JDK-8289128 : Create an "interpreted" version of Continuation.enterSpecial
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 19
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2022-06-24
  • Updated: 2024-01-11
  • Resolved: 2024-01-11
Related Reports
Relates :  
JDK-8288949 - serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing
Description
To properly fix JDK-8288949 (in a way that avoids the possibility of another thread, running concurrently to an interp_only_mode thread resolving the call to Continuation.enter) we should probably have an "interpreted" version of enterSpecial.

There is no need for a special "deoptimization" of such frames, because there's only one call to Java (and one safepoint) from enterSpecial. There's nothing to be done after we return to it.
Comments
RT Triage: closing as WNF based on the Ron's comments.
11-01-2024
This has mostly been resolved by https://github.com/openjdk/jdk19/commit/9a0fa8242461afe9ee4bcf80523af13500c9c1f2 I'm not sure this issue should remain open, but perhaps that fix could be made more elegant.
09-08-2022
That's what we had early on. enterSpecial was created to save us all the trouble that caused. I don't remember all the details, but a continuation entry with an interpreted caller required quite a bit of special casing, and the ability to save a linked list of entries for mounted continuations on the stack ended up being a lot easier than what we had before.
01-07-2022
Dumb question. Can we write a enterSpecial in Java and save ContinuationEntry info in an Object known to the JVM?
30-06-2022