[aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation

[Andrew Haley]

On 4/29/20 9:51 AM, Nick Gasson wrote:
> For compressed OOPs it makes sense because it allows a larger heap
> without changing the encoding mode.

That's right: I'm looking at AOT-compiled code (after applying your
patch) and by default it uses a shift of 3, no offset. If I then run
the AOT-compiled code with -Xmx31G I get:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffffa142bd3c, pid=9965, tid=10174
#
# JRE version:  (15.0) (slowdebug build )
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 15-internal+0-adhoc.aph.jdk-tmp, mixed mode, aot, tiered, compressed oops, g1 gc, linux-aarch64)
# Problematic frame:
# A 388  java.lang.Thread.setPriority(I)V java.base (56 bytes) @ 0x0000ffffa142bd3c [0x0000ffffa142bac0+0x000000000000027c]

   0x0000ffffa142bd30 <+624>:	ldr	w1, [x4, #56]
   0x0000ffffa142bd34 <+628>:	cbz	w1, 0xffffa142bd84 <java.lang.Thread.setPriority(I)V+708>
   0x0000ffffa142bd38 <+632>:	lsl	x1, x1, #3
   0x0000ffffa142bd3c <+636>:	ldr	w0, [x1, #12]

... so the AOT-compiled code is still trying to use the shift of 3,
but it is not adding in the base, which is 0x1000000000. I guess this
is pilot error, but I'm trying to understand what gets checked and
when.

> But for compressed class pointers we never need to address more than
> 4G so maybe it's better to use 0 shift instead of logKlassAlignment
> above? With CDS the default shared base address is 0x80000000 which
> doesn't allow a zero base anyway.

Maybe. What actually happens when we decode compressed class pointers
in AOT-compiled code is:

Load the klass pointer from an Object:

  532440:       b940082a        ldr     w10, [x1,#8]

Load the compressed class base:

  532444:       90055e68        adrp    x8, b0fe000 <A.meta.got+0x16e000>
  532448:       9104c108        add     x8, x8, #0x130
  53244c:       f9400108        ldr     x8, [x8]

Shift and add:

  532450:       8b2a6d0a        add     x10, x8, x10, uxtx #3

... none of which is very nice, but the expensive part is loading the
compressed classw base and doing the add, so I guess we don't care
that there is a shift as well.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671