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

Andrew Haley aph at redhat.com
Sat Dec 9 11:37:15 UTC 2017


On 08/12/17 19:07, Stuart Monteith wrote:

>    The Aarch64 backend decompresses klass pointers using XOR if the
> size of the compressed classes space is less then the base address.
> However, in JDK 10  CompressedClassSpaceSize doesn't represent the
> range of the compressed shared classes area, which is set to 4GB.
>    https://bugs.openjdk.java.net/browse/JDK-8193266
>    http://cr.openjdk.java.net/~smonteith/8193266/webrev/
> I've speculatively put up a patch which deals with the issue on
> Aarch64. While I understand the problem with the generated aarch64
> code, I don't believe understand the CDS code sufficiently at this
> point to determine if there is a bug within the CDS code regarding the
> CompressedClassSpaceSize parameter.

Good catch!

Hmm.  This sort-of papers over the problem, in that it disables XOR-
encoding of class metadata.  I would have thought it makes more sense
to set narrow_klass_base high enough so that this does not happen.  We
really want narrow_klass_shift to be zero if we can, which should be
OK if the shared klasses are in a 4G range.

I think that I see the logic of your patch, but I think it's a very
complicated way of saying

  if (narrow_klass_base() > 1ul << 32 << narrow_klass_shift())

Also, beware of putting any more complexity into
use_XOR_for_compressed_class_base because it's executed very often.
We should perhaps do it once, when we allocate the metaspace.

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 mailing list