Biased locking Obsoletion

[Andrew Dinn]

I'm reviving this discussion from an old thread here because of a new 
Red Hat customer issue that has emerged thanks to removal of biased locking.

The customer has some code to compare data in two input streams byte by 
byte. The benchmark is fairly simple, comparing each file in a suitably 
long list with itself byte for byte. It includes code like this at its core:

         boolean contentChanged = false;
         BufferedInputStream oldContent = ...;
         BufferedInputStream newContent = ...;
         try {
             int newByte = newContent.read();
             int oldByte = oldContent.read();
             while (newByte != -1 && oldByte != -1 && newByte == oldByte) {
                 newByte = newContent.read();
                 oldByte = oldContent.read();
             }
             contentChanged = newByte != oldByte;
         } catch (IOException e) {
             contentChanged = true;
         }
         ...

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.

Clearly with this simple example the slowdown can be worked round by 
doing bulk reads but that is not really the point. The model for client 
use implemented by the InputStream API suffers from the same issues that 
mar the OutputStream API. What makes this especially egregious is that 
this is a *buffered* stream. Buffering is supposed to make piecemeal 
access more efficient and, no doubt, it does when compared to doing 
individual reads at the device level. Still, using buffered in the name 
definitely jars with a client API model that presumes concurrent 
consumption and punishes byte by byte access.

I am not clear why the lock coarsening has not kicked in with this input 
stream case. That optimization was found not to be effective in the case 
of the output stream code but the problem was easily fixed (see 
https://bugs.openjdk.org/browse/JDK-8254078).

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill