G1 native memory consumption

[Thomas Schatzl]

Hi Milan,

On Fri, 2017-02-03 at 16:22 +0000, Milan Mimica wrote:
> Hi Thomas
> 
> Thanks for your input. I took me a while to have a stable system
> again to repeat measurements.
> 
> I have tried setting G1HeapRegionSize to 16M on one instance (8M is
> default) and I notice lower GC memory usage:
> GC (reserved=1117MB -18MB, committed=1117MB -18MB)
> vs
> GC (reserved=1604MB +313MB, committed=1604MB +313MB)
> 
> It seems more stable too. However, "Internal" is still relatively
> high for a 25G heap, and there is no much difference between
> instances:
> Internal (reserved=2132MB -7MB, committed=2132MB -7MB)

I am not sure why there is no difference, it would be nice to have a
breakdown on this like in the previous case to rule out other
components or not enough warmup.

Everything that is allocated via the OtherRegionsTable::add_reference()
-> BitMap::resize() path in the figure from the other email is
remembered sets, and they _should_ have gone down.

You can try to move memory from that path to the CHeapObj operator new
one. This results in g1 storing remembered sets in a much more dense
but potentially slower to access representation.

The switch to turn here is G1RSetSparseRegionEntries. It gives maximum
number of cards (small areas, 512 bytes) per region to store in that
representation. If it overflows, pretty large bitmaps that might be
really sparsely populated are used (that take lots of time). By default
it is somewhat like 

4 * (log2(region-size-in-MB + 1)

E.g. with 32M region only 24 cards are stored there max. I think you
can easily increase this to something like 64 or 128 or even larger. I
think (and I am unsure about this, in jdk9 we halved its memory usage)
memory usage should be around equal with the bitmaps with 2k entries on
32M regions, so I would stop at something in that area at most.

This size need not be a power of two btw. You can try increasing this
value significantly and see if it helps with memory consumption without
impacting performance too much.

Thanks,
  Thomas