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

Zhengyu Gu zgu at redhat.com
Wed Jun 6 00:58:18 UTC 2018

On 06/05/2018 12:10 PM, Thomas Stüfe wrote:> On Tue, Jun 5, 2018 at 3:46 
PM, Adam Farley8 <adam.farley at uk.ibm.com> wrote:
>> Hi All,
>> Native memory allocation for DBBs is tracked in java.nio.Bits, but that
>> only includes what the user thinks they are allocating.
> Which is exactly what I would expect as a user...

I agree with Thomas, there is no point for a user to aware of tracking 
overhead, and the overhead only incurs when native memory tracking is 
on. As a matter of fact, it can really confuse user that values can be 
varied, depending on whether native memory tracking is on.



>> 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
> which I do not understand either - why do we do this? After all,
> normal allocations from inside hotspot do not get aligned up in size,
> and the java doc to Unsafe allocateMemory does not state anything
> about the size being aligned.
> In addition to questioning the align up of the user requested size, I
> would be in favor of adding a new NMT tag for these, maybe "mtUnsafe"?
> That would be an easy fix.
>> , and
>> something to do with nmt_header_size in os:malloc() (os.cpp) too.
> That is mighty unspecific and also wrong. The align-up mentioned above
> goes into the size reported by Bits; the nmt header size does not.
>> On its own, and in small quantities, align_up(sz, HeapWordSize) isn't that
>> big of an issue. But when you allocate a lot of DBBs,
>> and coupled with the nmt_header_size business, it makes the Bits values
>> wrong. The more DBB allocations, the more inaccurate those
>> numbers will be.
> To be annoyingly precise, it will never be more wrong than 1:7 on
> 64bit machines :) - if all memory requested via Unsafe.allocateMemory
> would be of size 1 byte.
>> To get the "+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.
> I don't follow that.
>> That's only one way to fix the accuracy problem here though. Suggestions
>> welcome.
> You are throwing two effects together:
> - As mentioned above, I consider the align-up of the user requested
> size to be at least questionable. It shows up as user size in NMT
> which should not be. I also fail to see a compelling reason for it,
> but maybe someone else can enlighten me.
> - But anything else - NMT headers, overwriter guards, etc added by the
> VM I consider in the same class as any other overhead incurred e.g. by
> the CRT or the OS when calling malloc (e.g. malloc allocator bucket
> size). Basically, rss will go up by more than size requested by
> malloc. Something maybe worth noting, but IMHO not as part of the
> numbers returned by java.nio.Bits.
> Just my 2 cents.
> Best Regards, Thomas
>> 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