RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]

[Erik Österlund]

On Thu, 22 Oct 2020 08:42:40 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Stack frames are counted beginning at 0. The top frame has depth 0. So object deoptimization happens in the top frame.
>> 
>> Still the used method is not optimal because it assumes that objects of frames within the given depth are accessed and their escape state is changed. But potentially caller methods optimized on the escape state therefore it searches for caller frames passing ArgEscape objects and deoptimizes these too. With ForceEarlyReturn no objects are accessed but it is so uncommon that I did not bother optimizing this. Should I?
>
> @robehn you haven't messed up. Hope I havn't either. I've tested
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg:hotspot_serviceability     197   197     0     0   
>    jtreg:test/jdk:jdk_svc                             1176  1176     0     0   
>    jtreg:test/jdk:jdk_jdi                              174   174     0     0   
>    jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdi        1141  1141     0     0   
>    jtreg:test/hotspot/jtreg:vmTestbase_nsk_jvmti       648   648     0     0   
>    jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdwp        113   113     0     0   
> ==============================
> TEST SUCCESS
> jdk_jdi now includes jdk/com/sun/jdi/EATests.java which tests PopFrame/ForceEarlyReturn with object reallocation with and without reallocation failures.

Ah. I see now the loop uses <= instead of <. So my reasoning was right but off by 1. Passing in 0 really means deopt 1 frame. Which means everything is fine and working the way I expect it to.

-------------

PR: https://git.openjdk.java.net/jdk/pull/729