Hacker News Reader

Comment by bit_logic | Hacker News Reader

For the JVM experts here: how realistic is it for OpenJDK developers to add a command line "-useGreenThreads" option? In Golang, you can create thousands and thousands of threads and there's no issue. If I tried that in the JVM, it would quickly crash. But if there was a "-useGreenThreads" option, I could create Java Executor threadpool of size 50000, use existing http client libraries, and get full concurrency.

View on HN

Quasar might be the closest in the meantime. One problem is that blocking IO blocks all the green threads (fibers). It might be possible for Oracle or someone to fix that by wrapping NIO with green threads to implement the IO APIs. Most people will just use async NIO wrapped in fibers so it appears synchronous. Also with Quasar any calls to Thread sleep, wait, or synchronization block all the threads. It would not be an easy feature for Oracle to add but Quasar has been attempting to get merged into the JRE. For Java 9 they said they got some features added that improves the situation but Quasar instrumentation will still be required.

The Quasar instrumentation in my opinion is a pain. Out of the box you either get AoT instrumentation or you use Java agent command line option. Both were problematic for me in context of build processes, IDE support, etc. It's possible to do runtime instrumentation with no special command line option using the Quasar URL classloader and Ant task which scans classes to instrument.

> I could create Java Executor threadpool of size 50000, use existing http client libraries, and get full concurrency.

No, you'd get a slow illusion of full concurrency. The JDK ditched green threads ages ago because native threads were far more robust.

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?

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.

Well, it was a runtime option that was requested, and runtime options don't have to be identical on every platform.

Actually they do. That is the entire point of Java.

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.

Robust, sure, but they offer an interface far too heavyweight for simple tasks.

The interface is exactly the same as green threads. It is the implementation that is far more heavy than green threads.

The first wave of JVMs had it, but they eventually dropped because it wasn't worthwhile for the type of Java workloads.

The language specification doesn't state anything about how threads should be scheduled.

There are actually a few embedded JVMs that might still offer it.

There are problems with separating JVM and OS threads, mostly in assumptions that native library authors may have made about that mapping being 1:1. That isn't to say the situation can't be improved in specialised environments (see the JVM at Google talk at http://www.oracle.com/technetwork/java/javase/community/jlss...) but fixing it in general is a hard problem. It is being thought about though - see John Rose's talk at this year's JVMLS.

Thanks for the replies, I think I understand better now why this isn't as possible as I hoped.

Not sure why I'm getting downvotes for just asking a question, I thought this place was about discussion of ideas.

Why do you need a JVM flag for this? There are libraries that do it.

http://docs.paralleluniverse.co/quasar/

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.

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.

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.

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.

How is the concurrency illusionary?

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.

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)

Reply on news.ycombinator.com