Native interop with Virtual Threads

[Ron Pressler]

Virtual thread stacks move around in memory, as they’re stored in the Java heap. Frames of native code are hard to move around because they may contain pointers into the stack itself, which Java doesn’t know about. Because it isn’t much of a problem in practice — “upcalls" from native code to Java are rare in general, and blocking operations in upcalls are rarer still — it isn’t a challenge worth solving at the moment.

— Ron

> On 26 Jun 2023, at 10:22, Danish Nawab <dnawab at outlook.com> wrote:
> 
> Both the JEP [1] and the original Loom proposal [2] state that running native code will pin the virtual thread to its carrier.
> 
> I am curious to learn more about the reasons and implementation challenges that cause this limitation. Does it have something to do with how the native code is managed by the JVM? Could you please point me in the right direction? 
> 
> [1] https://openjdk.org/jeps/444
> [2] https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html