<div dir="ltr">Hi Ron.<div>Thank you for getting back to me so quickly.</div><div><br></div><div>Yep, it slipped my mind that ByteInputStream calls are short and not blocking, the first example I remembered.</div><div><br></div><div>Follow-up questions:</div><div>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? </div><div>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. <br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 5, 2023 at 1:36 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 5 Jul 2023, at 11:38, Andrii Lomakin <<a href="mailto:lomakin.andrey@gmail.com" target="_blank">lomakin.andrey@gmail.com</a>> wrote:<br>
> <br>
> Hi team.<br>
<br>
Hi.<br>
<br>
> <br>
> What is the status of adapting IO-related JDK implementations to the virtual threads?<br>
<br>
I believe it is complete.<br>
<br>
> For example, ByteArrayInputStream still uses synchronized in JDK 20.<br>
<br>
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.<br>
<br>
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.<br>
<br>
> <br>
> If I call FileChannel methods, will VT threads be pinned in such cases?<br>
<br>
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.<br>
<br>
> Is the same true for RandomAccessFile?<br>
<br>
Yes, the limitation is at the OS level for all filesystem operations.<br>
<br>
> <br>
> 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?<br>
<br>
Yes. The work is ongoing.<br>
<br>
<br>
— Ron<br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Best regards,<br>Andrii Lomakin.<br><br></div></div></div></div>