2 ms·

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 surp

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?
  - pron 6y ago
    > because posix threads were much faster than the previous implementation of green threads. Green threads employed only one kernel thread so couldn't take advantage of multicore, and at the time Java relied on native code so much more than today. > but in some alternate universe maybe we could have got here without os threads Maybe :) > But now we’re moving back to green threads - at much greater effort, 20 years later These aren't green threads but M:N, and I don't think it's a much greater effort than the effort that would have been required to add it to HotSpot back then.
    - doctor_eval 6y ago
      Sorry, I'm using the modern meaning of green threads [0], which is simply threads scheduled in userspace. The first green threads implementation, which was of course Java 1.0, was certainly M:1 - my memory is that we didn't even have pthreads in linux at the time - but the term today doesn't specifically mean a M:1 mapping. On the other hand, of course JVM1.0 invented "green threads" which was M:1. So yeah this is confusing and I made it more confusing. Sorry. :) So the point I was trying to make is that Java originally scheduled threads in userspace, then delegated scheduling to the OS, and has now taken it back. In hindsight it seems that delegating this key function to the OS has caused a lot of pain, and I'm interested in the drivers for using OS threads instead of just making the original green thread implementation better. To be even clearer, I see this a lot in software. We delegate some key function of a product (like database access) to some inefficient and complex machinery (like an ORM) and then spend years working around the problems that decision caused. I've done this myself. I'd like to understand how to stop doing it. [0] https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads
      - deleted 6y ago
        [deleted]
      - pron 6y ago
        You are largely correct about the "reversion" to userspace threading, but the decisions (some of them were forced moves) weren't because of fashions but very different circumstances. You could point out that it is interesting that different circumstances have led to userspace threads. I don't know all the reasons behind abandoning green threads, but some are mentioned here: https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/index.html https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/inde... namely, no multi-core and bad FFI ("interoperate with existing MT applications"). Plus, a little later, the transition to HotSpot left little desire to reimplement userspace threading. There was no pressing need, there was other, higher-priority work needed, and FFI was still an impediment. In other words, making green threads better was neither an important requirement nor a reasonable possibility back then. Why have we "gone back"? 1. the scale of concurrency required today is higher and resulted in the scaffolding I mention in the article, 2. FFI is no longer an impediment as Java code rarely relies on native code these days. Nevertheless, Project Loom doesn't switch from kernel to userspace threads, but rather lets you choose which implementation you want for each thread.

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?
- pron 6y ago
  > because posix threads were much faster than the previous implementation of green threads. Green threads employed only one kernel thread so couldn't take advantage of multicore, and at the time Java relied on native code so much more than today. > but in some alternate universe maybe we could have got here without os threads Maybe :) > But now we’re moving back to green threads - at much greater effort, 20 years later These aren't green threads but M:N, and I don't think it's a much greater effort than the effort that would have been required to add it to HotSpot back then.
  - doctor_eval 6y ago
    Sorry, I'm using the modern meaning of green threads [0], which is simply threads scheduled in userspace. The first green threads implementation, which was of course Java 1.0, was certainly M:1 - my memory is that we didn't even have pthreads in linux at the time - but the term today doesn't specifically mean a M:1 mapping. On the other hand, of course JVM1.0 invented "green threads" which was M:1. So yeah this is confusing and I made it more confusing. Sorry. :) So the point I was trying to make is that Java originally scheduled threads in userspace, then delegated scheduling to the OS, and has now taken it back. In hindsight it seems that delegating this key function to the OS has caused a lot of pain, and I'm interested in the drivers for using OS threads instead of just making the original green thread implementation better. To be even clearer, I see this a lot in software. We delegate some key function of a product (like database access) to some inefficient and complex machinery (like an ORM) and then spend years working around the problems that decision caused. I've done this myself. I'd like to understand how to stop doing it. [0] https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads
    - deleted 6y ago
      [deleted]
    - pron 6y ago
      You are largely correct about the "reversion" to userspace threading, but the decisions (some of them were forced moves) weren't because of fashions but very different circumstances. You could point out that it is interesting that different circumstances have led to userspace threads. I don't know all the reasons behind abandoning green threads, but some are mentioned here: https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/index.html https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/inde... namely, no multi-core and bad FFI ("interoperate with existing MT applications"). Plus, a little later, the transition to HotSpot left little desire to reimplement userspace threading. There was no pressing need, there was other, higher-priority work needed, and FFI was still an impediment. In other words, making green threads better was neither an important requirement nor a reasonable possibility back then. Why have we "gone back"? 1. the scale of concurrency required today is higher and resulted in the scaffolding I mention in the article, 2. FFI is no longer an impediment as Java code rarely relies on native code these days. Nevertheless, Project Loom doesn't switch from kernel to userspace threads, but rather lets you choose which implementation you want for each thread.