[PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

[Adam Farley8]

> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter, 
>> 
>> I see that native memory is tracked in java.nio.Bits, but that only 
includes what the user thinks they are allocating. 
>> 
>> When the VM adds extra memory to the allocation amount this extra bit 
is not represented in the Bits total. 
>> A cursory glance shows, minimum, that we round the requested memory 
quantity up to the heap word size in 
>> the Unsafe.allocateMemory code, and something to do with 
nmt_header_size in os:malloc() (os.cpp) too.
> Is the align_up(sz, HeapWordSize) really causing an issue?

Coupled with the nmt_header_size business, it makes the Bits values wrong. 
The more DBB allocations, the more 
inaccurate those numbers will be.

> 
> We could change Bits to align with HotSpot. The BufferPoolMXBean API 
allows the capacity and memory usage to differ (when we originally added 
this, direct buffers were page aligned) so doing this would mean it more 
accurately reflects the memory allocated to direct buffers.
> 
> -Alan

I agree with you that the "+x" information should be added to only one of 
the two atomic longs.

To get "X", it seems to me that the best option would be to introduce an 
native method in Bits that fetches
"X" directly from Hotspot, using the same code that Hotspot uses (so we'd 
have to abstract-out the Hotspot logic
that adds X to the memory quantity).

This way, anyone modifying the Hotspot logic won't risk rendering the Bits 
logic wrong again.

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU