Native methods and virtual threads

[Brian S O'Neill]

It's pretty easy to identify potential issues without relying on JFR. In 
my example, I'm concerned with file I/O, but consider the SQLite use 
case. Any query can block the thread for an indefinite amount of time, 
and so an application which is legitimately using virtual threads and 
also using SQLite will need to tweak virtual thread settings or come up 
with workarounds.

The FFM API already supports linker hints, and it seems to me that an 
"isBlocking" or "canBlock" Linker.Option would be easy to add. Since 
it's just a hint, it can be safely ignored as well.

These two unmounting scenarios from JEP 444 keep getting discussed:

     1. When it executes code inside a synchronized block or method, or
     2. When it executes a native method or a foreign function.

Work is underway to address item 1, and item 2 can be partially 
addressed with a new linker hint. Special hints or modes could be added 
to JNI as well, but the FFM API is the path forward.


On 2023-07-13 12:25 PM, Ron Pressler wrote:
> Hi.
> 
> It’s something to consider if it turns out to be an issue.
> 
> Blocking OS threads in code that is called from virtual threads is not a problem in itself; it’s just something that *could* turn into a problem if the operation is very frequent and its duration is long. For the time being, I think the right approach is to rely on JFR for detecting performance issues when they occur before devising a mechanism to prevent a potential problem, as we don’t yet know how serious it is in practice.
> 
> — Ron
> 
>> On 13 Jul 2023, at 17:06, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> This seems like a potentially nice suggestion. CC'ing loom-dev.
>>
>> Maurizio
>>
>> On 13/07/2023 17:04, Brian S O'Neill wrote:
>>> In my project, I depend heavily on native methods which perform file I/O. These operations might block the current thread, but this isn't a concern, and in some cases, blocking is desirable. With virtual threads, I am concerned. I don't want to have to rewrite all my code to workaround any potential issues.
>>>
>>> Inside the JDK, any calls which might block inside native code use the internal Blocker class to help ensure that virtual threads aren't starved of carrier threads. This class is internal, and I think it should stay that way. It's easy to be misused.
>>>
>>> However, if it were possible to indicate that a downcall handle might block, it would be incredibly useful. This isn't likely to be misused simply because it wouldn't be applicable to ordinary code.
>