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
