Similarities to thin threads from JRockit?

[Magnus Ihse Bursie]

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
>
>