RFR: 8237521: Memory Access API fixes for 32-bit

David Holmes david.holmes at oracle.com
Thu Jan 23 07:46:45 UTC 2020


Hi Nick :)

On 23/01/2020 5:25 pm, David Holmes wrote:
> On 23/01/2020 5:08 pm, Nick Gasson wrote:
>> Hi Maurizio,
>>
>> Yes, for jdk/jdk. Do I need another Reviewer?
> 
> Yes - specifically you need a reviewer from Hotspot! cc'ing 
> hotspot-runtime-dev :)

So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed 
for by the jlong size variable. On 64-bit overflow is not possible 
because jlong is signed and size_t is not.

So we only need an overflow check on 32-bit.

But your checks don't look correct to me. If size is already aligned to 
HeapWordSize then "sz < (size_t)size" won't be true but you already have 
a completely bogus value for sz when you truncated size to 32-bits.

Cheers,
David

> Cheers,
> David
> 
>>
>> Thanks,
>> Nick
>>
>>
>> On 01/22/20 20:46 pm, Maurizio Cimadamore wrote:
>>> Fixes look good to me - I assume this is for JDK 15, right?
>>>
>>> Maurizio
>>>
>>> On 22/01/2020 08:43, Nick Gasson wrote:
>>>> Hi,
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
>>>> Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/
>>>>
>>>> This is a follow-up to JDK-8236634 which just contained changes to the
>>>> tests to make them build/pass on 32-bit systems for JDK 14. This patch
>>>> removes the test workarounds and fixes two things to make them pass:
>>>>
>>>> * In Unsafe_AllocateMemory0 handle the case where the aligned-up size
>>>> overflows a 32-bit size_t and throw an OutOfMemoryError instead of
>>>> calling os::malloc(0).
>>>>
>>>> * Change the value of Utils.MAX_ALIGN from 16 to 8 on 32-bit systems,
>>>> as malloc can return addresses that are only 8-byte aligned.
>>>>
>>>> Tested jdk_foreign on x86_32, arm32, aarch64, x86_64.
>>>>
>>>>
>>>> Thanks,
>>>> Nick
>>


More information about the hotspot-runtime-dev mailing list