System.gc() causes for jcl (BufferPoolMXBean)

Bernd Eckenfels ecki at
Sat Jun 6 17:07:07 UTC 2015


I noticed that when you set MaxDirectMemorySize the NIO buffers are
keeping track (Bits.reserveMemory). Since they do not get cleaned
immediatelly they do not only fail to allocate, but before that sleep a
small time and then request system.gc.

It is unfortunatelly not visible anywhere which System.gc() was caused
by this, and it is also not visible how many of those space-reclaim
issues occured (at least not in JMX).

I wonder two things

- would it be possible to have an alternative gc()
method exposed to those places (I would have said Unsafe.gc(String
cause) owever as you are phasing out Unsafe an alternative place might
be needed. I can imagine other places in the JCL (DGC?) would benefit
from that as well.

- why is BufferPoolMXBean not tracking allocation failures, allocation
  count, alignment flag and maximum size (maybe even modifyable). Would
  it be worth to contribute something in this area or is that supposed
  to be covered by some events (and if yes, when will they be exposed
  to JMX).

This would not improve the DirectBuffer situation but it would make its
behaviour more monitoreable.


More information about the hotspot-gc-dev mailing list