Question On Project Loom

[Alan Bateman]

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