Native interop with Virtual Threads

[Danish Nawab]

Thanks Ron.

What about native code that doesn’t make an upcall but does a blocking operation directly (via OS syscalls or similar)? Are such cases also rare?

What would be the advice if someone is making blocking calls from their downcalls? It might not always be possible to rewrite it in Java.

If I am reading this correctly [1], it seems like the golang implementation is able to unmount goroutines.

[1] https://stackoverflow.com/a/28354879
________________________________
From: Ron Pressler <ron.pressler at oracle.com>
Sent: Monday, June 26, 2023 5:47:32 PM
To: Danish Nawab <dnawab at outlook.com>
Cc: loom-dev at openjdk.org <loom-dev at openjdk.org>
Subject: Re: Native interop with Virtual Threads

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230626/06cc8e03/attachment-0001.htm>