RFR: Add NMT support for Java heap

[Aleksey Shipilev]

On 12/12/2017 12:20 PM, Per Liden wrote:
> On 2017-12-12 11:50, Aleksey Shipilev wrote:
>> On 12/12/2017 11:42 AM, Per Liden wrote:
>>> As Aleksey noticed, we don't register the Java heap with the native memory tracker. Here's a patch
>>> to do that.
>>>
>>> http://cr.openjdk.java.net/~pliden/zgc/nmt_java_heap/webrev.0/
>>
>> Patch looks good, but the NMT "reserved" data is off the charts:
>>
>> Total: reserved=17180280855KB, committed=17143487KB
>> -                 Java Heap (reserved=17179869184KB, committed=16777216KB)
>>                             (mmap: reserved=17179869184KB, committed=16777216KB)
>>
>> I guess this should not pass ZAddressSpaceSize, and instead tell the reserved space of the first
>> mapping?
>>
>> +  // Register address space with native memory tracker
>> +  nmt_reserve(ZAddressSpaceStart, ZAddressSpaceSize);
> 
> I think this is correct actually. But it depends on how one views things I guess. As I see it, I
> want to be able to look in /proc/../maps and with NMT see what the different mappings correlate to.
> If we only registered the first heap view, then there would be a big mysterious reservation that
> would go unaccounted. That doesn't sound right to me, but I'm open for hearing other opinions on
> this. The big number there covers all addresses for all heap views/mappings (i.e. the actual address
> space that is reserved). It should be noted that, in ZGC, the heap address space doesn't have a 1:1
> relation with max heap size.

In single-mapping GCs with -Xmx100g, I would expect to see reserved=100G for Java heap.

In multi-mapping GCs with -Xmx100g, I would expect to see either reserved=100G, or reserved=N*100G,
where N is the number of mappings.

Looking at /proc for ZGC, it seems we reserve the entire bulk from "lo" of first mapping to "hi" of
the last mapping for Java heap?

VmPeak:	18256719348 kB
VmSize:	18256719348 kB

Oh wow. So NMT is not lying there.

But, this does look overly pessimistic thing to do. If there are multiple mappings that differ in
upper bits, that means there is enough unused space between the mappings, and we don't actually have
to reserve it?

The way I look at it, "reserve" is something that helps to diagnose memory handling problems, and
over-reservation masks most of that. It probably makes sense to commit this NMT patch, and then
figure out if we want to reserve less?

Thanks,
-Aleksey