4 ms·

Say what you will about the evil database company which shall not be named, but under their stewardship the JVM ecosystem is moving into the right direction, an

Say what you will about the evil database company which shall not be named, but under their stewardship the JVM ecosystem is moving into the right direction, and there is massive investment in foundational technologies that will take years to come to fruition, some of it unmatched (eg virtual threads or GraalVM).

Yoric 4y ago
Out of curiosity, what's the difference between virtual threads, green threads and, say, goroutines?
- MrBuddyCasino 4y ago
  Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation. Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop. Green threads usually refer to single-threaded runtimes such as Node.
  - butt__hugger 4y ago
    [dead]
  - Yoric 4y ago
    So it's basically an implementation of transparent of M:N scheduling, right? I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).
    - nu11ptr 4y ago
      Yep, M:N cooperatively scheduled. It also requires a "runtime" which Rust didn't want to have
  - ithrow 4y ago
    Green threads usually refer to single-threaded runtimes such as Node. This doesn't sound right. How is the single-threaded event-loop of node green threads?
    - MrBuddyCasino 4y ago
      You're right, that was a bad example.
    - samus 4y ago
      Apart from that, it makes a lot of sense to have multiple threads in Node. They just run in the background, do stuff, and send events into JS land from time to time.
- twic 4y ago
  Not a lot. To a large extent, they are different names for the same concept. But since they are the names used for that concept by specific implementations, they also imply the particularities of those implementations. The old Java green threads could only use a single core, the new Java virtual threads can use multiple cores. AFAIK, Java green and virtual threads are both cooperatively scheduled, Goroutines are, nowadays, preemptively scheduled. And so on and so forth.
  - kaba0 4y ago
    Java's virtual threads are preemptive, not cooperative -- they are preempted not at explicit points, but at blocking IO operations.
    - twic 4y ago
      > they are preempted not at explicit points, but at blocking IO operations. That is cooperative scheduling.
    - diroussel 4y ago
      If you can’t break a thread out of an infinite loop, that is pure cpu and no io, then the run time is not preemptive, surely??
      - kaba0 4y ago
        At worst the OS will preempt the thread and the JVM will likely schedule a different virt thread the next time — but in case you have multiple CPU-hungry virtual threads fighting over a single core it will suck no matter what. The performance improvement comes from doing useful work on a thread during IO waits. Nonetheless, there were discussions about some way to force preemption at certain points, not sure whether there is a decision since, but that will be the exception, not the rule.
        Yoric 4y ago
        Still trying to understand: what's the difference between "forc[ing] preemption" and cooperative threading?
pjmlp 4y ago
People tend to forget that it was Oracle alongside IBM, that joined Sun in the major Java push before anyone else. See Network Computer, first Swing based GUI for DBAs, SP in Java,... Both of which also have had their own JVM implementations.
carimura 4y ago
Virtual Threads are actually in their second preview which means it might not be years before we see them standard in the JDK.
- hugi 4y ago
  It currently looks like Virtual Threads will be final in JDK 21, to be released in September this year. https://openjdk.org/jeps/8303683 https://openjdk.org/jeps/8303683
  - carimura 4y ago
    Just to be clear that's a submitted draft JEP [1] so not quite there yet.... [1] https://openjdk.org/jeps/1 https://openjdk.org/jeps/1
    - kaba0 4y ago
      But it is not the first iteration, and the loom branch has working versions for quite some times now. It’s definitely not in a design-only phase.
      - mike_hearn 4y ago
        Loom was already merged into their master equivalent, iirc. It was shipping behind a preview flag for a while.

Yoric 4y ago

Out of curiosity, what's the difference between virtual threads, green threads and, say, goroutines?

MrBuddyCasino 4y ago
Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation. Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop. Green threads usually refer to single-threaded runtimes such as Node.
- butt__hugger 4y ago
  [dead]
- Yoric 4y ago
  So it's basically an implementation of transparent of M:N scheduling, right? I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).
  - nu11ptr 4y ago
    Yep, M:N cooperatively scheduled. It also requires a "runtime" which Rust didn't want to have
- ithrow 4y ago
  Green threads usually refer to single-threaded runtimes such as Node. This doesn't sound right. How is the single-threaded event-loop of node green threads?
  - MrBuddyCasino 4y ago
    You're right, that was a bad example.
  - samus 4y ago
    Apart from that, it makes a lot of sense to have multiple threads in Node. They just run in the background, do stuff, and send events into JS land from time to time.
twic 4y ago
Not a lot. To a large extent, they are different names for the same concept. But since they are the names used for that concept by specific implementations, they also imply the particularities of those implementations. The old Java green threads could only use a single core, the new Java virtual threads can use multiple cores. AFAIK, Java green and virtual threads are both cooperatively scheduled, Goroutines are, nowadays, preemptively scheduled. And so on and so forth.
- kaba0 4y ago
  Java's virtual threads are preemptive, not cooperative -- they are preempted not at explicit points, but at blocking IO operations.
  - twic 4y ago
    > they are preempted not at explicit points, but at blocking IO operations. That is cooperative scheduling.
  - diroussel 4y ago
    If you can’t break a thread out of an infinite loop, that is pure cpu and no io, then the run time is not preemptive, surely??
    - kaba0 4y ago
      At worst the OS will preempt the thread and the JVM will likely schedule a different virt thread the next time — but in case you have multiple CPU-hungry virtual threads fighting over a single core it will suck no matter what. The performance improvement comes from doing useful work on a thread during IO waits. Nonetheless, there were discussions about some way to force preemption at certain points, not sure whether there is a decision since, but that will be the exception, not the rule.
      - Yoric 4y ago
        Still trying to understand: what's the difference between "forc[ing] preemption" and cooperative threading?

pjmlp 4y ago

People tend to forget that it was Oracle alongside IBM, that joined Sun in the major Java push before anyone else. See Network Computer, first Swing based GUI for DBAs, SP in Java,... Both of which also have had their own JVM implementations.

carimura 4y ago

Virtual Threads are actually in their second preview which means it might not be years before we see them standard in the JDK.

hugi 4y ago
It currently looks like Virtual Threads will be final in JDK 21, to be released in September this year. https://openjdk.org/jeps/8303683 https://openjdk.org/jeps/8303683
- carimura 4y ago
  Just to be clear that's a submitted draft JEP [1] so not quite there yet.... [1] https://openjdk.org/jeps/1 https://openjdk.org/jeps/1
  - kaba0 4y ago
    But it is not the first iteration, and the loom branch has working versions for quite some times now. It’s definitely not in a design-only phase.
    - mike_hearn 4y ago
      Loom was already merged into their master equivalent, iirc. It was shipping behind a preview flag for a while.