Questions regarding VirtualThread pinning JDK21 vs loom EA build

[Alan Bateman]

On 27/02/2024 10:04, Christian Ortlepp wrote:
> :
>
> First, regarding pinning on monitor-enter: Before this talk was 
> published I already stumbled onto this Issue when testing 
> VirtualThreads. I was very surprised to see that this limitation was 
> not mentioned in the JEP (along with the other  pinning causes) or any 
> other official communication (Or did I just miss something?). 
The section "Executing virtual threads" in JEP 444 [1] covers this topic.


> And this kind of pinning of course also does not trigger the 
> stacktrace dumps from "-Djdk.tracePinnedThreads=full". The latter is 
> probably due to the fact that it would spam the log so much that the 
> tool would be useless to begin with, but why was this limitation not 
> as publicly disclosed as the other ones? It seems to me that pinning 
> on monitor-enter has the same performance-degrading characteristics as 
> pinning while monitor enter, and the same safety issues too (i.e. the 
> possibility to easily introduce deadlocks that would not occur using 
> platform threads). Lastly, did I understand you correctly that the 
> current EA build not only fixes parking-while-holding-a-monitor but 
> also pinning-on-monitor-enter?
The current EA build releases the carrier in both cases (unless pinned 
by a native frame or other reason).

The JFR events are improved in the EA builds so there is a JFR event 
when blocking on monitorenter when pinned, parking when pinned, or 
Object.wait. The system property jdk.tracePinnedThreads is now ignored 
as it was problematic for several reasons.


>
> Second, in the FOSDEM talk Alan showed FileChannel.open()/read() as an 
> example of filesystem I/O that expands the parallelism of the ForkJoin 
> scheduler. Now FileChannel is a java.nio.* API. I was under the 
> impression that java.nio.* works gracefully with the current 
> VirtualThread implementation, since in java.nio.* the actual blocking 
> is done by the background nio threadpool and not the caller. From your 
> example I assume that not to be the case. Is it possible to (easily) 
> distinct which methods in java.nio.* execute the I/O call themselves, 
> and which delegate this action to the nio pool?
FileChannel provides a synchronous API. AsynchronousFileChannel which 
defines an asynchronous I/O API. You mention thread pools so maybe you 
are asking about AsynchronousFileChannel rather than FileChannel?

In any case, in EA builds, parallelism is temporarily increased around 
synchronous I/O ops when the file is opened for non-buffered I/O. More 
specifically, direct I/O with FileChannel or when using the synchronized 
I/O options (SYNC/DYNC) with FileChannel or RandomAccessFile. It wasn't 
been profitable to increase parallelism for buffered I/O cases, e.g. 
file I/O on SSD where the I/O ops is a small number of microseconds.


>
> Third, regarding io_uring: Are only "functional" problems the cause 
> for io_uring not being available as of now (i.e. difficult 
> implementation of io_uring interface in the JDK) or also 
> quirks/problems of the io_uring API itself, especially security-wise. 
> I read that google actually disabled io_uring on many of their 
> production systems due to security concerns 
> (https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html). 
> Is this also a concern to the JDK/loom team?
I won't comment on security issues here. The challenges around io_uring 
stem from the variations across kernel versions in the Linux 
distributions and "ownership" of the submission/completion rings in user 
space. There are many different design and implementations choices 
around this.

-Alan

[1] https://openjdk.org/jeps/444#Executing-virtual-threads