I guess I'm really wondering: let's say Java 9 mutexes use Linux 4's user-mode threading syscall; in that case do we need Quasar's scheduler, channels, actors etc. Or can we just use "good-old" threads and mutexes? Where would Quasar's benefits come from?
It sounds to me like the subtext to Google's patches is that rather than accepting the conventional wisdom that "threads don't scale", they've instead just fixed threads.
Trying again: Taking your example benchmark, you aren't really calling any special methods that provide any hints for cooperative threading (to my untrained eye). That's great - you've got a great abstraction. But then, what opportunities for optimization does Quasar have, that are not also available to a JVM using the magic syscall?
I'm sure there's something here, but I'd appreciate a hint!
I'm excited by the idea that threads are going to be "the right way", once these improvements make it out of the 'plex.
I also like that I can get a similar API today with Quasar :-)
Quasar doesn't just provide lightweight threads. It has rich libraries that help you make the best of them.
If user-mode threading is adopted, Quasar could work without instrumentation, but instrumentation is a very small part of the Quasar code base.
Quasar gives you the scheduler, channels, actors, etc.
The 10x performance boost comes from the fact that there can be non-negligible latency from the time you unpark a thread to the time it starts running, while for fibers that latency is much shorter.