Biased locking Obsoletion

[David Holmes]

On 9/11/2020 10:11 pm, Andrew Dinn wrote:
> 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.

We are talking about the ancient fully-synchronized "collection classes" 
primarily: Vector and Hashtable. The problems with these being fully 
synchronized has been well known since Java 1.1 and there have been 
alternatives since 1.2 with the proper Collection classes. The migration 
away from these old classes even predates the introduction of BL!

The DataOutputStream issue was a bit of a surprise as the code is 
grossly inefficient as written even with BL helping it out. I'm 
surprised nobody spotted this much earlier, but I'm glad that it has now 
been spotted and fixed. If other cases are discovered then we can also 
fix them.

> 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.

I think that is overstating the case somewhat.

David
-----

> 
> 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
>