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

[Thomas Stüfe]

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

> 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