Similarities to thin threads from JRockit?
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Nov 19 09:40:38 UTC 2018
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
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".
> 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!
More information about the loom-dev