Why isn't -XX:+ExplicitGCInvokesConcurrent the default when using the G1 collector?

Question

In the context of an in-memory database, we are using off-heap memory in conjunction to the G1 collector of hotspot.

However, when off-heap memory usage reaches MaxDirectMemorySize, a full GC is triggered by the JDK code using System.gc(). This causes a long and painful stop the world GC, that also seem to put all the current live set in the old gen, bypassing the survivor (and thus increasing nepotism issues). This does not happen when setting -XX:+ExplicitGCInvokesConcurrent: the GC is much faster and respects the survivors.

Since System.gc() is something used internally by the JDK, why isn't this option on by the default in hotspot? Does this flag induce theoritical or practical issues? Or is just for compatibility reasons? Does anybody has experience of using this option in a production environment, and encountered issues with it?

Draughtsman

Answer 1

From what it seems, the JDK folks have not answered this question yet either (see the comment of Charlie Hunt on JDK-8071770).

The only drawback that I found about using this option so far is the fact that by default a concurrent GC does not unload classes (see JDK-6541037). But if this is your issue, you can use -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses instead.

Edit 2017: A specific ticket with the same question has been open for jdk10: JDK-8160392

Draughtsman

I've just found a case where G1 garbage collection ignores the ExplicitGCInvokesConcurrentAndUnloadsClasses argument unfortunately -- since G1 will do class unloading, better to do ExplicitGCInvokesConcurrent – Collett