Biased locking Obsoletion

[Andrew Dinn]

On 06/11/2020 18:36, Andrew Haley wrote:
> On 11/6/20 5:29 PM, Doerr, Martin wrote:
>> My impression is that modern workloads are fine without BL, so typical JDK15 users will probably not notice it was switched off.
> 
> I don't believe they are, because there are several (many?) places in
> the Java library that perform badly. In particular, see JDK-8254078,
> DataOutputStream is very slow post-disabling of Biased Locking.
> 
> This is not a solved problem, and I don't know what a "typical"
> user is, but some users may experience significant performance
> degradation. This is not a solved problem.
Red Hat has been conducting an internal review of our middleware 
products to assess the impact of biased lock removal. For the cases we 
have been able to test (which we acknowledge are /far/ from 
comprehensive) we have not found any clear picture of outright gain or 
loss in performance in the middleware code per se. We have almost always 
seen small improvements or degradations in performance (sometimes in the 
same product with different workloads).

The only case where we have seen a significant loss of performance with 
biased locking disabled was for our Transactions product when running in 
a /non-production/ operational mode. That specific degradation was not 
directly caused by our middleware implementation. It resulted from 
unnecessary and unavoidable synchronization overheads in /standard/ JDK 
library code that the middleware relied on (specifically, the 
DataOutputStream issue that Andrew Haley addressed in JDK-8254078).

Note that this issue did not affect /production/ operational modes 
because in those modes the extra synch costs were amortized across 
storage access costs. We think the same story most likely explains the 
lack of significant degradation for our other middleware products. 
However, that does not mean the JDK gets the all clear. Indeed, it may 
not even leave our middleware in the clear. With only limited testing we 
cannot be sure storage costs will mask synchronizations costs in all 
production use cases.

More generally, it is quite probable that there are applications built 
over DataOutputStream or other JDK XXXOutputStream APIs (perhaps also 
other class hierarchies) which don't suffer from synchronization costs 
at present but are going to hit problems when biased locking is removed. 
The argument from David Holmes that:

   Real "old" code would have been updated years ago to move away from 
the synchronized library classes

misses the obvious point that "real, old code" and, quite possibly, some 
"real, relatively new code" will not have manifested performance issues 
when using these old skool JDK classes with biased locking enabled. 
Relying on users to have already fixed problems when they are not 
visible prior to the deprecation change seems to me, at best, unrealistic.

I also feel that relying on users to come up their own alternatives to 
work around the limitations of these /standard/ classes -- if and when 
problems do turn up -- would be an inadequate response. If a need 
emerges for unsynchronized, non-thread safe alternatives to JDK library 
classes because of this JVM change then I think it would be appropriate 
for that need to be met by upgrading the JDK itself to provide either an 
alternative class or alternative mode of operation for the existing 
class. A common, well built, integrated solution would be preferable to 
many ad hoc alternatives.


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