Using BufferedReader and InputStreamReader with virtual threads
Alan Bateman
Alan.Bateman at oracle.com
Mon Aug 10 15:17:49 UTC 2020
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
More information about the loom-dev
mailing list