G1 native memory consumption

[Milan Mimica]

Hi Thomas

> 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.

At least native memory is stable now. That's what I was aiming for. Attached are two graphs. This is after 5 days uptime, high load. With G1HeapRegionSize 16M.
Note that the graph is showing alive memory allocations for which allocation happened in last:
izd2.svg -- 36 hours
izd3.svg -- 10 hours

As you can see, not much going on in last 10 hours. That's great! It's stable.

Still, native memory usage is relatively high, but that's not a big problem for me.

Java Heap (reserved=25600MB, committed=25600MB)
Internal (reserved=2144MB, committed=2144MB)
GC (reserved=1166MB, committed=1166MB)

I'll look at the rest you wrote some later day.


Milan Mimica, Senior Software Engineer / Division Lead
________________________________________
From: Thomas Schatzl <thomas.schatzl at oracle.com>
Sent: Wednesday, February 8, 2017 17:06
To: Milan Mimica; hotspot-gc-use at openjdk.java.net
Subject: Re: G1 native memory consumption

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: izd2.svg
Type: image/svg+xml
Size: 47136 bytes
Desc: izd2.svg
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20170208/92918488/izd2-0001.svg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: izd3.svg
Type: image/svg+xml
Size: 92803 bytes
Desc: izd3.svg
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20170208/92918488/izd3-0001.svg>