RFR(xs): 8210068: Unsafe.allocateMemory() should not round up requested memory size

[Thomas Stüfe]

Hi Andrew,

On Mon, Nov 5, 2018 at 10:15 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 11/05/2018 07:13 AM, Thomas Stüfe wrote:
> > This rounding is unnecessary, since the additional space is not needed
> > by the caller. In addition, this rounding causes NMT to over-report
> > the numbers of mtOther - which consists mainly of nio DirectByteBuffer
> > related allocations - the more buffers and the smaller they are the
> > more inaccurate those numbers become.
> >
> > --
> >
> > This bug has been originally reported by Adam Farley, see fragments of
> > a scattered discussion on core-libs:
> >
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054412.html
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054797.html
>
> I don't believe that this change is useful. Any realistic malloc()
> will round the allocated memory size anyway, and the current behaviour
> more realistically answers the "Where did my memory go?" question.
>

I agree that this is not a "real" memory leak. But still think this
should be fixed;

For answering  "Where did my memory go" this is a poor solution. On
the way down the OS a lot of wastages happen, some directly tied to
this allocation, some more indirect. Adding malloc alignment
requirement to the user size arbitrarily adds only one small part of
the real wastages while leaving others out:

- in the VM: wastage for NMT malloc headers, waste for associated NMT
data structures, waste (debug builds) for leading/trailing canaries in
os::malloc()
- libc: other waste associated with allocations, e.g. for glibc unused
memory in the thread arena, free chunks, fragmentation in the top
chunk -  I am not a glibc expert but I believe there is more waste
than just malloc alignment.

My point is that I rather have a number reporting something exactly
("how much memory did we alloc via DBB") then something fuzzy and not
really useful ("how much memory did we alloc via DBB plus some minor
part of the wastage").

Another argument is that this aligning-up is not done consistently: I
do not see this done on any other os::malloc call. So, while the other
mtXX categories in the NMT report th eprecise size of user memory, for
mtOther we report a bit more.

A third argument is that this alignment causes mtOther numbers to
differ from nio.Bits, which was confusing.

Cheers, Thomas

> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671