Coroutines or Java Fibers in Project Loom

Project Loom introduces lightweight concurrency construct in Java. The main purpose or goal of Project Loom is to support a high-throughput, lightweight concurrency model in Java.

Problems with the current Java Concurrency Model:

We already knew that the current java concurrency model uses operating system kernel level threads. let’s see some problems with the current model.

Problem 1: Waiting of threads or Blocking of threads.

We already knew that if the thread blocks the till that time thread is blocked due to I/O operations, we are not using CPU or CPU cycles are getting wastes so we are not using CPU efficiently.

Let’s say we start creating more no of threads to solve the above problems, for example, if some threads are blocked we can spawn similar no threads so that CPU not idle and we can use CPU cycle efficiently, But it creates another problem.

Problem 2: Creation of more threads can cause JVM Crash (Out of memory):

The creation of a thread takes time and takes approximately 1MB of memory. so we start creating more threads it can cause JVM Crash depends upon the memory given to JVM.

How can we solve the above two problems:

There are two we can solve the above problems:

1. Reactive Programming:

Reactive programming works under the concepts of the event loop which never get blocked or not supposed to do any blocking operation of on the event loop. It uses event queues so any I/O operation happens it gets pushed to queue(callbacks get pushed to queue) so that main thread not get blocked and whenever thread gets the response and gets executed by main thread or event loop.

2. Using Coroutines:

It introduces user level or mode threads which rely on Java runtime implementation of continuations and schedulers instead of the OS implementation.

Currently, java implementation relies on kernel level schedulers, continuation, and threads. So let’s say if the thread is blocked due to some I/O operation in order to suspend a continuation, it’s required to store the entire call-stack. And similarly, retrieve the call-stack on resumption.

Java doesn’t have controls over threads CPU treats all the request in the same manner, and hence we cannot control so it is not certain that same request goes to the same CPU this is very less probable.

To get control over threads scheduling we required Application level or user level threads, continuation (aka task) and scheduler.

Fibers Schedulers:

• To achieve this Schedulers is required which can control over fibers and schedules task in OS level threads
• Takes care of mount and unmount of task (due to I/O) operation.
• During I/O operation continue with other tasks
• Continue with the same task where it left during I/O operation.

Advantages over Threads:

1. Very LightWeight
2. Takes only a few Kb of the stack as compare to Thread (takes around 1MB)
3. Can run millions of fibers in an application.
4. Servers can handle more no of concurrent connections.
5. Efficient utilization of CPU

Happy Learning.

Thanks