Biased locking Obsoletion

[Alan Bateman]

On 20/10/2022 13:20, Andrew Dinn wrote:
> :
>
> This code slows down considerably when biased locking is not 
> available. Of course, the problem is that the API only provides a 
> synchronized method, BufferedInputStream.read(), for reading single 
> bytes. So, without biased locking (or some improved version of 
> non-biased locking) client code that needs to perform per-byte 
> read+consume steps is going to be harmed.

A general point is that you are more likely to see this with the java.io 
APIs because they date from early JDK releases where they was a tenancy 
to synchronize everything. The synchronization is not specified and for 
most of these classes it just doesn't make sense to have several threads 
reading from a stream. However, there is 25+ years of usage, and there 
is concurrency if there is async close, so it would not be easy to just 
remove it. The DataOutputStream change that you linked to was okay 
because the class wasn't thread safe already and part of the change was 
to add a disclaimer on thread safety to the javadoc.

I don't know know which JDK release was used for the test but BIS 
changed in JDK 19 to use j.u.concurrent locks when a BIS is constructed 
directly. It may be that it could be changed further to use a stamped 
lock but it would it would requires exclusive access. Just mentioning 
this because I think lock coarsening is monitors only (BIS does use 
monitors when subclassing as existing code may assume synchronization in 
the super class).

-Alan