RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing

[Dean Long]

On Fri, 24 Jun 2022 09:23:26 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.

src/hotspot/share/code/compiledMethod.cpp line 464:

> 462:   while(iter.next()) {
> 463:     if (iter.type() == relocInfo::static_call_type) {
> 464:       iter.reloc()->clear_inline_cache();

This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode.  If this was being done at a safepoint then it would probably be OK.  However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351).

src/hotspot/share/runtime/mutexLocker.cpp line 287:

> 285:   def(JfieldIdCreation_lock        , PaddedMutex  , safepoint);
> 286: 
> 287:   def(CompiledIC_lock              , PaddedMutex  , nosafepoint-1);  // locks VtableStubs_lock, InlineCacheBuffer_lock

Please explain.  Is there another lock causing problems?

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

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