4 ms·

according to the article: > Virtual threads have more in common with the user-mode threads found in other languages, such as goroutines in Go or processes in E

by stefs 4y ago

according to the article: > Virtual threads have more in common with the user-mode threads found in other languages, such as goroutines in Go or processes in Erlang -- but have the advantage of being semantically identical to the threads we already have.

anonymousDan 4y ago
And the disadvantages of global shared memory, stop the world pauses etc. For sure it is a step in the right direction but it depends on where you stand wrt having shared mutable state in your programming model. It's also not clear to me whether virtual threads can lock up carrier threads (e.g. due to an infinite loop) or are somehow preemptible (c.f. erlang reduction counts).
- kaba0 4y ago
  They can lock up carrier threads and are not preemptible. It is a bit subjective, but regarding threading Java often chooses to expose the basic primitives as is, and let you build on top. Erlang is an opinionated specialization of concurrent programming en large, which may be a better for for certain problems, but not for others. Also, I don’t think global shared memory is a problem, one is free to use ExtentLocals (threadlocals, but virtual thread friendly) in Java. Also, while small actor-scoped heaps are cool, I don’t think that they have anything on the state-of-the-art GCs Java employ, and also stop the world pauses are not really a problem that comes up, and if they do it is likely some programmer error.
- pron 4y ago
  Java hasn't had significant stop-the-world pauses for a few years now. ZGC, the new low-latency collector, has <1ms pauses for heaps up to at least 4 TB. As to shared mutable state, virtual threads are completely orthogonal to that. You can write code with shared state or without, or, if you want language guarantees, you can use languages that greatly limit it, like Clojure. I would love to see a new implementation of Erlang for the Java platform.

by stefs 4y ago

anonymousDan 4y ago

And the disadvantages of global shared memory, stop the world pauses etc. For sure it is a step in the right direction but it depends on where you stand wrt having shared mutable state in your programming model. It's also not clear to me whether virtual threads can lock up carrier threads (e.g. due to an infinite loop) or are somehow preemptible (c.f. erlang reduction counts).

kaba0 4y ago
They can lock up carrier threads and are not preemptible. It is a bit subjective, but regarding threading Java often chooses to expose the basic primitives as is, and let you build on top. Erlang is an opinionated specialization of concurrent programming en large, which may be a better for for certain problems, but not for others. Also, I don’t think global shared memory is a problem, one is free to use ExtentLocals (threadlocals, but virtual thread friendly) in Java. Also, while small actor-scoped heaps are cool, I don’t think that they have anything on the state-of-the-art GCs Java employ, and also stop the world pauses are not really a problem that comes up, and if they do it is likely some programmer error.
pron 4y ago
Java hasn't had significant stop-the-world pauses for a few years now. ZGC, the new low-latency collector, has <1ms pauses for heaps up to at least 4 TB. As to shared mutable state, virtual threads are completely orthogonal to that. You can write code with shared state or without, or, if you want language guarantees, you can use languages that greatly limit it, like Clojure. I would love to see a new implementation of Erlang for the Java platform.