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

Similar Messages

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

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

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

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

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.

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.

Reconciling garbage collection, heap overview, and object stats

First, both the JRockit RuntimeAnalyzer and Console are great tools. We use
them extensively so thank you.
I'm trying to reconcile the numbers in these three tabs.
1. How do I reconcile the Runtime Analyzer and Console output?
- The Heap overview tab in our application profile shows Heap Overview as
83% free.
- However, the Garbage Collection tab of the profile and Console shows the
application as oscillating between 50 Meg and 200 Meg of heap used. That's
25% (50Meg/200Meg) to 100%(200Meg/200Meg) used. How do I interpret the 83%
vs. the 100%?
I don't believe the 83% free, but I'm skeptical that we consume 150Meg of
memory in 50 seconds.
2. How do I reconcile the Object stats with the Garbage collection?
- Take the top heap user at end of recording, character buffer. It's 22.8%
of heap using 6,328 KB. If the heap is actually only 34Meg ( 17% of 200Meg.
I get the 17% from the 83% free), then 22.8% makes sense.
- So what's in the 200Meg of heap?
I sent this recording to the JRA team if you want to look at it.
Thanks
Jeff

I've never heard it put that way. Very interesting.
"Johan Walles" <johan@spamalamadingdong> wrote in message
news:41bf0be3@mail...
Note that the time it takes for the garbage collector to do its thing
grows with the amount of live data.
What the garbage collector really does is more like retaining the live
data than disposing of the garbage.
Regards //Johan
Jeff wrote:
Staffan,
Thanks - you clearly answered my questions. Now the follow-on questions:
1. Is there a way to get insight into what the 'dead' data is composed
of?
2. Is this pattern of consuming 3x the live data in about a minute
'typical' or a disaster in the making?
I'm trying to get a sense of what a reasonable target of 'dead' data is.
The system processes about a meg of data per second, including database
writes.
Thanks
Jeff
"sla" <[email protected]> wrote in message
news:33533893.1102952170368.JavaMail.root@jserv5...
Hi Jeff,
I'll try to answer the questions.
1) The Heap overview in the application profile is a snapshot of the heap
at the end of a garbage collection. At this time only live data is still
on the heap. So it looks like you have 17% of the heap filled with live
data (and some overhead as seen in the Heap overview).
In the garbage collection tab you can see the heap usage oscillating
between 35-40MB and 200MB. The lower value is right after a garbage
collection and the higher value is right before a garbage collection. The
garbage collector clears out about 160MB of "dead" data from the heap.
This is the amount of temporary objects that you created during the
garbage collection cycles.
2) The Object statistics are also taken right after a garbage collection.
At this time there is 34M of live data on the heap and of these about 22%
is taken up by character arrays (not unusual).
At this time the rest of the 200MB heap is empty. It's been cleared of
all temporary objects and is ready for allocation of new objects.
I hope this answered your questions.
Regards,
/Staffan

Improving Latency - Garbage Collection

Hi there,
Are there any suggestions as to what you can do to reduce latency in real time applications. Any suggestions as to improving performance times or garbage collection?
Thanks,

Hi there,
Are there any suggestions as to what you can do to
reduce latency in real time applications. High octane Java!
I would have suggested you search for a specific forum on this site that features such topics but alas, google is not for you, so....

Garbage Collection in jdk 1.3 on 2K

I have recently run into a problem with garbage collection in JDK 1.3 that is reminicent of jdk 1.1x. On complex pages I am getting GC times of 5+ seconds in the middle of the page (sometime multiple times). I have also noted that if I push the complexity even higher the machine goes into a meltdown so to speak, it allocates an extra 200m ram and spins off 200+ threads and sits there for a minute doing nothing then deallocates the bunch and continues...but in random places. This is NOT good for page performance. One final oddity is that I am seeing 5+ second GC's when the pages are being compiled. When I switch back to JDK 1.2.2 everything works fine.
We haven't tested on production hardware (Sun/Solaris) so as yet it hasn't effected us but I would hate to switch back to 1.2.2 and loose the speed boost. Anybody out there had similar problems? Found fixes? I am tuning the pages and EJBs backing them for ram (it helps ALOT)but it's still not acceptable. Thanx!
-Jeff Ward

As the message mentioned by you i.e. : Unloading class sun.reflect.GeneratedMethodAccessor4069
Are related to FULL GC happening within the JVM and hence it is trying to unload the classes.
The Flags: -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
Will allow the JVM to log the GC details within the server log file with the exact time stamps which can be analyzed to figure out why the unloading of classes are happening.
Thanks,
Sandeep

[scjp exam] garbage collection questions

can someone please post me some garbage collection questions + correct answers, because i've taken the SCJP test again and i didn't passed it again. A co-worker of mine also didn't passed either.
(We both got 0% on Garbage Collection every time) And i really thought i had it correct the last time.
So please can someone mail/post me some garbage collection questions? thanks!

The garbage collector collects unreachable objects.
You have no control over when the objects are
collected, but there is a guarantee that all
unreachable objects will be collected before an
OutOfMemoryError is thorwn.Exactly my thoughts...
That's it. It really is just that simple. I scored 94%
on the Programmer's Exam, with 100% in the garbage
collection section.Hmm i got 54% last exam i took. I really begin to doubt about myself, because i find the questions on the exam so tricky.. Last book was Exam Cram (Java), and i found this a very nice and good book to study for the exam. Garbage collection is just one question, so it's either 0% or 100%. So far it hasn't gone anything higher then 0% with me.
Here are some questions:
1. When is the Object first available for garbage
collection (when does it become unreachable)?
Object o = new Object();
Object p = o;
o = null;
p = null;p = null; -> available for gc.
2. When is the Object first available for garbage
collection?
Object o = new Object();
Vector v = new Vector();
v.add(o);
o = null;
v = null;v = null; -> available for gc.
3. Can the Vectors be garbage collected at the end of
this code?
Vector v = new Vector();
Vector w = new Vector();
v.add(w);
w.add(v);
v = null;
w = null;yes
Now i have a question:
public int foo {
Integer result = new Integer(10);
result = null;
return result;
when is result available for gc?

Garbage Collection settings

Hi All
I have the following snippet from GC logs:
Can we determine settings of VM?
Are these settings too high, I mean is large amount of memory thrown at it?
Also based on pattern in used Tenured Generation ( Ex: 271844K) can I determine a memory leak.
Is it good or bad to use these kind of settings.
Please let me know.
Bib
Heap
def new generation total 104832K, used 57076K [0x10010000, 0x171d0000, 0x171d0000)
eden space 93184K, 51% used [0x10010000, 0x12f32e20, 0x15b10000)
from space 11648K, 75% used [0x15b10000, 0x163aa270, 0x16670000)
to space 11648K, 0% used [0x16670000, 0x16670000, 0x171d0000)
tenured generation total 932096K, used 409688K [0x171d0000, 0x50010000, 0x50010000)
the space 932096K, 43% used [0x171d0000, 0x301e6148, 0x301e6200, 0x50010000)
compacting perm gen total 131072K, used 75403K [0x50010000, 0x58010000, 0x58010000)
the space 131072K, 57% used [0x50010000, 0x549b2e10, 0x549b3000, 0x58010000)
33256.362: [Tenured: 409688K->271844K(932096K), 1.8892192 secs] 466764K->271844K(1036928K), [Perm : 75403K->75403K(131072K)] Heap after GC invocations=121:
Heap
def new generation total 104832K, used 0K [0x10010000, 0x171d0000, 0x171d0000)
eden space 93184K, 0% used [0x10010000, 0x10010000, 0x15b10000)
from space 11648K, 0% used [0x15b10000, 0x15b10000, 0x16670000)
to space 11648K, 0% used [0x16670000, 0x16670000, 0x171d0000)
tenured generation total 932096K, used 271844K [0x171d0000, 0x50010000, 0x50010000)
the space 932096K, 29% used [0x171d0000, 0x27b49228, 0x27b49400, 0x50010000)
compacting perm gen total 131072K, used 75403K [0x50010000, 0x58010000, 0x58010000)
the space 131072K, 57% used [0x50010000, 0x549b2e10, 0x549b3000, 0x58010000)
} , 1.8893669 secs]
Total time for which application threads were stopped: 1.9019171 seconds

Hi
before the RBSMaintainer was run against a SharePoint content database (WSS_Content_XYZ) 　for ORPHAN BLOB cleanup, from one of the web front end server and after they make the database Read-only, the RBS storage has nearly
3.5 Million of BLOB files.
The Original_Wss_Content_XYZ database restored from 　　backup of WSS_Content_XYZ database,
if we restore every time the same database I found that BLOBS are deleting from RBS storage.
I open ticket and ask Microsoft support they saying its by a filestream garbage collection and in background its deleting orphan blobs ,
Is it 　the case still this 　background process not deleted the all Orphan BLOBS from this database and its why showing
orphan_cleanup_in_progress = true; and is any way to stop the background process .
for this database is there any way to check
how many Orphans BLOBS actually exists in 　and while it is running or after 　how we can check the history for deleted BLOBS in 　database
adil

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 garbage collection times

Similar Messages

Maybe you are looking for