4 ms·

I probably shouldn't have used the term "green threads" since that has history in the JVM. I meant whatever Golang is doing which is similar (M:N threading).

I probably shouldn't have used the term "green threads" since that has history in the JVM. I meant whatever Golang is doing which is similar (M:N threading). With an AOT option for Java, this becomes even more of an option. Golang has shown this works, why can't Java implement the same idea and let all existing libraries benefit from it?

valarauca1 10y ago
Green Threading is M:N threading. Go-Routines are M:N threading. Q.E.D. M:N threading isn't a new idea. Go just offers a backed (or compiled) in run-time that does M:N threading by default for you. While nearly every other Green Threaded language offered as an additional library/option. This hurt adoption. While Go just forces you to use Green Threading. With an AOT option for Java, this becomes even more of an option. Not in the slightest. why can't Java implement the same idea and let all existing libraries benefit from it? A laundry list of reason: 1. Change what functions do and don't block can cause huge issues with down stream libraries/people who depend on system libraries behaving the same thing tomorrow as they did yesterday. 2. Refactoring all code around system calls so they never block. 3. Write a multi-core and multi-socket scheduler. 4. Write a scheduler to balance multi-core and multi-socket thread load. 5. Determine how you will do polling, and write a polling strategy to figure out what green threads are/are not blocked, then figure out how to communicate this information efficiently. 6. Repeat the above 5 steps for EVERY platform Java runs on.
- paulddraper 10y ago
  Well, it was a runtime option that was requested, and runtime options don't have to be identical on every platform.
  - valarauca1 10y ago
    Actually they do. That is the entire point of Java.
    - paulddraper 10y ago
      No, the point was to make compile-once run-anywhere software. It's natural for tuning runtime parameters to vary. The hotspot JVM will accept both -d32 (32-bit data model) and -d64 (64-bit data model) everywhere, but they will only work on certain platforms.

valarauca1 10y ago

Green Threading is M:N threading. Go-Routines are M:N threading. Q.E.D. M:N threading isn't a new idea. Go just offers a backed (or compiled) in run-time that does M:N threading by default for you. While nearly every other Green Threaded language offered as an additional library/option. This hurt adoption. While Go just forces you to use Green Threading. With an AOT option for Java, this becomes even more of an option. Not in the slightest. why can't Java implement the same idea and let all existing libraries benefit from it? A laundry list of reason: 1. Change what functions do and don't block can cause huge issues with down stream libraries/people who depend on system libraries behaving the same thing tomorrow as they did yesterday. 2. Refactoring all code around system calls so they never block. 3. Write a multi-core and multi-socket scheduler. 4. Write a scheduler to balance multi-core and multi-socket thread load. 5. Determine how you will do polling, and write a polling strategy to figure out what green threads are/are not blocked, then figure out how to communicate this information efficiently. 6. Repeat the above 5 steps for EVERY platform Java runs on.

paulddraper 10y ago
Well, it was a runtime option that was requested, and runtime options don't have to be identical on every platform.
- valarauca1 10y ago
  Actually they do. That is the entire point of Java.
  - paulddraper 10y ago
    No, the point was to make compile-once run-anywhere software. It's natural for tuning runtime parameters to vary. The hotspot JVM will accept both -d32 (32-bit data model) and -d64 (64-bit data model) everywhere, but they will only work on certain platforms.