Native methods and virtual threads

[Ron Pressler]

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.