Native methods and virtual threads

[Brian S O'Neill]

In the context of the JDK itself, it's quite easy to classify all native 
blocking operations as socket I/O or file I/O. Sockets can use epoll (et 
al), and files can use io_uring (et al). Once complete, the JDK has no 
need to use the special Blocker class.

This is not the case in the context of the FFM subsystem. The goal is to 
make it easier to link to native libraries, and those libraries might 
perform blocking operations. They might also perform very long 
computations. If the library doesn't have an appropriate non-blocking 
alternative, then it might not interact well with virtual threads. It's 
easy to dismiss the problem by saying, "don't use virtual threads," but 
earlier I outlined a legitimate use case in which a server interacts 
with SQLite.

One workaround is to pass messages through a special queue, where one 
side is driven by a pool of platform threads, but this adds complexity 
and overhead. I'm proposing a linker option hint. The hint might utilize 
the Blocker class, or might automatically set up a messaging passing 
queue if it makes more sense. Or it might be ignored entirely if at some 
point stacks with native threads can be unpinned.


On 2023-07-14 07:00 AM, Ron Pressler wrote:
> 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
>