Fibers in Java (Yes fibers !!!)

Fiber is upcoming feature in Java which will offer a light weight alternative to Threads . However the question is why fibers ,one word answer to it is “money”.

Each thread created by Java corresponds to operating system thread. Creating Threads is costly as well as context switching to another thread is quite expensive. As a result in most applications thread gets blocked and servers remain underutilized. Java fibers on the other hand will be managed by JVM by its own scheduler .

If we see methods of Thread class vis-a-vis Fiber it will make the picture clearer.

Thread :
checkAccess() countStackFrames() getContextClassLoader() getId() getName() getPriority() getStackTrace() getState() getThreadGroup() getUncaughtExceptionHandler() interrupt() isAlive() isDaemon() isInterrupted() join() resume() run() setContextClassLoader() setDaemon() setName() setPriority() setUncaughtExceptionHandler() start() stop() suspend()

Fiber :
await() cancel() isAlive() isCancelled() schedule()

Creating and starting a fiber is quite straight forward

var fiber = new Fiber(() -> System.out.println("Hello from fiber"));
fiber.schedule();

In today’s cloud computing world where applications are billed on hourly basis reducing server underutilization is top most priority of application owners and fibers will certainly help them.

Comments

[Valery Silaev]

Full disclosure first:
I'm the author and a maintainer of the Apache JavaFlow fork -- Tascalate JavaFlow.

The author of Fibers proposal (aka Project Loom), Ron Pressler, is the original author of Quasar, and a significant part of the Quasar functionality is Fibers.

So we are persons behind competitive OSS projects, and I may be biased, probably. But here is what I think.

The whole idea for Project Loom looks for me like promoting Quasar to JVM. Yes, it's doable. Yes, there is a prototype already. But... Is it grounded enough?

1. The practice shows that continuations allow creating higher-level abstractions like Actors (Kilim, Quasar itself, may be other implementations) or even syntax-like extensions, for example -- async / await (my own implementation is here -- Tascalate Async / Await. Again, both are higher-level abstractions, that empower developers with better syntax and/or better programming model. There are continuations underneath, there are schedulers involved -- but this low-level details are hidden from library's users. But proposed Fibers is a low-level construct, almost the same as Threads + ExecutorService-s. Do we need low-level construct? Do we need all this low-level details exposed? Do we need to step back and start coding again in terms of low-level locks, monitors, synchronization blocks? Notice, that no one ever promises that Thread-based code will be magically ported to Fibers.
2. Though Fibers has own scheduler, it ends up calling some Thread scheduler. There is no magic. So we will have a user-code scheduler atop of system scheduler. Any seasoned developer will tell you that this might improve performance in some cases, but, definitely, not in all cases.
3. Just to re-iterate: there are continuations behinds Fibers. Continuations need to capture execution stack of methods' calls up to the point the continuation is suspended. There is no free lunch, and continuations affect performance negatively. You are saying: "Creating Threads is costly as well as context switching to another thread is quite expensive". And I'm pretty skeptic that overhead necessary to maintain continuations will augment performance losses of thread context switching.
4. There are some tests that shows (from the authors' words) that Fibers outperforms Threads. Probably. But what is the baseline they compare with? I hardly believe that Fibers per-se will ever outperform good written combo of NIO + thread pools. And for calculation tasks, I hardly believe that Fibers with underneath continuations (quite resource-hungry beast, trust me) will be better than ForkJoinPool.

All in all, it would be great to have native JVM support for continuations. It will definitely beat performance of any existing continuations library -- even the current leader coroutines. It would be great to finally see tail-call optimizations in Java -- this will open the door for more functional-style code in Java. But Fibers, even they will be added, is not a silver bullet, and I hardly believe the idea to add them, at least that early, is justified enough. So I do not share your enthusiasm about them...