[jdk19] RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2]

[Robbin Ehn]

On Sat, 25 Jun 2022 01:23:47 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Please review the following bug fix:
>> 
>> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
>> 
>> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
>> 
>> This change does three things:
>> 
>> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
>> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
>> 3. In interp_only_mode, the c2i stub will not patch the callsite.
>> 
>> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
>> 
>> 
>> Passes tiers 1-4 and Loom tiers 1-5.
>
> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Remove outdated comment"
>   
>   This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe.

Handshakes are per thread serialization points, so as Erik says, the thread going to interp mode will pick up the correct code, but other threads may or may not see it.
Lock rank change may be okay, to much code to trace just say yes for me.

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

PR: https://git.openjdk.org/jdk19/pull/66