Yes. Yes it is. I'm sorry you're struggling with it.

Thanks for posting this — any chance you can share more specifics on what you were experimenting with, how you did it, level of effort, etc? Sounds fun!

I‘m currently compiling some blog posts about this topic (and probably a video collab) and tinkered with virtual threads in http-kit and core.async today, I hope to publish some of this stuff in the upcoming week

Before that Tweet I patched virtual threads into a Java process engine / workflow engine which spawns threads to execute tasks, and had a lot of tasks with longer, blocking I/O. The effort was rather low, changed the threadfactories from creating new Threads to “Thread.ofVirtual()…” and avoided the Threadpool.

I don't know about biggest high-impact for the JVM. With Kotlin Coroutines you can also do it, plus it's much easier to cancel them.

There are similar concepts in some languages already, but I was focussing the JVM as the platform, not JVM languages. And I am not that familiar with Kotlin, but I was under the impression that you should avoid blocking calls in coroutines?

Relevant: https://twitter.com/BrianGoetz/status/1513162122141839360?s=20

Yes, agree that “increased throughput by x” would have been the better wording

Thanks for instigating the ... thread ..., @javahippie :D Today is learning day! I've only known virtual thready things from a distance.

AFAIK you should also avoid blocking calls in virtual threads.

That’s actually the main feature about them. Virtual Threads get mounted onto Platform Threads to perform work. If inside a thread a blocking syscall is made, it triggers the virtual thread to yield it’s assigned platform thread, making room for other virtual threads to mount. After the blocking call is finished, the virtual thread is assigned to a platform thread again and continues to work. One of the goals is to enable developers to use the “thread per task” programming model instead of async strategies with the same performance and less complexity.

Does this mean that thread pools are/will be deprecated?

Threads and Threadpools will exist in the same way, as they are the underlying technology and still are useful. We will just get virtual threads on top

This guy said that we shouldn't use threadpools and instead should resort to semaphores when using virtual threads: https://youtu.be/6dpHdo-UnCg?t=473

I agree with Nicolai, but still the old API won’t be deprecated 😉 (This is an excellent video, btw).

Anyone remember the post which benchmarked loom?

btw if you want to try virtual threads yourself, I have created a short how-to for setting up your workspace with the JDK Preview Builds: https://javahippie.net/java/concurrency/2022/04/12/getting-started-with-virtual-threads.html

It also works for Clojure projects, e.g. with Cursive

I tried out a deps.edn project with the latest JDK preview build 19-loom+5-429, and I did not seem to need to pass the --enable-preview JVM option to get virtual threads to work. Not sure why that’s the case.