Using BufferedReader and InputStreamReader with virtual threads

[Alan Bateman]

On 10/08/2020 15:37, karsten at soit.de wrote:
> Hi @all,
>
> i started experimenting with loom and virtual threads [thanks for this 
> nice project].
> I know, that suspending virtual threads leads to thread-pinning if 
> synchronized frames are on the stack.
> My question is: when using classes like BufferedReader or 
> InputStreamReader on blocking streams (e.g. TCP-Inputstreams) the 
> os-workerthread will be blocked (virtual-thread is unable to yield), 
> since the abstract Reader-Class and classes like 
> sun.nio.cs.StreamDecoder use internal synchronization (read()-method of
> tcp-stream is called from synchronized-block).
> I think, this may prevent many existing libs (e.g. jdbc-drivers) to 
> benefit from virtual threads. Is there a plan to optimize these 
> classes to be more 'virtual-thread-friendly'?
Yes, java.io is awkward because built-in monitors are used extensively 
and several of the APIs expose lock objects to sub-classes.

The approach that we've been using is to separate direct uses of these 
APIs from cases that extend the java.io classes. So if you use a 
BufferedInputStream or BufferedOutputStream directly then they will use 
j.u.concurrent locks and blocking in read/write won't pin the carrier 
thread. If you extend these classes then you are out of luck because the 
sub-class may assume all methods are synchronized. OutptuStreamWriter 
(and the underlying sun.nio.cs.StreamDecoder) and PrintStream are other 
examples that do the same. I thought we had changed InputStreamReader 
(and sun.nio.cs.StreamEncoder) but it seems not - this may be an 
oversight so I'll look into that.

So are you running into issue? Are running with 
-Djdk.tracePinnedThreads=full to find these issues?

-Alan