[aarch64-port-dev ] RFR: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults

[Nick Gasson (Arm Technology China)]

Hi,

Please review a one-line fix to prevent a JVMTI PopFrame crash on AArch64:

Bug: https://bugs.openjdk.java.net/browse/JDK-8215951
Webrev: http://cr.openjdk.java.net/~njian/8215951/webrev.0/

This jtreg test started intermittently failing on AArch64 with a 
segfault after 8215425:
   http://hg.openjdk.java.net/jdk/jdk/rev/1e213c37befa
(There is a full crash log attached to the bug.)

The faulting instruction is the load of the dispatch table pointer from 
rdispatch (x21) in InterpreterMacroAssembler::dispatch_base.

   0x0000ffff8c939ab8: ldrb   w8, [x22, #0]!
   0x0000ffff8c939abc: add    w9, w8, #0x900
   0x0000ffff8c939ac0: ldr    x9, [x21, w9, uxtw #3]   <------
   0x0000ffff8c939ac4: br     x9

When deoptimising a frame that has a JVMTI PopFrame event pending, 
vframeArrayElement::unpack_on_stack will set the return PC of the 
deoptimised frame to the the interpreter entry point 
remove_activation_preserving_args_entry. After the PopFrame handling 
this calls dispatch_next to dispatch the next opcode, but at this point 
rdispatch may not have been initialised to point at the dispatch table. 
Fix by calling get_dispatch() to initialise rdispatch at the same time 
as the rest of the interpreter state is restored in 
remove_activation_preserving_args_entry.

I guess this has always been a potential problem, but adding the prints 
in the changeset above changed the timing of when a method was compiled 
and exposed it?

Thanks,
Nick