Question On Project Loom

[Sohail Khan]

Thanks a lot Alan Ron and Arthur, for all your wonderful answers.

I am trying to summarize my queries in a single email. I am using the
Mailing List for the very first time, and not sure about the mailing
convention, therefore please correct me if I am wrong.

   1. Alan, going by the example you shared of Blocking Queue trying to
   fetch an element and getting blocked. This implies all Java API that  can
   block, have been modified to Detect Virtual Threads being used, and then
   save the context and park it for later execution. Is my understanding
   correct? The push operation will place elements and mark blocked virtual
   threads as Ready.
   2. Ron, Whenever we make API calls that currently use blocking IO Like
   Plain old blocking sockets, the API has been modified to detect a virtual
   thread being used, they internally switch  to the usage of non blocking NIO
   apis transparently. Is my understanding correct? Also when the request
   comes from Classic threads, the implementation will be using the blocking
   apis, similar to what's happening today.
   3. Arthur, thanks a lot for the detailed write up. In your previous
   email, you shared details about a Poller being implemented in the Java
   Runtime. This poller will be delegated  the epoll syscalls and once the
   data is available in the buffers it will wake up the corresponding Virtual
   Threads, is my understanding correct? Also do you have nice write up  on
   the implementation of Poller as well, it will be a very good learning for me
   4. Will JNI calls only be allowed from Classic threads and not virtual
   threads, because JNI could allow some one execute blocking code from within
   a virtual thread.

Thanks a lot again to Alan. Ron and Arthur. Really appreciate your work and
kindness in helping me understand this topic

On Mon, Apr 26, 2021 at 3:35 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> 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
>