Hacker News Reader

Comment by zz865 | Hacker News Reader

I was going to say with modern PCs this is kinda redundant now, but its still a language of small devices too, where it'll be welcome.

View on HN

This isn't really targeted for small devices - its very very applicable with large computers in datacenters (id argue those machines will benefit even more from this). Any time you wait on I/O you potentially park an entire thread when you could be multiplexing your threads. This is a net win for almost all users of threads (except perhaps 100% cpu intensive tasks)

You can do that now already though, the main expense is 1mb of memory for stack.

Up to 1mb of stack memory. It starts lower, only consuming what it needs. It doesn’t resize down again, though, which virtual threads do.

The other cost is context switching, which is much cheaper with virtual threads.

I'm salivating over the context switching wins, myself. I've got a simulation system that uses threads to pause and resume modeled tasks at the appropriate times relative to the simulation clock, and we're just passing a token back and forth with each step of a task. These threads aren't used for parallelism; they're just used to capture the task's continuation in a convenient way, allowing us to use a direct-style approach to modeling tasks.

The context switching sucks so much that an alternate approach, swapping threads for throwing an exception on yield and re-running the method and ignoring side-effects until we get back to the resumption point, saves us a significant amount of time.

In my experience most Java services who care have already long switched to non-blocking IO.

Reply on news.ycombinator.com