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

[Doerr, Martin]

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.

I assume that the code which was written at that time still exists.
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.
Not everyone wants to write an additional single-threaded version if BiasedLocking can do the job.

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


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


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.

Best regards,
Martin