RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop

Nick Gasson nick.gasson at arm.com
Fri Aug 7 09:04:49 UTC 2020


Hi,

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

Running jtreg test vmTestbase/nsk/jdb/pop/pop001/pop001.java with -Xcomp
causes this assertion failure:

  assert(oopDesc::is_oop(obj)) failed: not an oop: 0x0000ffff60b334c0

This test has a sequence of method calls func1(0) -> func2(1) -> ... ->
func5(4) -> lastBreak() with a breakpoint in lastBreak(). func{2..5} are
inlined into func1 when compiled. At the breakpoint the debugger is used
to pop four frames and then continue executing from func2. This causes
func1 to be deoptimized but the recreated interpreter frame for func2
has garbage values in its temporary expression stack (the parameters for
func3), which triggers the above assertion when the invoke bytecode
re-executes.

The outgoing parameters in func2's expression stack should be filled in
when we recreate the locals for func3. But on AArch64 the template
interpreter inserts padding between the locals block and the saved
sender SP to align the machine SP to 16-bytes. This extra padding is
accounted for by AbstractInterpreter::size_activation() but not when
recreating the frame in layout_activation(). This causes the incoming
parameters in the callee frame to be misaligned with outgoing parameters
in the caller frame. This patch fixes that by using the caller's ESP to
calculate the location of the locals if the caller is an interpreted
frame.

Tested jtreg hotspot_all_no_apps, jdk_core plus tier1 with
-XX:+DeoptimizeALot.

--
Thanks,
Nick


More information about the hotspot-compiler-dev mailing list