cask
cask copied to clipboard
Use Java Virtual Threads (Loom) (500USD Bounty)
Spawn a virtual thread for each incoming request, which would enable asynchronous behaviour and increase performance of the library. The new Java virtual threads are lightweight and can replace the traditional Java threads. Given that Cask does not have any strong async/concurrency model of its own, leveraging the new JVM feature would be really nice.
Haoyi: To incentivize contribution, I'm putting a 500USD bounty on resolving this ticket. This is payable via bank transfer, and at my discretion in case of ambiguity. The acceptance criteria is a PR implementing support for virtual threads, tests exercising them, and performance benchmarks (ad-hoc is OK) demonstrating a performance improvement (e.g. in high concurrency use cases) vs normal threads in Java 21+
I can create a PR for this if this seems like a good idea to @lihaoyi
Go for it, though note we'll need some compatibility story for Java <21
Is this something that https://github.com/com-lihaoyi/cask/pull/74 unblocks?
I would recommend against this until JAVA-23 is released, du to the "pinning issue", effectively making Virtual Threads useless if your code/libs uses synchronized a lot.
https://www.infoworld.com/article/3713220/java-virtual-threads-hit-with-pinning-issue.html
Doing it opt-in should be fine. We can run benchmarks etc. without synchronized to see the benefit. That way we can be ready on day one when Java 23 lands with a fix to the thread pinning issue.
I have done this at $work for all my services, with Java 21, it works fine, no need to delay to Java 23.
If there are issues because of undertow, you may consider switching to Helidon, which is the new web server from Oracle, built for working with virtual threads.
https://helidon.io
https://github.com/helidon-io/helidon/tree/main/webserver
https://central.sonatype.com/artifact/io.helidon.webserver/helidon-webserver/overview
https://javadoc.io/doc/io.helidon.webserver/helidon-webserver/
FYI for anyone reading, this bounty is still open in case anyone else wants to take a crack at this
@lihaoyi Since I started this issue, I am going to finish it too. :)
while building cask, twirl throws java.lang.reflect.InvocationTargetException
while building cask, twirl throws java.lang.reflect.InvocationTargetException
I get that too when building on JDK >= 21. Maybe the newer 2.0.x works better.
Looks like it wasn't twirl afterall (probably, just a cached coincidence when I switched JDK version). See #154.
@sorumehta @jodersky I bought a MacBook for this :) .
@sideeffffect As all the dispatching layers are done in cask, I think Netty/Vert.x is an option, too?
@sorumehta BTW, I was superized by the performance, which is quite good, at least many systems only have < 1qps.