Native methods and virtual threads

[Jorn Vernee]

 > 2. When it executes a native method or a foreign function.

Note that either way we can never unmount a virtual thread that has 
native frames on the stack. In native code it is possible to have 
pointers into the thread stack. These pointers would be left dangling if 
the virtual thread, and its native frames, were unmounted from the 
carrier thread. The 'Blocker' API just signals to the thread pool that a 
carrier thread belongs to, that more carrier threads should be spawned 
to compensate for the blocked carrier thread.

Jorn

On 13/07/2023 22:29, Brian S O'Neill wrote:
> 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.
>>