Similarities to thin threads from JRockit?

[Billy Sjöberg]

Thanks Magnus for the very thorough answer!
Would have been nice to play around with JRockit back in the days. Seems like you had some very interesting stuff in there way ahead of its time.

/Billy

From: Magnus Ihse Bursie
Sent: Monday, 19 November 2018 10:42
To: Billy Sjöberg; loom-dev at openjdk.java.net
Subject: Re: Similarities to thin threads from JRockit?

Hi Billy,

On 2018-11-16 13:00, Billy Sjöberg wrote:
Hello everyone involved with project Loom!
First of I’d like to give my support to you guys as the progress you’re making is impressive to say the least and I hold all my thumbs that you’ll be successful in the project.

Could anyone instruct me in how Fibers differ from i.e. thin threads which was implemented in the JRockit VM? Are there similarities and did you reuse any of the experience and learnings from that?
Not many of the original JRockit developers are still with Oracle; I'm being one of the few left. While I'd love to work on Project Loom, I'm still very much stuck in working with the build system of OpenJDK. :-) I've followed Loom with quite some interest, but only from a distance, so I'll leave any discussion about the workings of Loom to someone more knowledgeable than me.

However, you are right that Loom fibers are quite similar to JRockit thin threads. I think also there are several differences, that will hopefully make fibers a better success story than the JRockit thin threads. One, for start, is the ability to work within the OpenJDK framework, where all changes necessary can be made. JRockit, at the time, was a true drop-in replacement for Hotspot, and we had to work within the limitations of the JDK at the time.

Thin threads showed tremendous performance on (more or less artificial) benchmarks using thread-based programming style, with threads doing mostly pure Java or waiting for IO. There was a chat-service benchmark, the name of which I've forgotten, where we could beat the competition with numbers that were almost hilarious. 

However, in the real world, most applications did not behave like this. Interaction with native code (most likely not as common today as when JRockit started) was a big problem, maybe the biggest. Scheduling was a hard issue -- not unsolvable, but seriously technically hard. We used what we called "MxN", mapping M thin threads on N native threads. Then you had to fight with the CPU on the scheduling of the N native threads on the P number of CPUs. Also, when a worker thread got caught in JNI too long, we spawned a new native thread to continue execute from the thin thread pool. This made the hard scheduling problem re-occur every so often.

In the end, the complexities of thin threads did not outweigh the benefits, and thin threads were removed quite early in JRockit.

>From my perspective, Loom shares many of the design features with thin threads, but it also different. I think Loom has a much higher chance of success, depending on a lot of factors:

1) The amount of pure Java libraries today is staggering, and many legacy systems has been removed -- so having a custom made JNI interface is the exception, rather than the rule as it was in the pre-2000 world. This would remove one of the main stumbling blocks we encountered.

2) Loom is working as an OpenJDK project, with the power to propose changes (and having a reasonable chance of getting them accepted) to all parts of the JDK classes, the VM and the specs. If something is not working, then need not be stuck.

3) Developers these days are well aware of multi-tasking issues, and are used to resorting to various async callback based solutions for massively parallel execution. Given this mindset, Loom will allow them to do the same things but with tremendously improved code readability. I think Loom will be seen not as "make my code still go fast when I scale it", but "make my fast and scalable code readable again".

/Magnus



Also, I think a good FAQ/comparison would be helpful as the concurrency terms seems be tossed around causing confusion whenever the Loom project is being discussed.

It would be nice to have one source of truth comparing it against i.e Kotlin coroutines, green threads, go-routines and thin threads. I get that the Kotlin / C# / JS way is i.e. not solving the colored method problem, but it would be nice to have a comparison matrix or something similar for the alternatives.

Best regards and good luck!

/Billy