[aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV
dms at samersoff.net
Mon Dec 18 08:05:43 UTC 2017
I can confirm that the patch works in our environment.
On 13.12.2017 18:56, Stuart Monteith wrote:
> Here's most latest patch:
> 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.
> 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
More information about the hotspot-dev