Skip to main content

Memory leak in G1 garbage collector

2 replies [Last post]
Joined: 2005-10-25
Points: 0


I am trying out the G1 collector to hopefully get rid of our problem of fragmentation causing CMS collector to perform full 'stop-the-world' GC from time to time. In our production environment it occurs once every 1 1/2 month or so, but is devastating since it is blocking our entire server application for 9 seconds (4GB heap) when compacting the heap due to the (not so well documented) ParNew (promotion failed) occuring. This happens when the old generation is so fragmented that CMS cannot find enough contigous space causing forcing a full heap compaction to occur.

Sadly, in our labs, when activating the G1 collector (running on JDK 1.6.0_18_ea), it incrementally expands it's memory usage until the system's resources are fully exhausted.
Reading the gc log output, it claims to use no more than the 2GB max I have assigned to it (-Xmx2g), but the OS (64-bit Windows Vista) keeps allocating more and more memory to the process until almost all 8 GB are utilized by the java process. Is this leak well known and is there a way round it? (I will download and try with JDK 1.7 ea as well and see if it exhibits same behaviour).

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-10-25
Points: 0

The memory leak was fixed in Java SE 6 Update 18 b05. Thanks :-).

Still, the JVM crashes when running with the G1 collector, though. Has reported crash bugs using the official bug reporting tools. Anyone able to run with G1 collector (as of JDK 1.6_18 b05?)

Joined: 2009-12-03
Points: 0

I have experimented with various versions of the G1 collector.

The latest problems I have with the java6u17 look like so:
at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.updateCheck(
at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.compareAndSet(
at java.util.concurrent.ConcurrentSkipListMap$Index.casRight(
at java.util.concurrent.ConcurrentSkipListMap$Index.unlink(
at java.util.concurrent.ConcurrentSkipListMap.findPredecessor(
at java.util.concurrent.ConcurrentSkipListMap.doPut(
at java.util.concurrent.ConcurrentSkipListMap.put(

That ain't not so good. So java6+G1 = not usable.

Java7 is better, but I get segfaults in after a while.

In the brief time that I have run the G1 GC I am finding it fairly slow - pauses in the 50-150ms every few seconds = not so great. I'd prefer to see 10-20ms pauses every second or so. Every time we pause for 150ms that is a request getting not serviced for 150ms!

At least there is no chance for a CMS failure - which takes anywhere between 40 second to 5 minutes in the scenarios I've seen.