RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking

[David Holmes]

On 27/11/2019 4:11 am, Doerr, Martin wrote:
> Hi David,
> 
>> Biased-locking is a very old optimization for uncontended locking, based
>> on a time when there was heavy single-threaded use of synchronized data
>> structures, and where actual lock/unlock atomic operations were very
>> expensive.
> 
> I don't understand which role the age of an optimization plays.
> The only thing I can imagine is that old optimizations may be subject for reevaluation.
> I'm ok with doing that.

That's exactly what role the age of an optimization plays. We've had 
numerous optimizations put in place to deal with the behaviour of 
hardware/OS at the time, and which subsequently becomes of no value when 
hardware/OS changes. We are reevaluating these constantly.

> I assume that the code which was written at that time still exists.

I would expect some still exists simply because you can get stuff from 
20 years ago. But the vast majority of non-trivial code that may have 
had extensive use of Vector/StringBuffer/Hashtable would have been 
rewritten to use more efficient single-threaded data structures when 
MT-safety was not needed (which is the uncontended case for which BL 
applies).

> And I think it's a valid approach to use a library which was written for a MT usage for a single-threaded use case.

It may be functionally "valid" but not the most efficient/performant.

> Not everyone wants to write an additional single-threaded version if BiasedLocking can do the job.

That's really clutching at straws. Based on that we'd never have defined 
StringBuilder to replace StringBuffer.

> I don't think lock/unlock atomic operations have become cheap.

They have certainly become cheaper.

> 
>> It is very complex and highly intrusive code. Every time "we"
>> have had to make changes to object monitor support, or safepoint
>> support, we have had to deal with the added complexity that
>> biased-locking introduced and "we" have asked ourselves many times
>> whether "we" can just get rid of this old optimization.
> 
> I understand this (also had to do some work for it). IMHO this is only a good argument if the benefit is small which should get proven.

We have no practical means to a-priori establish the benefit of BL to 
real world, significant, applications, but we expect it to be of limited 
benefit for the reasons outlined. All we can do is turn it off (with a 
way to turn back on) and see if our expectations are borne out. If our 
expectations are way off then we would hope that early access adopters 
would reflect that very quickly.

> 
> But I see that BiasedLocking is kind of disturbing for other features.
> E.g. UseRTMLocking in addition to project loom.
> Transactional memory fans would probably be happy about the deprecation because it can't be used together.
> It'd be also interesting to try UseRTMLocking together with project loom.
> 
> 
> I guess there will be more discussion when the JEP arrives.

I think a JEP is complete overkill for this. I don't see anything to be 
added to the discussion that hasn't already been said. Additional 
developer opinions won't change anything. Only real world data will show 
whether BL is still of sufficient value to make it worth keeping.

Regards,
David
-----

> 
> Best regards,
> Martin
>