Impact of setting -XX:+DisableExplicitGC when NIO direct buffers are used

Question

We are building a web application with aggressive performance SLAs which are periodically being violated due to the JVM going out to lunch due to System.gc() calls. We\'ve d

Answer 1

Disabling explicit GCs does not prevent buffers and thus the native memory they hold onto from being collected. But it may delay collections for a long time.

Which means memory allocated by direct buffers may accumulate for a long time before it is collected. In the long run that's not really a leak, but it will increase peak memory usage.

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4a1e42601d61/src/share/classes/java/nio/Bits.java

As I understand it that System.gc() call is there to free buffers when the reserveMemory limit is hit. After reserving the requested amount ByteBuffer.allocateDirect will call to Unsafe.allocateMemory which might do its own GC call, which should not be affected by DisableExplicitGC, if its attempt to mmap fails.

is there at least something we can do to reduce the frequency at which it's called?

It is only called when the MaxDirectMemorySize limitation is hit. If you can tune your GC or application code so that it meets one of the following options:

• it uses a fixed set of buffers (-> limitation will never be exceeded)
• buffers are collected early (shortlived buffers -> die in a young GC)
• the old generation gets collected regularly before direct buffer space runs out
• uses heap buffers instead of direct buffers

then System.gc() calls won't be necessary.

On hotspot there also exists a ExplicitGCInvokesConcurrent option. Maybe IBM's VM has something similar.