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

[Stuart Monteith]

Hello,
   I've redone the patch such that we're passing different values
depending on whether we are dumping or are using shared classes. There
is a point before this initialisation where the  default is used,
which is 4GB:

http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/


BR,
   Stuart

On 18 December 2017 at 13:41, Stuart Monteith
<stuart.monteith at linaro.org> wrote:
> Ok, the constant was just an attempt at reducing the likelihood of the
> backend generating bad addresses if the range changes. We have a
> testcase that might trip if the future changes.
>
> We'll need the 4GB limit during dumping the shared metaspace. During
> runtime, we'll need the maximum size of the compressed metaspace. I
> suppose that's the intention behind using CompressedClassSpaceSize.
> I've just been checking to see if that still holds.
>
> BR,
>    Stuart
>
>
> On 18 December 2017 at 09:15, Andrew Haley <aph at redhat.com> wrote:
>> On 13/12/17 15:56, Stuart Monteith wrote:
>>>    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.
>>
>> I don't thing that really helps.  We don't need a global constant
>> which is the worst possible case for UnscaledClassSpaceMax because
>> we already know what that is: it's 2**32.
>>
>> We need to know how much space is in use.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671