Use Virtual Threads when on JDK 24+

[SentryMan]

• Use Method Handles to invoke Thread.ofVirtual().name(threadBaseName, 0).factory() when on jdk 24+.
• create a new class VirtualExecutor to reflectively create thread per task executors
• replace non scheduled thread pools with virtual thread executors

part of #53

[corite]

I've had a quick look over your proposed changes (note that I'm not very familiar with kwik as a project, but I have worked quite a bit with VirtualThreads). I think the changes look good, as far as that it shouldn't break anything, but I think it falls a bit short conceptually. Currently the factory which you have changed supplies several ThreadPools in kwik. Generally speaking, you should never pool VirtualThreads, because pooling as a concept only makes sense for expensive resources. A PlatformThread (i.e. a normal OS thread) is an expensive resource, a VirtualThread however is not (the bookkeeping effort of pooling the thread may very much outweigh to cost of creating a new one). So in my opinion, if you want to introduce VirtualThreads, you should also adapt the ThreadPools which consume them (i.e. probably just make them non-caching in JDK24+).

You also don't have to take my word for this, the original JEP which introduced VirtualThreads in JDK 21 already makes that argument. It also goes into quite some detail about what the mental model for this feature is, and even though some things (mostly limitations like monitor pinning) have changed since JDK 21, I think it still gives a good birds-eye view of the whole situation. I think it's definitely worth a read if your looking to implement something on top of VirtualThreads.

(this is not meant as criticism, I was just pinged by your issue comment and wanted to offer my two cents on the topic :) )

[SentryMan]

the factory which you have changed supplies several ThreadPools in kwik

Yeah I was going to do a follow up to modify all of those cached threadpools into thread per task executors. For the scheduled executors I figured there was no harm in using a virtual thread factory,.

[SentryMan]

though I suppose there is no need to wait

[SentryMan]

@ptrd what do we think about this?

[ptrd]

Sorry, very busy a.t.m., will look at it later.

[SentryMan]

Understandable, have a nice day

[ptrd]

Thanks for this contribution.

Great that you took the effort to make it still compile and run on Java 11.
But even for newest Java versions, I think that running with virtual threads should be optional and must be enabled by setting a feature flag like -Dtech.kwik.core.virtualThreads=true. Especially because we still need to find out how well it works. Virtual threads cannot be pre-empted, so in theory (if we'd use virtual threads for the server connection itself also, so below) it could lead to different behaviour on platforms that has limited number of cores, e.g. connections stalling because they don't get cpu....

Currently, you're using virtual threads only for the sharedExecutor in the ServerConnector. Is this on purpose, or just a first step? There are a few other executors and what about the thread created in ServerConnectionThread?

And I'm still thinking about what to do with the scheduledExecutors. Some people suggest it should only be used for triggering only and delegate the work to a virtual thread....

[SentryMan]

Dtech.kwik.core.virtualThreads=true

feels kinda yucky, I'm used to the other way, where you have a flag to disable. Servers like jetty tend to enable them by default.

There are a few other executors and what about the thread created in ServerConnectionThread?

I don't know the codebase that well, so I just changed wherever I saw them. let me know of any ones I missed.