[aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV

[Dmitry Samersoff]

Stuart,

I can confirm that the patch works in our environment.

-Dmitry

On 13.12.2017 18:56, Stuart Monteith wrote:
> Hello,
>    Here's most latest patch:
> 
> http://cr.openjdk.java.net/~smonteith/8193266/webrev-2/
> 
> Things to note:
>    I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp
> and metaspaceShared.cpp
> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is
> the same value as UnscaledOopHeapMax. Perhaps that should be used
> instead of UnscaledClassSpaceMax in all three places.
>    I'm using the constant in MacroAssembler_aarch64.hpp in the
> MacroAssembler constructor instead of CompressedClassSpaceSize.
>    The calculation has changed - "1u" has changed to "1ul" as the
> address "0x100000000" is not representable as a 32 bit value.
>    The test has changed from ">" to ">=" as the greatest offset for
> 4GB is "0xffffffff", and so 0x100000000 and upwards are all acceptable
> for XORing offsets to.
> 
> The intention is to prevent bad code from being generated if the
> compressed class addresses range changes.
> 
> BR,
>    Stuart
> 
> On 11 December 2017 at 13:54, Andrew Haley <aph at redhat.com> wrote:
>> On 11/12/17 13:43, Stuart Monteith wrote:
>>> I've copied and pasted the calculation for UnscaledClassSpaceMax in
>>> use_XOR_for_compressed_class_base to match the variable of the same
>>> name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces  -
>>> I did this for ease of reference while we decide what to do.
>>
>> Yes, I get that.  I don't want to pessimize the "normal" use of OpenJDK
>> AArch64 for the sake of this weird case.  I guess that as long as no-
>> one explicitly sets the base of the metaspace below 32 bits it doesn't
>> matter anyway.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671