Adaptation of IO classes to the VTs

[Robert Engels]

Hi Ron, I’ll confess - I havent looked at the VT implementation - but are you stating that it doesn’t use epoll/select behind the scenes to multiplex the IO onto a single native thread - like Go does? Only certain “rare/less used” kernel calls cause the carrier to be locked in Go. 

> On Jul 5, 2023, at 6:36 AM, 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
>