Article about JRockit's garbage collectors and expirience of using it for large heap size.
In this article I would like to elaborate on the garbage collection specifics of Oracle's JRockit JVM. Recently JRockit has been made free for use and many people may consider using it instead of another widely popular Oracle JVM - HotSpot (former Sun's JVM).
JRockit uses mark-sweep-compact (MSC) as its base garbage collection algorithm, though it allows a lot of tweaking. The JVM command line option -Xgc: allows to choose variations of MSC algorithm.
Full text of article is available at JavaLobby
http://java.dzone.com/articles/jrockit-gc-action.
Posts
Hi,
ReplyDeleteThis post is really good! Thanks...
I hope u can help me on a problem im having...
Im facing this very strange OOM problem with a 12GB heap, using gen parallel collector.
The system do pretty good as i can see on the GC logs for some days sometimes we dont see any problem in a week... but at some point Right after getting one ugly pause (the reason of the ugly pause is External Compaction->Moving Objects) the system just not able to release any memory, triggers a lot of OC and in less than 2 minutes throws OOM.
The Heap shows fragmentation issues since i see the nursery parts to be so many in order of 100,000, so i would expect to have this big pauses because of fragmentation.
What my problem really is, That JVM is throwing an OOM because after that pause it seems not able to recover any memory. This happen very suddenly and i dont think there is any leak or not enough heap since the system does pretty good for most of the time, previews to this issue i see the heap usage go down to 2.5gb all the time taking almost no time.
A second problem i have and im trying to investigate if it may be related to the pause time issue, is that when jvm generates a heap dump on the OOM, the heap dump only contains 2.5gb of memory used, im struggling trying to understand what is going on here, any comments are high appreciated.
Jonathan
Hi,
ReplyDeleteThis looks like a fragmentation problem. You have only 2.5 gb of live objects but free space is too fragmented. Incremental compaction in JRockit is fairly bad so after short time it just give up and throw OOM.
You can try to increase portion of heap compacted during each OC (e.g. 20% of heap).
I have no better ideas unfortunately. Indeed, your case looks weird.