Native methods and virtual threads

[Ron Pressler]

> On 13 Jul 2023, at 21:29, Brian S O'Neill <bronee at gmail.com> 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.

Blocking an OS thread for some time may be a problem in some cases and not at all in others, and it’s not a bigger problem for virtual threads than it is for thread pools. 

> 
> 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.

That something is easy to do doesn’t mean it should be done. Blocking a thread in a native method may be not an issue at all in some cases, and in cases where it is both frequent and lengthy it may be a problem the JDK can’t solve (i.e. the system’s throughput will be bounded by the number of threads the OS can support and that’s that).

It sounds like a reasonable suggestion if experience shows us that there is, indeed, something to be done here, so I would suggest we revisit it after people gain more experience with both virtual threads and FFM. But until we know what if any actual problems people run into due to blocking, I’m not sure we should propose solutions.

> 
> 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.


Item 2, like item 1, refers to pinning not to blocking, namely native code that calls back into Java code, which puts the thread in a pinned state where it is more likely to block the OS thread. This is automatically detected anyway today (we’ve just chosen not to compensate, a decision we may change in some or all situations due to the experience we’re gaining).

— Ron