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