4 ms·

I was reading about Go threads just the other day and the article mentioned that Go uses green threads because they are more efficient. I thought this was weir

I was reading about Go threads just the other day and the article mentioned that Go uses green threads because they are more efficient. I thought this was weird because IIRC Java 1.0 used green threads in Linux and it was a big deal when they moved to OS threads. I’ve long believed that the IT world moves in cycles but this is a very clear example of exactly that. Java has gone from green threads to Posix threads and now back to green threads. I do think it’s awesome (I love goroutines) and Threads in Java have become a but of a nightmare, made a little easier with executors and CompletableFutures. So this further improvement is great news. But still... call me when the builder pattern is dead.

dullgiulio 6y ago
As the article explains (I know it's hard to comment after actually reading), Java moved away from using several green threads on top of a single system thread. What Loom and Go do is to schedule green threads on a bunch of system threads and spawn more system threads when they get blocked doing synchronous system calls.
- doctor_eval 6y ago
  No need for snark, I did read the article. I was just pointing out the irony that it was a big deal when the JVM moved away from green threads and now it’s a big deal when it moves back. It’s a comment on the hype cycle. And, as I said in my OP, it’s a good change and I’m happy to see it. (And if you want to be pedantic, IIRC the green threads were originally mapped to the Java process, not a thread, because threads were either unavailable or immature in Linux when Java 1 came out; I can’t remember which)
  - codr7 6y ago
    You're missing the point, which is what the person replying was trying to explain. We're not simply going back and forth, we're learning from past experience and improving implementations. The green threads on the JVM were not the same kind as green threads in Go (and Loom), they would block on IO. Can't speak for Loom, but Go automagically reschedules your green thread when it blocks which allows other threads to run while waiting. The point is they weren't rescheduled when they would block in the JVM, every process has a main thread.
    - doctor_eval 6y ago
      It’s hard to understand how I can miss my own point... yes, I know that we are not simply going back and forth; I did read the article. I know that the new implementation of green threads is more sophisticated than the original implementation. But I find the cycle - what I called the hype cycle - from internal scheduling to external scheduling and back again, interesting, and I wonder what, if anything, we as an industry can learn from this? ISTM that Java 1.2 could have improved on green threads instead of moving to os threads. So, is there something we can learn from these two transitions that will help us all make better decisions in the future? The use of OS threads and all the complexity that this has caused has cost the industry hundreds of thousands of hours of developer time. If we can learn some lessons from this then isn’t that a good thing?
      - dullgiulio 6y ago
        I don't think this is a matter of hype cycle at all. There are two things that changed: 1. Threading got much faster and lightweight. This is what Java was initially trying to work around, until it didn't have to any more. 2. The problem moved to handling as many sockets concurrently as possible. Even lightweight system threads are too heavy for scaling linearly with the number of connections (too much context-switching overhead, too much space for stack, etc.) Green-threading has become a good idea again because we now have a kernel API that is used to multiplex a lot (but not all) I/O systemcalls. Today Go runtime uses epoll/kqueue to read from a big bunch of sockets, whenever something new happens to any of them. This takes one system thread only. The API model of epoll/kqueue implies some way to handle concurrency in your user code: this can either be callbacks (or async/await syntactic sugar) or green threads and CSP (channels and so on.) This is why green threading is having a comeback. (Sorry for implying you did not read the article!)
        doctor_eval 6y ago
        That's OK, lots of people fail to RTFA, but I really like reading about this stuff. > Green-threading has become a good idea again because we now have a kernel API that is used to multiplex a lot (but not all) I/O systemcalls. OK, that makes a lot of sense. I had to read up about how epoll is different from select/poll (that's how long it's been since I worked in C :). Clearly epoll was needed to make green threads efficient, but from what I can see, by the time epoll and friends were widespread, the pthread model was entrenched in Java.
chrisseaton 6y ago
> I’ve long believed that the IT world moves in cycles but this is a very clear example of exactly that. Java has gone from green threads to Posix threads and now back to green threads. No it’s not the same thing - Java was previously M:1, then became M:M, and now Loom is M:N and also preserves M:M at the same time.
- doctor_eval 6y ago
  Sure, but back when Java had green threads on Linux, almost nobody had multicore processors, so it’s not surprising that it started as M:1. What is perhaps surprising is that Java then moved to using OS (POSIX?) threads instead of continuing to manage them internally. I remember OS threads were touted at the time as being faster than green threads. It’s a comment on the hype cycle. As a long time (since 1.0!) java developer, I like that Java has adopted a more efficient threading model. But they are certainly returning to a state where the JVM manages the threads rather than the OS, which certainly is the same as the original release, at least on Linux.
  - pron 6y ago
    Java didn't deliberately move to OS threads so much as the JDK replaced the "classical VM", which was interpreted and had green threads, with HotSpot, that supported OS threads. Moreover, back then Java was young, and people still heavily relied on calling native libraries, which make green threads much less beneficial. So it's more circumstance and necessity than hype.
    - doctor_eval 6y ago
      Not really. They could have supported green threads under hotspot, but they chose posix threads, because posix threads were much faster than the previous implementation of green threads. Today, green threads are faster. Have os threads become slower? Not that I know of. All that’s really changed is how green threads are implemented. We went from “green threads bad os threads good” to “os threads bad green threads good”. Sure, the new green threads are better than the old ones, but in some alternate universe maybe we could have got here without os threads (and maybe saved hundreds of thousands of hours of developer time in the process). To me, what’s interesting is that this appears to be a case of evolutionary “local maxima”. Java went from green threads to os threads because os threads gave better performance for the amount of effort expended. But now we’re moving back to green threads - at much greater effort, 20 years later. I’m sure I’m not the only person that wonders what lessons we can learn from this?

dullgiulio 6y ago

As the article explains (I know it's hard to comment after actually reading), Java moved away from using several green threads on top of a single system thread. What Loom and Go do is to schedule green threads on a bunch of system threads and spawn more system threads when they get blocked doing synchronous system calls.

doctor_eval 6y ago
No need for snark, I did read the article. I was just pointing out the irony that it was a big deal when the JVM moved away from green threads and now it’s a big deal when it moves back. It’s a comment on the hype cycle. And, as I said in my OP, it’s a good change and I’m happy to see it. (And if you want to be pedantic, IIRC the green threads were originally mapped to the Java process, not a thread, because threads were either unavailable or immature in Linux when Java 1 came out; I can’t remember which)
- codr7 6y ago
  You're missing the point, which is what the person replying was trying to explain. We're not simply going back and forth, we're learning from past experience and improving implementations. The green threads on the JVM were not the same kind as green threads in Go (and Loom), they would block on IO. Can't speak for Loom, but Go automagically reschedules your green thread when it blocks which allows other threads to run while waiting. The point is they weren't rescheduled when they would block in the JVM, every process has a main thread.
  - doctor_eval 6y ago
    It’s hard to understand how I can miss my own point... yes, I know that we are not simply going back and forth; I did read the article. I know that the new implementation of green threads is more sophisticated than the original implementation. But I find the cycle - what I called the hype cycle - from internal scheduling to external scheduling and back again, interesting, and I wonder what, if anything, we as an industry can learn from this? ISTM that Java 1.2 could have improved on green threads instead of moving to os threads. So, is there something we can learn from these two transitions that will help us all make better decisions in the future? The use of OS threads and all the complexity that this has caused has cost the industry hundreds of thousands of hours of developer time. If we can learn some lessons from this then isn’t that a good thing?
    - dullgiulio 6y ago
      I don't think this is a matter of hype cycle at all. There are two things that changed: 1. Threading got much faster and lightweight. This is what Java was initially trying to work around, until it didn't have to any more. 2. The problem moved to handling as many sockets concurrently as possible. Even lightweight system threads are too heavy for scaling linearly with the number of connections (too much context-switching overhead, too much space for stack, etc.) Green-threading has become a good idea again because we now have a kernel API that is used to multiplex a lot (but not all) I/O systemcalls. Today Go runtime uses epoll/kqueue to read from a big bunch of sockets, whenever something new happens to any of them. This takes one system thread only. The API model of epoll/kqueue implies some way to handle concurrency in your user code: this can either be callbacks (or async/await syntactic sugar) or green threads and CSP (channels and so on.) This is why green threading is having a comeback. (Sorry for implying you did not read the article!)
      - doctor_eval 6y ago
        That's OK, lots of people fail to RTFA, but I really like reading about this stuff. > Green-threading has become a good idea again because we now have a kernel API that is used to multiplex a lot (but not all) I/O systemcalls. OK, that makes a lot of sense. I had to read up about how epoll is different from select/poll (that's how long it's been since I worked in C :). Clearly epoll was needed to make green threads efficient, but from what I can see, by the time epoll and friends were widespread, the pthread model was entrenched in Java.

chrisseaton 6y ago

> I’ve long believed that the IT world moves in cycles but this is a very clear example of exactly that. Java has gone from green threads to Posix threads and now back to green threads. No it’s not the same thing - Java was previously M:1, then became M:M, and now Loom is M:N and also preserves M:M at the same time.

doctor_eval 6y ago
Sure, but back when Java had green threads on Linux, almost nobody had multicore processors, so it’s not surprising that it started as M:1. What is perhaps surprising is that Java then moved to using OS (POSIX?) threads instead of continuing to manage them internally. I remember OS threads were touted at the time as being faster than green threads. It’s a comment on the hype cycle. As a long time (since 1.0!) java developer, I like that Java has adopted a more efficient threading model. But they are certainly returning to a state where the JVM manages the threads rather than the OS, which certainly is the same as the original release, at least on Linux.
- pron 6y ago
  Java didn't deliberately move to OS threads so much as the JDK replaced the "classical VM", which was interpreted and had green threads, with HotSpot, that supported OS threads. Moreover, back then Java was young, and people still heavily relied on calling native libraries, which make green threads much less beneficial. So it's more circumstance and necessity than hype.
  - doctor_eval 6y ago
    Not really. They could have supported green threads under hotspot, but they chose posix threads, because posix threads were much faster than the previous implementation of green threads. Today, green threads are faster. Have os threads become slower? Not that I know of. All that’s really changed is how green threads are implemented. We went from “green threads bad os threads good” to “os threads bad green threads good”. Sure, the new green threads are better than the old ones, but in some alternate universe maybe we could have got here without os threads (and maybe saved hundreds of thousands of hours of developer time in the process). To me, what’s interesting is that this appears to be a case of evolutionary “local maxima”. Java went from green threads to os threads because os threads gave better performance for the amount of effort expended. But now we’re moving back to green threads - at much greater effort, 20 years later. I’m sure I’m not the only person that wonders what lessons we can learn from this?