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

[Zhengyu Gu]

Hi Thomas,

Apparently, Unsafe.allocateMemory() does have alignment requirement: the 
result address should be aligned to *all value types*. So, it looks like 
align_up() is required to satisfy to the API requirement.


/**
      * Allocates a new block of native memory, of the given size in 
bytes.  The
      * contents of the memory are uninitialized; they will generally be
      * garbage.  The resulting native pointer will never be zero, and 
will be
      * aligned for all value types.  Dispose of this memory by calling 
{@link
      * #freeMemory}, or resize it with {@link #reallocateMemory}.
      *
      * @throws IllegalArgumentException if the size is negative or too 
large
      *         for the native size_t type
      *
      * @throws OutOfMemoryError if the allocation is refused by the system
      *
      * @see #getByte(long)
      * @see #putByte(long, byte)
      */
     public native long allocateMemory(long bytes);


Thanks,

-Zhengyu



On 11/05/2018 02:13 AM, Thomas Stüfe wrote:
> Hi all,
> 
> I am cleaning up my bug queue for 12.
> 
> may I please have reviews for this small fix:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210068
> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210068-Unsafe.allocateMemory-shall-not-round-up-user-size/webrev.01/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 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
> 
> --
> 
> The patch ran through jdk-submit. I will put it through our
> SAP-internal tests to check whether removal of that alignment space
> could possibly trigger any hidden overwrite bugs.
> 
> Thanks, Thomas
>