3 ms·

Because that's at the library level. It would require rewriting code to use it which loses one of the big advantages of the JVM (a huge existing ecosystem). I

Because that's at the library level. It would require rewriting code to use it which loses one of the big advantages of the JVM (a huge existing ecosystem). If it's at the JVM level (with a command line option to change how threading is done such as -useGreenThreads") then it's transparent to all existing code. I can just use anything (such as existing JDBC library), increase threadpool to levels that would be considered "ridiculous" with current JVM threading system, and it would all work fine. No code changes necessary for existing libraries.

brianwawok 10y ago
Except I don't think you can just magically do that. People do this in Python, but they do it in Python because 1) Python is dumb and has the GIL, much easier to hack in 2) They use reflection to change libraries, but it breaks anytime you would hit native C code. With Java trying to JIT everything, you are now having to change threading at the assembly level. I think it is would be a ton of work to do at the base JVM level. If you look at the people behind the library I linked, it is many of the core Java people. They might have more insight on reasons why it won't work.
takeda 10y ago
Green threads are very different from system threads. With green threads you get an illusion of concurrency, and when coding you need to account that multiple green threads work on a single system thread. There's no way you would get a switch like that, because you interact with them differently. I wish greenthreads would not use "thread" in the name because it causes confusion like in your case.
- icebraining 10y ago
  How is the concurrency illusionary?
  - brianwawok 10y ago
    Well a System with 16 CORE / 32 Hardware threads.. you run a program with 32 threads, you can legit run 32 things in parallel. Now not really because of OS scheduling and logs and other junk going on, but it could actually happen. You take the same code and run it with 3000000 green threads... you are still capped out at 32 things running at the same time. Your system can kinda sorta pretend to be more concurrent, but the actually concurrency is the same.
    - icebraining 10y ago
      Yeah, but you could also have thousands of system (OS) threads in that same hardware, and they wouldn't run at the same time either. (Also, they're still concurrent, just not parallel: https://vimeo.com/49718712 https://vimeo.com/49718712)
- logn 10y ago
  Green threads and system threads are the same illusion to programmers (or, at least, they can be). The only caveat is that dependencies using system threads won't play nicely with green threaded code. Quasar, which does green threads for Java, schedules and distributes your green threads to system threads, one for each cpu. The Quasar API for green threads is basically identical to built in Java APIs.

brianwawok 10y ago

Except I don't think you can just magically do that. People do this in Python, but they do it in Python because 1) Python is dumb and has the GIL, much easier to hack in 2) They use reflection to change libraries, but it breaks anytime you would hit native C code. With Java trying to JIT everything, you are now having to change threading at the assembly level. I think it is would be a ton of work to do at the base JVM level. If you look at the people behind the library I linked, it is many of the core Java people. They might have more insight on reasons why it won't work.

takeda 10y ago

Green threads are very different from system threads. With green threads you get an illusion of concurrency, and when coding you need to account that multiple green threads work on a single system thread. There's no way you would get a switch like that, because you interact with them differently. I wish greenthreads would not use "thread" in the name because it causes confusion like in your case.

icebraining 10y ago
How is the concurrency illusionary?
- brianwawok 10y ago
  Well a System with 16 CORE / 32 Hardware threads.. you run a program with 32 threads, you can legit run 32 things in parallel. Now not really because of OS scheduling and logs and other junk going on, but it could actually happen. You take the same code and run it with 3000000 green threads... you are still capped out at 32 things running at the same time. Your system can kinda sorta pretend to be more concurrent, but the actually concurrency is the same.
  - icebraining 10y ago
    Yeah, but you could also have thousands of system (OS) threads in that same hardware, and they wouldn't run at the same time either. (Also, they're still concurrent, just not parallel: https://vimeo.com/49718712 https://vimeo.com/49718712)
logn 10y ago
Green threads and system threads are the same illusion to programmers (or, at least, they can be). The only caveat is that dependencies using system threads won't play nicely with green threaded code. Quasar, which does green threads for Java, schedules and distributes your green threads to system threads, one for each cpu. The Quasar API for green threads is basically identical to built in Java APIs.