Exorbitant Garbage Collection Times

Once a day, at around 4-4:30am, our application experiences a single Full GC with taking an exorbitant amount of time. A Full GC kicks in and pauses all threads for 5 to 30 minutes. Full GC's regularly occur at other times and complete in 5-20 seconds. Anyone seen this or any have any ideas about this?
Example of normal GC that occurs frequently throughout the day:
[Full GC[Unloading class $Proxy136]
4632722K->1616289K(6141952K), 14.9400110 secs]
Example of ridiculously long GC that occurs daily at 4-4:30am:
[Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor455]
5456231K->2017269K(6141952K), 492.0402160 secs]
Here's our VM params:
-server -XX:-OmitStackTraceInFastThrow -Xincgc -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:MaxGCPauseMillis=20000 -XX:+DisableExplicitGC -XX:NewSize=1500m -XX:SurvivorRatio=18 -verbose:gc
-Xms6000M -Xmx6000M
We're running Java 1.6 on Linux, Redhat 3.

Just experienced a 498 second (yikes!) garbage collection pause. The entry from the log is below (we added -XX:+PrintGCTimeStamps -XX:+PrintGCDetails and removed -verbose:gc). I will also send the entire log to the email address you have provided.
Note that we actually reduced our Xmx to 4000M (from 6000M) despite this machine having 8gig physical ram in the hopes that this would prevent any paging, and it seems to have drastically improved the situation - these exorbitant pauses now occur only very seldomly.
This is the full command we're justing to start the JBoss JVM:
/proj/bo/apps/jdk/production/bin/java -Dprogram.name=run.sh -server -XX:-OmitSta
ckTraceInFastThrow -Xincgc -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:MaxGCPauseMillis=20000 -XX:+DisableExplicitGC
-XX:NewSize=1500m -XX:SurvivorRatio=18 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Djava.endorsed.dirs=/var/local/jboss/jboss-c
urrent/lib/endorsed -Dsystem.state=production -Dcom.hb.common.api.util.Environment.app.name=Hermes -Djboss.partition.name=as20.
nyc.hcmny.com -Dorg.jboss.security.SecurityAssociation.ThreadLocal=true -Doracle.net.tns_admin=/var/opt/oracle/etc -Djnp.discov
eryPort=1103 -classpath /var/local/jboss/jboss-current/bin/run.jar:/proj/bo/apps/jdk/production/lib/tools.jar -Xms4000M -Xmx400
0M -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8134 -Dcom.sun.management.jmxremote.authenticate=true -Dc
om.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=/proj/bo/jmxremote.password org.jboss.Main -
cdefault
This is the exact JRE we're using:
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)
Here's the 498 second GC pause:
103999.802: [GC 103999.802: [ParNew (promotion failed): 1459200K->1459200K(1459200K), 478.7897900 secs]104478.592: [CMS104483.552: [CMS-concurrent-mark: 5.170/491.280 secs]
(concurrent mode failure)[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor605]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor866]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor870]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor887]
[Unloading class sun.reflect.GeneratedMethodAccessor267]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor864]
[Unloading class sun.reflect.GeneratedConstructorAccessor148]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor861]
[Unloading class sun.reflect.GeneratedMethodAccessor268]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor606]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor862]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor886]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor706]
[Unloading class sun.reflect.GeneratedConstructorAccessor145]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor865]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor350]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor860]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor868]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor863]
[Unloading class sun.reflect.GeneratedConstructorAccessor147]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor867]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor869]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor185]
[Unloading class sun.reflect.GeneratedConstructorAccessor125]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor871]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor707]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor708]
: 2517456K->2073715K(2560000K), 19.7399910 secs] 3927185K->2073715K(4019200K) icms_dc=5 , 498.5297810 secs]
 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96)
 at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
 at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1838)
 at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1747)
 at java.io.ObjectOutputStream.<init>(ObjectOutputStream.java:226)
21:37:07,931 WARN [TransactionImpl] Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=as20.nyc.hcmny.com/163214, BranchQual=, localId=163214] timed out. status=STATUS_ACTIVE
2007-09-12 21:37:08

Similar Messages

High garbage collection times

Our app is currently experiencing quite high garbage collection times. I've been looking for some causes for this and haven't had a ton of luck in finding anything. We have not run into an outOfMemoryException.
We have run with both 800M heap size and 2G heap size. With the 2G heap size, garbage colleciton takes ~40% of total time. With 800M it takes ~75% of total time. In both instances, OldGen memory is using between 60 and 75% of total heap size.
MarkSweep is running 1 time for every 11 scavenge runs (roughly). Each MarkSweep run takes around 30 seconds. Each Scavenge run takes around .1 seconds. This is for 2GB heap size.
My question is, could it just be possible that the app needs more memory? It seems like it could be a combination of needing a larger heap size with a code review to get rid of object references whenever possible.
If more details are needed to answer, let me know. Also, if I missed something obvious, let me know as well.

Joe.Cavanagh wrote:
Our app is currently experiencing quite high garbage collection times. I've been looking for some causes for this and haven't had a ton of luck in finding anything. We have not run into an outOfMemoryException.
We have run with both 800M heap size and 2G heap size....
MarkSweep is running 1 time for every 11 scavenge runs (roughly)...
My question is, could it just be possible that the app needs more memory?Incredibly difficult without knowing a bit more about what you're doing, but 800Mb is a lot of memory.
It seems like it could be a combination of needing a larger heap sizeHmmmm
with a code review to get rid of object references whenever possible.Bingo (I suspect). What application could possibly need to keep references to 800Mb worth of objects. If it's truly the case, then some kind of paging system might be in order.
If more details are needed to answer, let me know. Also, if I missed something obvious, let me know as well.Uhm yes. What are you doing?
Winston

Garbage collection time change

Hello how can i find out exactly when does garbage collection take place for my managed servers heap size and how can I optimize it and have garbage collection done at an earlier stage?

Hi,
You can use vm startup params -Xverbose:gcpause and -Xverboselog to trace and log gc events.
For example, java -Xverbose:gcpause -Xverboselog:verboseText.txt myApp

High cpu usage for garbage collection (uptime vs total gc time)

Hi Team,
We have a very high cpu usage issue in the production.
When we restart the server, the cpu idle time would be around 95% and it comes down as days goes by. Today idle cpu is 30% and it is just 6th day after the server restart.
Environemnt details:
Jrockit version:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-linux-ia32, Native Threads, GC strategy: parallel)
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep
Number Of Processors: 4
Max Heap Size: 1073741824
Total Garbage Collection Time: 21:43:56.5
Uptime: 114:33:4.1
Total Garbage Collection Count: 420872
Total Number Of Threads: 198
Number Of Daemon Threads: 191
Can you guys please tell me what would be problem in the server which causing the high cpu usage?
One more thing I would like to know is that why the total number of threads is 198 when we specified the Executor pool size as 25? I agree that weblogic would create some threads for its maintenance but around 160 threads!!! something is wrong I guess.
Santhosh.
[email protected]

Hi,
I'm having a similar problem, but haven't been able to resolve it yet. Troubleshooting is made even harder by the fact that this is only happening on our production server, and I've been unable to reproduce it in the lab.
I'll post whatever findings I have and hopefully we'll be able to find a solution with the help of BEA engineers.
In my case, I have a stand-alone Tomcat server that runs fine for about 1-2 days, and then the JVM suddenly starts using more CPU, and as a result, the server load shoots up (normal CPU utilization is ~5% but eventually goes up to ~95%; load goes from 0.1 to 4+).
What I have found so far is that this corresponds to increased GC activity.
Let me list my environment specs before I proceed, though:
CPU: Dual Xeon 3.06GHz
RAM: 2GB
OS: RHEL4.4 (2.6.9-42.0.2.ELsmp)
JVM build 1.5.0_03-b07 (BEA JRockit(R) (build dra-45238-20050523-2008-linux-ia32, R25.2.0-28))
Tomcat version 5.5.12
JAVA_OPTS="-Xms768m -Xmx768m -XXtlasize16k -XXlargeobjectlimit16k -Xverbose:memory,cpuinfo -Xverboselog:/var/log/tomcat5/jvm.log -Xverbosetimestamp"
Here are excerpts from my verbose log (I'm getting some HT warning, not sure if that's a problem):
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Detected SMP with 2 CPUs that support HT.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to determine if HT is enabled.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] HT is: supported by the CPU, not enabled by the OS, enabled in JRockit.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: HT enabled even though OS does not seem to support it.
[Fri Oct 20 15:54:55 2006][22855][memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
[Fri Oct 20 15:54:55 2006][22855][memory ] heap size: 786432K, maximal heap size: 786432K
[Fri Oct 20 16:07:30 2006][22855][memory ] Changing GC strategy to generational, parallel mark and parallel sweep
[Fri Oct 20 16:07:30 2006][22855][memory ] 791.642-791.874: GC 786432K->266892K (786432K), 232.000 ms
[Fri Oct 20 16:08:02 2006][22855][memory ] 824.122: nursery GC 291998K->274164K (786432K), 175.873 ms
[Fri Oct 20 16:09:51 2006][22855][memory ] 932.526: nursery GC 299321K->281775K (786432K), 110.879 ms
[Fri Oct 20 16:10:24 2006][22855][memory ] 965.844: nursery GC 308151K->292222K (786432K), 174.609 ms
[Fri Oct 20 16:11:54 2006][22855][memory ] 1056.368: nursery GC 314718K->300068K (786432K), 66.032 ms
[Sat Oct 21 23:21:09 2006][22855][memory ] 113210.427: nursery GC 734274K->676137K (786432K), 188.985 ms
[Sat Oct 21 23:30:41 2006][22855][memory ] 113783.140: nursery GC 766601K->708592K (786432K), 96.007 ms
[Sat Oct 21 23:36:15 2006][22855][memory ] 114116.332-114116.576: GC 756832K->86835K (786432K), 243.333 ms
[Sat Oct 21 23:48:20 2006][22855][memory ] 114841.653: nursery GC 182299K->122396K (786432K), 175.252 ms
[Sat Oct 21 23:48:52 2006][22855][memory ] 114873.851: nursery GC 195060K->130483K (786432K), 142.122 ms
[Sun Oct 22 00:01:31 2006][22855][memory ] 115632.706: nursery GC 224096K->166618K (786432K), 327.264 ms
[Sun Oct 22 00:16:37 2006][22855][memory ] 116539.368: nursery GC 246564K->186328K (786432K), 173.888 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117122.577: nursery GC 279056K->221543K (786432K), 170.367 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117123.041: nursery GC 290439K->225833K (786432K), 69.170 ms
[Sun Oct 22 00:29:10 2006][22855][memory ] 117291.795: nursery GC 298947K->238083K (786432K), 207.200 ms
[Sun Oct 22 00:39:05 2006][22855][memory ] 117886.478: nursery GC 326956K->263441K (786432K), 87.009 ms
[Sun Oct 22 00:55:22 2006][22855][memory ] 118863.947: nursery GC 357229K->298971K (786432K), 246.643 ms
[Sun Oct 22 01:08:17 2006][22855][memory ] 119638.750: nursery GC 381744K->322332K (786432K), 147.996 ms
[Sun Oct 22 01:11:22 2006][22855][memory ] 119824.249: nursery GC 398678K->336478K (786432K), 93.046 ms
[Sun Oct 22 01:21:35 2006][22855][memory ] 120436.740: nursery GC 409150K->345186K (786432K), 81.304 ms
[Sun Oct 22 01:21:38 2006][22855][memory ] 120439.582: nursery GC 409986K->345832K (786432K), 153.534 ms
[Sun Oct 22 01:21:42 2006][22855][memory ] 120443.544: nursery GC 410632K->346473K (786432K), 121.371 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.508: nursery GC 411273K->347591K (786432K), 60.688 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.623: nursery GC 412391K->347785K (786432K), 68.935 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.576: nursery GC 412585K->348897K (786432K), 152.333 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.783: nursery GC 413697K->349080K (786432K), 70.456 ms
[Sun Oct 22 01:34:16 2006][22855][memory ] 121197.612: nursery GC 437378K->383392K (786432K), 165.771 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.496: nursery GC 469709K->409076K (786432K), 78.257 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.730: nursery GC 502490K->437713K (786432K), 65.747 ms
[Sun Oct 22 01:44:03 2006][22855][memory ] 121785.259: nursery GC 536605K->478156K (786432K), 132.293 ms
[Sun Oct 22 01:44:04 2006][22855][memory ] 121785.603: nursery GC 568408K->503635K (786432K), 71.751 ms
[Sun Oct 22 01:50:39 2006][22855][memory ] 122180.985: nursery GC 591332K->530811K (786432K), 131.831 ms
[Sun Oct 22 02:13:52 2006][22855][memory ] 123573.719: nursery GC 655566K->595257K (786432K), 117.311 ms
[Sun Oct 22 02:36:04 2006][22855][memory ] 124905.507: nursery GC 688896K->632129K (786432K), 346.990 ms
[Sun Oct 22 02:50:24 2006][22855][memory ] 125765.715-125765.904: GC 786032K->143954K (786432K), 189.000 ms
[Sun Oct 22 02:50:26 2006][22855][memory ] 125767.535-125767.761: GC 723232K->70948K (786432K), 225.000 ms
vvvvv
[Sun Oct 22 02:50:27 2006][22855][memory ] 125768.751-125768.817: GC 712032K->71390K (786432K), 64.919 ms
[Sun Oct 22 02:50:28 2006][22855][memory ] 125769.516-125769.698: GC 711632K->61175K (786432K), 182.000 ms
[Sun Oct 22 02:50:29 2006][22855][memory ] 125770.753-125770.880: GC 709632K->81558K (786432K), 126.000 ms
[Sun Oct 22 02:50:30 2006][22855][memory ] 125771.699-125771.878: GC 708432K->61368K (786432K), 179.000 ms
So, I'm running with the default GC strategy which lets the GC pick the most suitable approach (single space or generational). It seems to switch to generational almost immediately and runs well - most GC runs are in the nursery, and only once in a while it goes through the older space.
Now, if you look at [Sun Oct 22 02:50:27 2006], that's when everything changes. GC starts running every second (later on it's running 3 times a second) doing huge sweeps. It never goes through the nursery again, although the strategy is still generational.
It's all downhill from this point on, and it's a matter of hours (maybe a day) before we restart the server.
I guess my only question is: What would cause such GC behavior?
I would appreciate your ideas/comments!
Thanks,
Tenyo

Why Garbage Collection take more time on JRockit?

My company use 
BEA WebLogic 8.1.2 
JRockit version 1.4.2 
Window 2003 32bit 
RAM 4 Gig 
 
-Xms = 1300 
-Xmx = 1300 
and running ejb application. 
My problem is why JRockit take more time. How Can I solve this problem. Because my application will down again.
 
This is my infomation on JRockit :
 
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep.
 
Total Garbage Collection Count: 10340
 
Last GC End: Wed May 10 13:55:37 ICT 2006
 
Last GC Start: Wed May 10 13:55:35 ICT 2006
 
Total Garbage Collection Time: 2:53:13.1
 
GC Handles Compaction: true
 
Concurrent: false
 
Generational: false
 
Incremental: false
 
Parallel: true
 

Hi,
I will suggest you to check a few places where you can see the status
1) SM37 job log (In source system if load is from R/3 or in BW if its a datamart load) (give request name) and it should give you the details about the request. If its active make sure that the job log is getting updated at frequent intervals.
Also see if there is any 'sysfail' for any datapacket in SM37.
2) SM66 get the job details (server name PID etc from SM37) and see in SM66 if the job is running or not. (In source system if load is from R/3 or in BW if its a datamart load). See if its accessing/updating some tables or is not doing anything at all.
3) RSMO see what is available in details tab. It may be in update rules.
4) ST22 check if any short dump has occured.(In source system if load is from R/3 or in BW if its a datamart load)
5) SM58 and BD87 for pending tRFCs and IDOCS.
Once you identify you can rectify the error.
If all the records are in PSA you can pull it from the PSA to target. Else you may have to pull it again from source infoprovider.
If its running and if you are able to see it active in SM66 you can wait for some time to let it finish. You can also try SM50 / SM51 to see what is happening in the system level like reading/inserting tables etc.
If you feel its active and running you can verify by checking if the number of records has increased in the data tables.
SM21 - System log can also be helpful.
Also RSA7 will show LUWS which means more than one record.
Thanks,
JituK

Garbage Collection take long times.....

*** NOTES 19-JUN-2001 10:27:33 [20-JUN-2001 00:27:33 ASST3] websupport
*** Logged by contact: Weber Wang, 2-87705935 ext. 63
Product Name and Version, including Service Pack (if any):
=============================================
weblogic6.0sp2
Platform (OS Version)
=================
solaris2.7
JDK Version (if applicable)
=====================
jdk130
If your problem relates to a 3rd party product (JDBC driver, database, or web/proxy
server), please provide vendor name, product name, version number
==============================================================================================
Detailed Problem Description
======================
we have set java parameter to start up weblogic server ,but got the Garbage Collection
time too long...it cause browser halt...when Garbage Collection
will do a Full GC?and will it degrade weblogic's performance?
java -server -verbose:class -verbose:gc -verbose:jni -XX:newSize=512m -XX:MaxNewSize=512m
-Xms768m -Xmx768m -XX:SurvivorRatio=2
Error Message/Stack Trace
=====================
[Full GC 65065K->27729K(65216K), 1.2891364 secs]
[Full GC 49079K->28008K(65216K), 1.0507784 secs]
[Full GC 65111K->29714K(65216K), 1.1813595 secs]
[Full GC 51063K->29988K(65216K), 1.0506374 secs]
[Full GC 64951K->27867K(65216K), 1.1312621 secs]
[Full GC 49216K->28146K(65216K), 1.0534394 secs]
[Full GC 65095K->29993K(65216K), 1.6070138 secs]
[Full GC 51343K->30182K(65216K), 1.3617954 secs]

I think your young generation size is waaaaay too high - its performance
impact becomes negative at or around 1/2 of the total heap size.
weber <[email protected]> wrote:
*** NOTES 19-JUN-2001 10:27:33 [20-JUN-2001 00:27:33 ASST3] websupport
*** Logged by contact: Weber Wang, 2-87705935 ext. 63
Product Name and Version, including Service Pack (if any):
=============================================
weblogic6.0sp2
Platform (OS Version)
=================
solaris2.7
JDK Version (if applicable)
=====================
jdk130
If your problem relates to a 3rd party product (JDBC driver, database, or web/proxy
server), please provide vendor name, product name, version number
==============================================================================================
Detailed Problem Description
======================
we have set java parameter to start up weblogic server ,but got the Garbage Collection
time too long...it cause browser halt...when Garbage Collection
will do a Full GC?and will it degrade weblogic's performance?
java -server -verbose:class -verbose:gc -verbose:jni -XX:newSize=512m -XX:MaxNewSize=512m
-Xms768m -Xmx768m -XX:SurvivorRatio=2
Error Message/Stack Trace
=====================
[Full GC 65065K->27729K(65216K), 1.2891364 secs]
[Full GC 49079K->28008K(65216K), 1.0507784 secs]
[Full GC 65111K->29714K(65216K), 1.1813595 secs]
[Full GC 51063K->29988K(65216K), 1.0506374 secs]
[Full GC 64951K->27867K(65216K), 1.1312621 secs]
[Full GC 49216K->28146K(65216K), 1.0534394 secs]
[Full GC 65095K->29993K(65216K), 1.6070138 secs]
[Full GC 51343K->30182K(65216K), 1.3617954 secs]--
Dimitri

Disabling RMI Explicit Garbage Collection

I have an application that uses RMI. From different articles on the javasoft web site, I have read that RMI explicitly does a Full RMI every minute (default setting). This is undesirable, b/c these full GCs are causing some objects I need to use later to be garbage collected. From the site, the options are to:
1) Disable Full GC
2) Delay Full GC
For point 1), what are the consequences of disabling explicit full GCing that RMI does? Documentation on the javasoft website only says that "this may also cause some objects to take much longer to be reclaimed" etc. To me, I would think that disabling the explicit Full GC is a bad idea for RMI applications (unless they are really short lived, but that is not my case). It would seem safer to go with 2) option to delay the Full GCs since it's not entirely clear what the consequences are of completey disabling explicit GCs, but this still causes objects I still need to use later to be garbage collected. The last option which I feel is not very elegant, would be to just set something to reference or use that object that is being gc'ed so when a Full GC is performed it doesn't get cleaned up. Does anyone have any experience with this or have any better suggestions?
I am using Java 1.4.2 currently, but am also interested in learning what would be good for Java 1.2.X and 1.3.X as well.
Thanks!
These are the links that I have already visited or docs that I have already read on this topic:
1) Java 2 Platform, Standard Edition v 1.4 Performance and Scalability Guide
http://java.sun.com/j2se/1.4/performance.guide.html
2) Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
3) Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1
http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/#11.1.3.15
4) Garbage Collection for Remote Objects (1.4.2)
http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-arch4.html

Towards the end of my pot I wrote:
The last option which I feel is not very elegant, would be to just set something to reference or use that object that is being gc'ed so when a Full GC is performed it doesn't get cleaned up. Does anyone have any experience with this or have any better suggestions?
I realize that I can reference these objects, but I don't think that is really a great solution. This would mean deliberately referencing them (a hack at a solution in my view) when really it's the explicity GC running every minute (b/c of RMI) that is collecting them. If I turn the explicit GC off, my objects are not collected like this.
My question was really does anyone have any better ideas or experience with RMI's explicit garbage collecting? I don't need to read a tutorial to tell me how to keep my objects alive by referencing them. Thanks.

Garbage collection & memory management causing app to run poorly on iOS 7

Sorry I post the same question but in the wrong forum (I posted it in the Flash Player Beta Channel).
Hi, I am currently working on a game built using Air SDK v. 3.8 that is running fine on iOS 6. However, since the release of iOS, sometime it becomes unresponsive. When profiling with Adobe Scout, the problem seems to have something to do with the garbage collection. In Scout, some GC pass could take up to few seconds on iOS 7, while it would never take more than 700 ms on iOS 6.
I've tried to compile the project using the new 3.9 beta, and the result is somewhere in between what we've got on iOS 6 and iOS 7 (1-2 seconds).
I'm wondering if this is something that you are aware of, and if there's a fix (or optimisation) around the corner. Thanks a lot.

I am also seeing this.
Here are screenshots of Scout profiling the same sequence in my game on iPad 2 iOS 7 vs iPad 2 iOS 6. The initial burst of activity is a loading sequence, followed by automated gameplay.
iOS 7: Please note the position of the red line on the graph, and the time associated with garbage collection.
iOS 6:
Ignoring the "loading sequence" section, the "vertical line" garbage collection spikes on the iOS 7 screen shot are on the order of 2-5 seconds (garbage collection time) each. The biggest spikes in the iOS 6 screen shot are all < 50 ms in comparison (again, note the position of the red line on the graph).
Earlier in the day I captured a few garbage collection spikes on iOS 7 that were > 10 seconds each, with the largest being a whopping 24 seconds.
Any insights, supporting evidence, or alternative theories are appreciated.
UPDATE: I tested an iPad3 iOS7 today and did not experience this behavior.
UPDATE: I tested with another iPad2 iOS7 and did see the behavior on that device as well.

Long pauses during ParNew garbage collection Please Help !

Hi,
We are running a server application on an large machine (~120 CPU, ~380 GB Memory).
After running 1 or 2 hours we suddenly get exorbitant application pause times during garbage collection and a massive cpu usage from the java vm
We are running on Java 6 (64Bit) with 6GB Heap.
Concurrent garbage collection is turned on using the parameters:
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=80
-XX:+DisableExplicitGC
We turned on verbose garbage collection and are getting the following output:
1. Normal operation:
Application time: 217.4656792 seconds
3180.905: [GC 3180.906: [ParNew
Desired survivor size 20119552 bytes, new threshold 4 (max 4)
- age   1:    2843824 bytes,    2843824 total
- age   2:    2577128 bytes,    5420952 total
- age   3:    5742024 bytes,   11162976 total
- age   4:     625672 bytes,   11788648 total
: 329531K->15764K(353920K), 0.1484379 secs] 2435799K->2122105K(3392144K), 0.1492386 secs]
Total time for which application threads were stopped: 0.1886810 seconds
2. The Problem:
Application time: 2.8858445 seconds
5008.433: [GC 5008.434: [ParNew
Desired survivor size 20119552 bytes, new threshold 2 (max 4)
- age   1:   15837712 bytes,   15837712 total
- age   2:   12284416 bytes,   28122128 total
: 348338K->39296K(353920K), 138.5317715 secs] 2487779K->2192551K(3392144K), 138.5327383 secs]
Total time for which application threads were stopped: 138.5778558 seconds
Application time: 2.9764564 seconds
5149.957: [GC 5149.957: [ParNew
Desired survivor size 20119552 bytes, new threshold 2 (max 4)
- age   1:    9483176 bytes,    9483176 total
- age   2:   14499344 bytes,   23982520 total
: 353920K->39296K(353920K), 231.5110574 secs] 2507175K->2204546K(3392144K), 231.5121011 secs]
Total time for which application threads were stopped: 231.5257754 seconds
Application time: 2.7932907 seconds
5384.277: [GC 5384.278: [ParNew
Desired survivor size 20119552 bytes, new threshold 4 (max 4)
- age   1:   10756376 bytes,   10756376 total
- age   2:    9135888 bytes,   19892264 total
: 353920K->28449K(353920K), 256.2065591 secs] 2519170K->2207651K(3392144K), 256.2076388 secs]
Total time for which application threads were stopped: 256.2221463 seconds
I can't find any significant differences in the log between fast and long running garbage collections.
I urgently need help in solving this problem !
What can I do ?

After the exciting reply I did get on my question, we did some more investigations on the problem and it seems that we finally found the solution to our problem.
The number of garbage collection threads used by the virtual machine defaults to the number of cpus of the machine.
This is ok for small machines or machines where the main load is produced by the java application itself.
In our environment the main load is not produced by the java application but oracle database processes.
When java tries to do it's garbage collection using 120 threads (# CPU) on the machine which is already overloaded by non java processes, the thread synchronization seems to produce an exorbitant overhead.
My theory is that spin locking is used on memory access, causing threads to spin while waiting for other blocking threads not getting cpu because of the heavy load on the system.
The solution is now to limit the number of garbage collection threads.
We did that on the first try by setting -XX:ParallelGCThreads=8
For over one day with heavy load no long GC pauses were experienced any more.

Hotspot core dumping during JVM garbage collection ?

We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
Any ideas gratefully accepted.
Here's a logfile excerpt from my applications showing the Hotspot error message :
=====================================================================================
08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
405.977: [Full GC#
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
# An error report file with more information is saved as hs_err_pid2600.log
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
=====================================================================================
The logfile referred to in the error message contains the following.
=====================================================================================
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
--------------- T H R E A D ---------------
Current thread (0x001484d8): VMThread [id=8]
siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
Registers:
O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
PC=0xfe141348 nPC=0xfe14134c
Top of Stack: (sp=0xf8781460)
0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
0xf8781470: 0000080f e54bab6c 0000080f 00000004
0xf8781480: 00487588 00000134 e54bab6c 00000004
0xf8781490: 00000001 00000000 f87814c0 fe17aef4
0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
0xf87814b0: 00148988 00148c10 00148d7c f8781880
0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
0xf87814d0: 00008800 00487588 fe141310 fe7d6454
Instructions: (pc=0xfe141348)
0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x141348]
V [libjvm.so+0x17aefc]
V [libjvm.so+0x2d557c]
V [libjvm.so+0x300ef8]
V [libjvm.so+0x301e84]
V [libjvm.so+0x2ff950]
V [libjvm.so+0x29df30]
V [libjvm.so+0x362b44]
V [libjvm.so+0x6436f0]
VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
0x00038238 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
=>0x001484d8 VMThread [id=8]
0x0015c3b0 WatcherThread [id=16]
VM state:at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
[0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
Heap
PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
Dynamic libraries:
0x00010000      /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
0xff350000      /usr/lib/libthread.so.1
0xff340000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff390000      /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
0xff1e0000      /usr/lib/libsocket.so.1
0xff2d0000      /usr/lib/libsched.so.1
0xff1b0000      /usr/lib/libCrun.so.1
0xff160000      /usr/lib/libm.so.1
0xff080000      /usr/lib/libnsl.so.1
0xff060000      /usr/lib/libmp.so.2
0xff030000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
0xfdfc0000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
0xfdf80000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
0xfdf50000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
0xfb7e0000      /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xe4190000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
0xe3bd0000      /dsdvlp/lib/5/libSolarisNatives.so
0xe3e90000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
VM Arguments:
jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
Environment Variables:
JAVA_HOME=/dsdvlp/java/jvm/jdk150
CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
SHELL=/bin/csh
DISPLAY=CLI00184.mfil.local:1.0
OS=5
--------------- S Y S T E M ---------------
OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
load average:2.24 2.67 2.68
CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(166384k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550

The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
don't want to waste your time chasing a bug that's already been fixed.

High Eden Java Memory Usage/Garbage Collection

Hi,
I am trying to make sure that my Coldfusion Server is optomised to the max and to find out what is normal limits.
Basically it looks like at times my servers can run slow but it is possible that this is caused by a very old bloated code base.
Jrun can sometimes have very high CPU usage so I purchased Fusion Reactor to see what is going on under the hood.
Here are my current Java settings (running v6u24):
java.args=-server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:PermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.io.useCanonCaches=false -XX:+UseParallelGC -Xbatch ........
With regards Memory, the only memory that seems to be running a lot of Garbage Collection is the Eden Memory Space. It climbs to nearly 1.2GB in total just under every minute at which time it looks like GC kicks in and the usage drops to about 100MB.
Survivor memory grows to about 80-100MB over the space of 10 minutes but drops to 0 after the scheduled full GC runs. Old Gen memory fluctuates between 225MB and 350MB with small steps (~50MB) up or down when full GC runs every 10 minutes.
I had the heap set to 2GB initally in total giving about 600MB to the Eden Space. When I looked at the graphs from Fusion Reactor I could see that there was (minor) Garbage Collection about 2-3 times a minute when the memory usage maxed out the entire 600MB which seemed a high frequency to my untrained eye. I then upped the memory to 4GB in total (~1.2GB auto given to Eden space) to see the difference and saw that GC happened 1-2 times per minute.
Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often? i.e do these graphs look normal?
Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
Any other advice for performance improvements would be much appreciated.
Note: These graphs are not from a period where jrun had high CPU.
Here are the graphs:
PS Eden Space Graph
PS Survivor Space Graph
PS Old Gen Graph
PS Perm Gen Graph
Heap Memory Graph
Heap/Non Heap Memory Graph
CPU Graph
Request Average Execution Time Graph
Request Activity Graph
Code Cache Graph

Hi,
>Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often?
Yes normal to garbage collect Eden often. That is a minor garbage collection.
>Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
Sometimes it is good to set Eden (Eden and its two Survivor Spaces combined make up New or Young Generation part of JVM heap) to a smaller size. I know your thinking - what make it less, but I want to make it bigger. Give less a try (sometimes less = more, bigger not = better) and monitor the situation. I like to use -Xmn switch, some sources say to use other method/s. Perhaps you could try java.args=-server -Xmx4096m -Xms4096m -Xmn172m etc. I better mention make a backup copy of jvm.config before applying changes. Having said that now you know how you can set the size to bigger if you want.
I think the JVM is perhaps making some poor decisions with sizing the heap. With Eden growing to 1Gb then being evacuated not many objects are surviving and therefore not being promoted to Old Generation. This ultimately means the object will need to be loaded again latter to Eden rather than being referenced in the Old generation part of the heap. Adds up to poor performance.
>Any other advice for performance improvements would be much appreciated.
You are using Parallel garbage collector. Perhaps you could enable that to run multi-threaded reducing the time duration of the garbage collections, jvm args ...-XX:+UseParallelGC -XX:ParallelGCThreads=N etc where N = CPU cores (eg quad core = 4).
HTH, Carl.

IncompatibleClassChangeError. Caused by garbage collection?

The problem occurs on JDK 1.3.1-b24 compiled in JBuilder Windows and
running on Sun Solaris with identical JDK version.
The application is a relatively complex RMI server.
An error recovery function in the server runs in a Thread every two
minutes. Most of the time it has nothing to do and ends without
incident.
Occasionally conditions require recovery that may not be successful
for many attempts.
Part of the recovery is a simple debug display of parameters involved
in the recovery. There will be multiple displays during a single
recovery cycle.
In a recent example of problem, the recovery executed every two
minutes for over two hours with the debug display working
successfully.
Suddenly one display works successfully and 5 milliseconds later the
same display fails with a IncompatibleClassChangeError.
The last part of the stack trace is:
java.lang.IncompatibleClassChangeError
 at [class name].toString([class name].java:74)
 at java.lang.String.valueOf(String.java:1947)
 at java.lang.StringBuffer.append(StringBuffer.java:370)
 at java.util.AbstractMap.toString(AbstractMap.java:567)
 at java.lang.String.valueOf(String.java:1947)
line 74 of class is
public String toString()
return _responses.toString();
where _responses is an ArrayList that has been stored on Map that
contains the parameters that is being display as part of the debug
information.
Once the failure occurs, it will always occur until the JVM is
restarted. This suggests to me that something in the JVM, maybe garbage collection, has either corrupted the in-memory copy of the class or some internal table used by the JVM has become corrupted.
Anybody else have ideas?

java.lang.IncompatibleClassChangeError
 at [class name].toString([class name].java:74)
 at java.lang.String.valueOf(String.java:1947)
at
java.lang.StringBuffer.append(StringBuffer.java:370)
at
java.util.AbstractMap.toString(AbstractMap.java:567)
 at java.lang.String.valueOf(String.java:1947)
Problem: The IncompatiableClassChangeError is a Symbolic resolution problem. In lamen's terms a package,class,method,or a variable name is corrupted.
Possible problem location: Are you using a Custom ClassLoader? Do you Load and compile on the fly?
where _responses is an ArrayList that has been stored
on Map that
I would look hard at the following methods in your MAP Interface:
public void clear();
public Object put(Object key,Object value);
public void putAll(Map t);
public Object remove(Object key);Is it possible that your MAP interface is corrupting your ArrayList using one of the above methods? Then, when you are building the strings using the AbstractMap's.toString() method, you are getting the IncompatiableClassChangeError?
This is word for word listing of the MAP Interface...V1.41.
Some map implementations have restrictions on the keys and values they may contain. For example, some implementations prohibit null keys and values, and some have restrictions on the types of their keys.
This puzzles me
Attempting to insert an ineligible key or value throws an unchecked exception, typically NullPointerException or ClassCastException.
What's this, they state above that you should get a unchecked Exception, but the first sentence below makes me assume they are pulling a query on an ineligible key or value???
Attempting to query the presence of an ineligible key or value may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter.
Oh,OK. They are basically saying it totally depends on how you implement this Interface <grin>
More generally, attempting an operation on an ineligible key or value whose completion would not result in the insertion of an ineligible element into the map may throw an exception or it may succeed, at the option of the implementation.
The "optional" they are talking about are the methods that I listed above.
Such exceptions are marked as "optional" in the specification for this interface.
Well you asked for ideas, so there's a brain fart for you?
...Hope this helps

Remove / unload external swf file(s) from the main flash file and load a new swf file and garbage collection from memory.

I can't seem to remove / unload the external swf files e.g when the carousel.swf (portfolio) is displayed and I press the about button the about content is overlapping the carousel (portfolio) . How can I remove / unload an external swf file from the main flash file and load a new swf file, while at the same time removing garbage collection from memory?
This is the error message(s) I am receiving: "TypeError: Error #2007: Parameter child must be non-null.
at flash.display::DisplayObjectContainer/removeChild()
at index_fla::MainTimeline/Down3()"
import nl.demonsters.debugger.MonsterDebugger;
var d:MonsterDebugger=new MonsterDebugger(this);
stage.scaleMode=StageScaleMode.NO_SCALE;
stage.align=StageAlign.TOP_LEFT;
stage.addEventListener(Event.RESIZE, resizeHandler);
// loader is the loader for portfolio page swf
var loader:Loader;
var loader2:Loader;
var loader3:Loader;
var loader1:Loader;
// resize content
function resizeHandler(event:Event):void {
    // resizes portfolio page to center
loader.x = (stage.stageWidth - loader.width) * .5;
loader.y = (stage.stageHeight - loader.height) * .5;
// resizes about page to center
loader3.x = (stage.stageWidth - 482) * .5 - 260;
loader3.y = (stage.stageHeight - 492) * .5 - 140;
/*loader2.x = (stage.stageWidth - 658.65) * .5;
loader2.y = (stage.stageHeight - 551.45) * .5;*/
addEventListener(Event.ENTER_FRAME, onEnterFrame,false, 0, true);
function onEnterFrame(ev:Event):void {
var requesterb:URLRequest=new URLRequest("carouselLoader.swf");
loader = null;
loader = new Loader();
loader.name ="carousel1"
//adds gallery.swf to stage at begining of movie
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader.load(requesterb);
} catch (error:SecurityError) {
trace(error);
addChild(loader);
loader.x = (stage.stageWidth - 739) * .5;
loader.y = (stage.stageHeight - 500) * .5;
// stop gallery.swf from duplication over and over again on enter frame
removeEventListener(Event.ENTER_FRAME, onEnterFrame);
//PORTFOLIO BUTTON
//adds eventlistner so that gallery.swf can be loaded
MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
function Down(event:MouseEvent):void {
// re adds listener for contact.swf and about.swf
MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
//unloads gallery.swf from enter frame if users presses portfolio button in nav
var requester:URLRequest=new URLRequest("carouselLoader.swf");
    loader = null;
loader = new Loader();
loader.name ="carousel"
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader.load(requester);
} catch (error:SecurityError) {
trace(error);
addChild(loader);
loader.x = (stage.stageWidth - 739) * .5;
loader.y = (stage.stageHeight - 500) * .5;
removeChild( getChildByName("about") );
removeChild( getChildByName("carousel1") );
// remove eventlistner and prevents duplication of gallery.swf
MovieClip(root).nav.portfolio.removeEventListener(MouseEvent.MOUSE_DOWN, Down);
//INFORMATION BUTTON
//adds eventlistner so that info.swf can be loaded
MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
function Down1(event:MouseEvent):void {
//this re-adds the EventListener for portfolio so that end user can view again if they wish.
MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
var requester:URLRequest=new URLRequest("contactLoader.swf");
loader2 = null;
loader2 = new Loader();
loader2.name ="contact"
loader2.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader2.load(requester);
} catch (error:SecurityError) {
trace(error);
addChild(loader2);
loader2.x = (stage.stageWidth - 658.65) * .5;
loader2.y = (stage.stageHeight - 551.45) * .5;
// remove eventlistner and prevents duplication of info.swf
MovieClip(root).nav.info.removeEventListener(MouseEvent.MOUSE_DOWN, Down1);
//ABOUT BUTTON
//adds eventlistner so that info.swf can be loaded
MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
function Down3(event:MouseEvent):void {
//this re-adds the EventListener for portfolio so that end user can view again if they wish.
MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
var requester:URLRequest=new URLRequest("aboutLoader.swf");
loader3 = null;
loader3 = new Loader();
loader3.name ="about"
loader3.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
function ioError(event:IOErrorEvent):void {
trace(event);
try {
loader3.load(requester);
} catch (error:SecurityError) {
trace(error);
addChild(loader3);
loader3.x = (stage.stageWidth - 482) * .5 - 260;
loader3.y = (stage.stageHeight - 492) * .5 - 140;
removeChild( getChildByName("carousel") );
removeChild( getChildByName("carousel1") );
// remove eventlistner and prevents duplication of info.swf
MovieClip(root).nav.about.removeEventListener(MouseEvent.MOUSE_DOWN, Down3);
stop();

Andrei1,
Thank you for the helpful advice. I made the changes as you suggested but I am receiving a #1009 error message even though my site is working the way I wan it to work. I would still like to fix the errors so that my site runs and error free. This is the error I am receiving:
"TypeError: Error #1009: Cannot access a property or method of a null object reference."
I'm sure this is not the best method to unload loaders and I am guessing this is why I am receiving the following error message.
     loader.unload();
     loader2.unload();
     loader3.unload();
I also tried creating a function to unload the loader but received the same error message and my portfolio swf was not showing at all.
     function killLoad():void{
     try { loader.close(); loader2.close; loader3.close;} catch (e:*) {}
     loader.unload(); loader2.unload(); loader3.unload();
I have a question regarding suggestion you made to set Mouse Event to "null". What does this do setting the MouseEvent do exactly? Also, since I've set the MouseEvent to null do I also have to set the loader to null? e.g.
---- Here is my updated code ----
// variable for external loaders
var loader:Loader;
var loader1:Loader;
var loader2:Loader;
var loader3:Loader;
// makes borders resize with browser size
function resizeHandler(event:Event):void {
// resizes portfolio page to center
     loader.x = (stage.stageWidth - loader.width) * .5;
     loader.y = (stage.stageHeight - loader.height) * .5;
// resizes about page to center
     loader3.x = (stage.stageWidth - 482) * .5 - 260;
     loader3.y = (stage.stageHeight - 492) * .5 - 140;
//adds gallery.swf to stage at begining of moviie
     Down();
//PORTFOLIO BUTTON
//adds eventlistner so that gallery.swf can be loaded
     MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
function Down(event:MouseEvent = null):void {
// re adds listener for contact.swf and about.swf
     MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
     MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
//unloads gallery.swf from enter frame if users presses portfolio button in nav
     var requester:URLRequest=new URLRequest("carouselLoader.swf");
     loader = new Loader();
     loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
     function ioError(event:IOErrorEvent):void {
     trace(event);
     try {
     loader.load(requester);
     } catch (error:SecurityError) {
     trace(error);
     this.addChild(loader);
     loader.x = (stage.stageWidth - 739) * .5;
     loader.y = (stage.stageHeight - 500) * .5;
// sure this is not the best way to do this - but it is unload external swfs
     loader.unload();
     loader2.unload();
     loader3.unload();
// remove eventlistner and prevents duplication of gallery.swf
     MovieClip(root).nav.portfolio.removeEventListener(MouseEvent.MOUSE_DOWN, Down);
//INFORMATION BUTTON
     //adds eventlistner so that info.swf can be loaded
     MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
     function Down1(event:MouseEvent = null):void {
     //this re-adds the EventListener for portfolio so that end user can view again if they wish.
     MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
     MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
     var requester:URLRequest=new URLRequest("contactLoader.swf");
     loader2 = null;
     loader2 = new Loader();
     loader2.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
     function ioError(event:IOErrorEvent):void {
     trace(event);
     try {
     loader2.load(requester);
}      catch (error:SecurityError) {
     trace(error);
     addChild(loader2);
     loader2.x = (stage.stageWidth - 658.65) * .5;
     loader2.y = (stage.stageHeight - 551.45) * .5;
loader.unload();
loader2.unload();
loader3.unload();
     // remove eventlistner and prevents duplication of info.swf
     MovieClip(root).nav.info.removeEventListener(MouseEvent.MOUSE_DOWN, Down1);
//ABOUT BUTTON
     //adds eventlistner so that info.swf can be loaded
     MovieClip(root).nav.about.addEventListener(MouseEvent.MOUSE_DOWN, Down3, false, 0, true);
     function Down3(event:MouseEvent = null):void {
     //this re-adds the EventListener for portfolio so that end user can view again if they wish.
     MovieClip(root).nav.portfolio.addEventListener(MouseEvent.MOUSE_DOWN, Down, false, 0, true);
     MovieClip(root).nav.info.addEventListener(MouseEvent.MOUSE_DOWN, Down1, false, 0, true);
     var requester:URLRequest=new URLRequest("aboutLoader.swf");
     loader3 = null;
     loader3 = new Loader();
     loader3.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioError);
     function ioError(event:IOErrorEvent):void {
     trace(event);
     try {
     loader3.load(requester);
}      catch (error:SecurityError) {
     trace(error);
     addChild(loader3);
     loader3.x = (stage.stageWidth - 482) * .5 - 260;
     loader3.y = (stage.stageHeight - 492) * .5 - 140;
     loader.unload();
     loader2.unload();
     loader3.unload();
     // remove eventlistner and prevents duplication of info.swf
     MovieClip(root).nav.about.removeEventListener(MouseEvent.MOUSE_DOWN, Down3);
     stop();

Garbage Collection not releasing memory properly

Hello, In my web application memory is not releasing properly, after some point of time application throw out of memory error, we are using tomcat5, jdk5, my heap size is half of the RAM.Garbage Collection not releasing memory properly.

sabre150 wrote:
punter wrote:
georgemc wrote:
Yep. Couldn't be a problem with your code, it must be that garbage collection doesn't work and nobody else noticed. Raise a bug with Sun.Are you serious ?You need to replace your sarcasm detector.I have blowed my sarcasm meter and limping in the blindness !!!! :(

Do you think JOptionPane dialogs force garbage collection afterwards?

I ask because I've made a nested static class to implement my own file selection tool; the problem is that each time I call it the old JPanel is being recalled and so the components get re-added to it each time it's called, resulting in n versions of each file for every n times you open it.
I'm running myDialog.dispose() upon exiting, so is my only option now manual garbage collection? How could I force it to be garbage collected? Because System.gc() seems to have no effect.

Strictly speaking there is no way to force garbage collection, so, no, JOptionPane will not be doing it.
You almost certainly have a leak in your code. Post it and we may be able to help.

Exorbitant Garbage Collection Times

Similar Messages

Maybe you are looking for