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

[Stuart Monteith]

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