Some generic questions about the virtual thread.

[Mike Hearn]

In JEP 491<https://openjdk.org/jeps/491>, I could see the in-depth detail of the reason behind pinning for synchronized cases. Could someone share what would be the reason behind pinning in case of the JNI method invocation? I could see the JEP mentions `presence of native frame on stack` . Therefore, I am guessing it’s something around that but if someone could give a bit more detail about it that would  be helpful.

Native frames can’t be supported because Loom works by unwinding the stack into the heap (roughly speaking). Doing that requires metadata describing what’s on the stack and where, which has to be produced by the JIT compiler. Native frames were produced by a non-JVM compiler and lack that metadata, so can’t be unwound. The compiler is also expected to do some other things to coordinate with the JVM runtime.

Theoretically this can be solved either by:


  1.  Having a native code compiler that produces the same kind of code and the same kind of integrations as C1/C2/Graal does.
  2.  Compiling the native code just-in-time using the JVM JIT compilers too, from e.g. LLVM bitcode. Sulong is an implementation of this approach.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241111/0a5b0265/attachment.htm>