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
