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

Adam Farley8 adam.farley at uk.ibm.com
Mon Apr 16 10:46:00 UTC 2018

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 alignup(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

More information about the hotspot-dev mailing list