Question On Project Loom
Alan Bateman
Alan.Bateman at oracle.com
Mon Apr 26 07:35:29 UTC 2021
On 25/04/2021 21:22, Sohail Khan wrote:
> Hello Loom Dev,
>
> Thanks a lot for your great work on Project Loom. I am really excited
> about Project Loom.
> I had a couple of questions that I felt you could answer and help me. My
> questions are in the context of Linux OS and IO.
>
> 1. Current implementation of Java Threads are wrappers around Native
> Threads. In linux, threads are Process sharing Virtual Address Space
> allocated to the parent process. If a Java thread makes a blocking
> system call like Read() on a file descriptor, scheduler adds it to the Wait
> Queue, to be awakened later. When running in virtual threads. blocking it
> could be detrimental to the entire JVM. Is my understanding correct?. If
> it's correct then the only IO allowed from Virtual Thread will be
> non-blocking syscalls, any traditional API that uses blocking under the
> hood will need to be invoked from a non virtual thread.
Virtual threads love blocking I/O. If the thread needs to block in say a
Socket read then this releases the underlying kernel thread to do other
work. The virtual thread is re-scheduled to continue execution when the
socket is ready (data arrives, error ...).
> 2. SInce JVM will be doing scheduling, will Java Compiler add bytecodes
> to the task definition, to indicate the JVM to context switch a new virtual
> thread on the native thread. This would lead the JVM to save all the
> context, call stack in Data Structure and allocate a new executable task to
> the native thread. Is my understanding correct?
The scheduling points are in the Java runtime, more specifically in the
implementation of the APIs that do locking operations or blocking I/O.
As an example, suppose code executing in a virtual thread attempts to
"take" the element at the head of a BlockingQueue. If there is no
element to take then the thread parks and releases the underlying kernel
thread to do other work. This doesn't need any support from the
compiler, the code that is retrieving elements from the queue may be
have been compiled a long time ago.
There are other languages that do have compiler support along the lines
that you are thinking but in Project Loom. Instead, this project relies
on having being in control of the platform.
> 3. Will Java Scheduler Implement TIme Slicing, between competing CPU
> bound executable tasks or the preferred way of executing them would be to
> use existing ForkJoin Pool. Also in case if Java implements preemptive
> scheduling using time slicing, how will JVM interrupt the process as its
> running in the user space
This project isn't doing time slicing. Virtual threads are intended to
execute code that spends most of the time blocked.
If a good use for forceful preemption does arise then it can be
examined. There is some underlying support in the implementation that is
based on the HotSpot VM thread-local handshake mechanism but there is no
plan to expose anything on this at this time.
> 4. As of today Netty is one very popular wrapper around Java NIO, that
> relies on Event Loops. Will JVM Internally implement event loops for
> Project Loom, because availability of data on Socket buffers could make a
> task executable again.
There isn't anything exposed that is the equivalent of a call from an
event loop. Instead you use the existing SocketChannel, Socket, etc.
APIs to do blocking I/O. This allows code to be developed in the simple
synchronous style, this code is usually easier to read, debug and
profile when compared to asynchronous code.
> I was just trying to understand this topic in detail and seeking your help
> to do it. Thanks a lot for the help.
> I am not a JDK developer but just someone who has keen passion in
> understanding this topic and hopefully someday try contributing back as
> well to the community.
Thanks. The best way to contribute is to try out the early access
builds, use it with real applications and libraries, and provide
feedback (positive or negative) that helps identify issues or
shortcomings that may have been missed.
-Alan
More information about the loom-dev
mailing list