Native methods and virtual threads

[Attila Kelemen]

The assumption here is that what you are wrapping into such a call is often
slow, otherwise there is no problem to talk about, and you just wouldn't
wrap it in such a call.

The problem with exposing such a class is that it will bind the future
development of the JVM, because if people start to optimize their code to
it (even indirectly through a framework), and then in a later version of
the JVM there would be an overall better way, then they can't easily add
it, because everybody would be upset, if their code becomes worse after
upgrading to Java Many (even if after small code/framework upgrade it would
be considerably better). So, it is perfectly understandable that it is not
the first choice they want to do.

Brian S O'Neill <bronee at gmail.com> ezt írta (időpont: 2023. júl. 15., Szo,
0:32):

> How would a call like `NativeUtils.runBlocking(() -> mytask())` be
> implemented? By using a thread pool / message queue / FJ pool? In doing
> so, I've introduced a context switch. If the native method didn't
> actually block, then I just added a context switch for no good reason.
>
> Internally, the JDK uses a special Blocker class to handle this case.
> The nice thing is that it doesn't introduce an extra context switch or
> heap allocation.
>
> The whole point of this entire message thread is to ask for a simple
> feature in which native threads can indirectly utilize this special
> class (or whatever is best suited) and keep things simple. As virtual
> thread support evolves over time, I don't need to change my code.
>
> On 2023-07-14 03:14 PM, Attila Kelemen wrote:
>
> >
> > As for " Sometimes I can use virtual threads, and sometimes I need to
> > use a regular FJ pool": It wouldn't be like that, because only the
> > operation which is slow and pinning (and not compensated) should be just
> > written like this: `NativeUtils.runBlocking(() -> mytask())`, instead of
> > just writing `mytask()`. It would never be a choice between do I start a
> > VT or submit it to a thread pool? And presumably this is not the
> > majority of your code. And that is what you would gain, that you still
> > are mostly using VT, only those special pinning methods are not.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230715/4248112f/attachment.htm>