Adaptation of IO classes to the VTs

[Andrii Lomakin]

Hi Ron.
Thank you for getting back to me so quickly.

Yep, it slipped my mind that ByteInputStream calls are short and not
blocking, the first example I remembered.

Follow-up questions:
1. By tracking commits in the loom branch, I have had the impression that
working on the ability not to pin threads in synchronized blocks has
already started. Is this the correct impression?
2. "Yes. The work is ongoing." - Just to double check, is my understanding
correct that once this work is done, the worker thread (OS thread) will not
be frozen by IO calls? I am interested in calls done by FileChannel,  etc.


On Wed, Jul 5, 2023 at 1:36 PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 5 Jul 2023, at 11:38, Andrii Lomakin <lomakin.andrey at gmail.com>
> wrote:
> >
> > Hi team.
>
> Hi.
>
> >
> > What is the status of adapting IO-related JDK implementations to the
> virtual threads?
>
> I believe it is complete.
>
> > For example, ByteArrayInputStream still uses synchronized in JDK 20.
>
> Using synchronized in virtual threads is usually not a problem. It can
> become a problem in cases when the synchronized guards an operation that is
> both frequent and long running — typically IO. ByteArrayInputStream,
> however, performs no IO and operations are usually very short, so the use
> of synchronized should be okay.
>
> BTW, changing public synchronized methods to non-synchronized ones can be
> a backward incompatible change, especially when the class is not final and
> can be extended. Take a look at how BufferedInputStream (which usually does
> perform actual IO) was changed in a clever way to reduce the possible
> incompatibility.
>
> >
> > If I call FileChannel methods, will VT threads be pinned in such cases?
>
> Well, it will block an OS thread (because that’s how the OS works), but
> the virtual thread scheduler will compensate by adding more workers as
> there’s no other way to work around this.
>
> > Is the same true for RandomAccessFile?
>
> Yes, the limitation is at the OS level for all filesystem operations.
>
> >
> > I have read that there were plans to use an io_uring-like API for file
> IO (all major OSs currently have such an API). Do you know if there is any
> progress in this area?
>
> Yes. The work is ongoing.
>
>
> — Ron
>
>

-- 
Best regards,
Andrii Lomakin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230705/9a66fae8/attachment.htm>