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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Jan 23 23:27:36 UTC 2020


On 23/01/2020 22:59, David Holmes wrote:
> On 24/01/2020 12:41 am, Andrew Haley wrote:
>> On 1/23/20 10:22 AM, David Holmes wrote:
>>> That aside IIRC the overflow check is not ideal here because we already
>>> enter undefined behaviour territory inside align_up if we actually
>>> overflow.
>>
>> How is that possible? size_t is an unsigned type, and unsigned types
>> never overflow.
>
> Yes you are right, I was not recalling the rules correctly. So the 
> addition to the size_t is guaranteed to wrap and so the < test is valid.
>
> Sorry for the noise on that.
>
> It may still be cleaner if the Java side enforces a maximum of 
> Integer.MAX_VALUE for 32-bit.

I have no objections in adding an extra check where the native memory 
segment is created - perhaps we should just do that.

That said, memory segments are not the only clients of 
Unsafe::allocateMemory - so if we decided that overflow is an issue that 
should be handled in clients, fine, but at least it should be evident 
somewhere in the javadoc of Unsafe::allocateMemory?

Maurizio

>
> Thanks,
> David
>
>> On a 32-bit box, 0 <= size < 2**32. So -- in theory at
>> least -- you could allocate more than 2G.
>>


More information about the hotspot-runtime-dev mailing list