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

[Adam Farley8]

Hi Andrew,

If you are asserting that it is correct that we modify the amount of 
memory allocated,
then would you agree that my proposed solution (where an internal variable 
is
used in Bits to store the actual amount of memory used) is the preferred 
solution?

To recap, my proposed solution to this problem was to create a native 
function
to determine how much memory should need to be allocated if x was 
requested.
This function would be used by both the vm during memory allocation, and 
also
the Bits class when determining how much memory is actually being 
allocated
for a DBB.

The latter would store this number in a non-accessible Bits-internal 
variable, to 
leave Bits' current behaviour unchanged, while still allowing debuggers 
access 
to an accurate measure of how much native memory has been used for DBBs.

Best Regards

Adam Farley 


Andrew Haley <aph at redhat.com> wrote on 05/11/2018 09:15:36:

> From: Andrew Haley <aph at redhat.com>
> To: "Thomas Stüfe" <thomas.stuefe at gmail.com>, Hotspot dev runtime 
> <hotspot-runtime-dev at openjdk.java.net>
> Cc: Adam Farley8 <adam.farley at uk.ibm.com>
> Date: 05/11/2018 09:16
> Subject: Re: RFR(xs): 8210068: Unsafe.allocateMemory() should not 
> round up requested memory size
> 
> 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:
> > 
> > INVALID URI REMOVED
> 
u=http-3A__mail.openjdk.java.net_pipermail_core-2Dlibs-2Ddev_2018-2DJuly_054412.html&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=IZE-
> GixYgHksN0LdNPqRPi3xLv-
> BFKr_aTrFBaJTZ0g&s=Sfk4Crw89zjOYCN1xAZLtpvAm1qVXK-WDp6y4LHiCTM&e=
> > INVALID URI REMOVED
> 
u=http-3A__mail.openjdk.java.net_pipermail_core-2Dlibs-2Ddev_2018-2DAugust_054797.html&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=IZE-
> GixYgHksN0LdNPqRPi3xLv-
> BFKr_aTrFBaJTZ0g&s=8G2dIVCS3SMrl5AlLRjTqSXHAnpPo1SXT7_URU8pCTc&e=
> 
> 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.
> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <INVALID URI REMOVED
> u=https-3A__www.redhat.com&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=IZE-
> GixYgHksN0LdNPqRPi3xLv-
> BFKr_aTrFBaJTZ0g&s=e-6nvns3cneo2Ucmvd8vEsPxAmyeXFepubXHmjylcCY&e=>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

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