Native methods and virtual threads

Ron Pressler ron.pressler at oracle.com
Fri Jul 14 14:00:01 UTC 2023


Compensating for blocking is itself an option of last resort that could perhaps help in some cases somewhat maybe hopefully. Optimally, blocking IO shouldn’t be used at all for frequent operations, and that’s what we’re aiming for now that more OSes are beginning to offer non-blocking filesystem IO, and blocking the OS thread from time to time shouldn’t matter much anyway as the scheduler should smooth that over in a well-balanced system. So while in some cases we still have no option other than to compensate in the hope that maybe in some situations it might help, making compensation —  a backup plan at best — easier is not our number one priority at this time.

If for some reason you choose to do a lot of OS-blocking IO operations, you shouldn’t use virtual threads at all, as compensating may not help much, and if you only use it infrequently it may not be needed at all. I see no general purpose mechanism that could make intentional frequent blocking of OS threads somehow work smoothly with virtual threads, and trying to find a way to do that is not a goal of ours (unless we find some overwhelming demand for that).

— Ron

> On 14 Jul 2023, at 14:35, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> In my particular case, I would link the file I/O methods twice. One with the "is blocking" option and one without. Depending on how the file is opened, I know whether or not blocking is expected and can invoke the appropriate method.
> 
> The "a byte at a time" case is not something that I'd worry about, considering that the advice has always been to use buffered I/O streams when accessing files in tiny chunks. Has the extra overhead been measured with respect to the overhead of making a system call? On different operating systems?
> 
> 
> On 2023-07-14 05:54 AM, Alan Bateman wrote:
>> On 14/07/2023 13:39, Robert Engels wrote:
>>> Why do you say that Blocker usage is non optimal. I think that when the common IO operations are VT “reworked” the remaining cases being handled by Blocker seems simple and reasonable.
>> Right now, it adds a bit of overhead and some contention, but mostly this is only an issue when doing very short lived operations, like reading a file a byte at a time and the file is already in the file system cache.
>> -Alan



More information about the loom-dev mailing list