project-loom-c5m VS remove-recursion-inspection

It is not. Blocking IO (with some exceptions mentioned in the JEP) will automatically be translated by the runtime into non-blocking IO when it occurs on virtual threads, and no OS threads will be blocked. You can have a million threads blocking on a million sockets (obviously without creating a million OS threads): https://github.com/ebarlas/project-loom-c5m

You can't do that with thread pools. You could achieve that scalability with async code, but then observability tools will not be able to track the IO operations and who initiated them, but with virtual threads you'll see exactly what business operation is doing what IO and why.

That might change in JDK 21 (with virtual threads). See this https://github.com/ebarlas/project-loom-c5m . It achieve 5 million persistent connections (again depends on the server capacity and kernal tuning) using normal simple blocking code (https://github.com/ebarlas/project-loom-c5m/blob/main/src/main/java/loomtest/EchoServer.java) . It's a far better better programming model compared to JS async/await.

Thanks for posting that link to Java tail recursion library, super handy + didn't know about it. You need tail recursion for writing expression evaluators/visitors frequently.

I've been using an IntelliJ extension that can do magic by rewriting recursive functions to stateful stack-based code for performance, but it spits out very ugly code:

https://github.com/andreisilviudragnea/remove-recursion-insp...