[External] : Re: Native interop with Virtual Threads

[robert engels]

I would also argue that 99% (more?) of the common system calls used in an application are handled directly - that is they are turned into asynchronous calls by the JVM and the virtual thread properly moved off the carrier to allow another virtual thread to run.

Otherwise virtual threads would only affect cpu bound workloads - and then any context switching - user or OS is extremely expensive.

Virtual threads should only be used with workloads that do IO - if they don’t you should be using a thread pool for optimum performance.


> On Jun 27, 2023, at 9:56 AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> I would review the Go impl/docs I linked to. They did a lot of analysis - this is probably never worth it. If the bulk of the Java process is executing in C code you’re probably better off rewriting that in Java. 
> 
>> On Jun 27, 2023, at 9:09 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 27/06/2023 00:11, Robert Engels wrote:
>>> Go also locks the carrier thread in this arbitrary native case - and simply spawns a new one if needed.
>>> 
>> With virtual threads then this kind of thing would be possible if some of the interface to the scheduler were exposed. In particular the exploration into custom schedulers might have to expose some way to temporarily compensate for pinned threads. As Ron said, we haven't seen too many cases where there are upcalls from native code and where the Java code blocks. The other scenario of a downcall that blocks in a syscall is a lot more likely.
>> 
>> -Alan