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

Thomas Stüfe thomas.stuefe at gmail.com
Wed Aug 29 09:26:22 UTC 2018


p.s. jdk/submit tests ran through fine.

..Thomas


On Tue, Aug 28, 2018 at 8:05 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> Hello,
>
> may I have reviews please for this tiny fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8210068
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8210068-Unsafe.allocateMemory-shall-not-round-up-user-size/webrev.00/webrev/
>
> In Unsafe_AllocateMemory0(), we align the size requested by the caller
> up like this:
>
>   sz = align_up(sz, HeapWordSize);
>   void* x = os::malloc(sz, mtOther);
>
> This rounding up is unnecessary, since the additional space is not
> needed. I tried to find the reason for that rounding, but it predates
> the start of OpenJDK history.
>
> The problem is that this rounding causes NMT to overreport the numbers
> of mtOther - which contains the nio DirectByteBuffers - the more
> buffers and the smaller they are the more inaccurate those numbers
> become.
>
> Note that even though the numbers are off, little real memory is
> wasted by the alignment. This is probably because the libc malloc
> allocators internally round up allocations to at least pointer sizes
> anyway, or at least waste the trailing bytes of each allocation.
>
> Also note that yes, theoretically we may now uncover buffer overruns -
> program errors which were hidden by the rounding up of the user size.
> In my opinion, if we do, we should fix them. In debug builds,
> os::malloc() and friends have guard fences around the allocated user
> portions, so we should notice. In any case we will run the submit
> tests as well as our suite of nightlies.
>
> Kind Regards, Thomas


More information about the hotspot-runtime-dev mailing list