RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp
Alex Menkov
alexey.menkov at oracle.com
Mon Nov 26 19:14:00 UTC 2018
Hi all,
Please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8195639
webrev:
http://cr.openjdk.java.net/~amenkov/popframe009/webrev.01/
Description:
The test suspends a thread, turns on single stepping and then calls
PopFrame. SingleStep event is expected as soon as the thread is resumed
and PopFrame is processed (so we have call stack with the depth 1 less
than it was before PopFrame). Instead SingleStep event is received with
much deeper call stack (and PopFrame processes wrong frame).
Research shown that this is caused by missed deoptimization of the
current frame.
As far as I understand CompilationPolicy::event should handle the case
when the thread has is_interp_only_mode() set, but
TieredThresholdPolicy::event checks this only then CompLevel is
CompLevel_none.
CompilerRuntime always calls policy()->event with CompLevel ==
CompLevel_aot.
The fix looks quite simple, but I'd appreciate feedback from runtime and
compiler teams as I'm not sure I completely understand all the details
of the "PopFrame dance".
--alex
More information about the serviceability-dev
mailing list