[aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV
stuart.monteith at linaro.org
Mon Dec 18 13:41:36 UTC 2017
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.
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
More information about the hotspot-dev