I did some similar testing a few days ago[1]. Comparing platform threads to virtual threads doing API calls. They mention the right conditions like having high task delays, but it also depends on what the task is. Threads.sleep(1) performs better on virtual threads than platform threads but a rest call taking a few ms performs worse.
I suppose that a hard limit on the number of carrier threads is a sensible choice then - deadlock is better than creating threads until the system grinds to a halt.
But then again, why couldn't scheduler detect a deadlock? Go has a system in place that, in case of total program deadlock, prints out an error message with all goroutines' stack traces, and stops the program. Perhaps Virtual Thread Scheduler could do the same thing?
But then again, Java also allows for native threads to run in parallel to Virtual Threads, which makes it impossible to detect whether there's a deadlock, and not just virtual threads waiting on a native thread.
I suppose this is a very good example why simple is better than complex.
I have been writing for my personal blog now for a year. The time spend writing and editing does feel worth it. My writing is a lot better than it was a year ago.
It helped me to get noticed at my work and to make new connections.
You will always learn something about the stuff you write. To write better, some new way of doing something, or something from the comments.
I run my blog through cloudflare pages. I only have to push a new markdown file to github and the Hugo template and cloudflare do the rest. Took only a few hours to setup correctly.
> You will always learn something about the stuff you write. To write better, some new way of doing something, or something from the comments.
This. While you try to explain something to the potential reader, you will notice some holes in your own understanding. Teaching/explaining helps you become better at something.
The goal is to bring fast random read/writes to Java. Fun project with lots of great challenges around performance while maintaining a nice API.