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

[John Rose]

+1 on David’s points.  I’d like to add that, as workloads and hardware changes,
the JVM needs to keep up.  An obvious case of this is adding and tuning
optimizations, an activity generally regarded as safe, although one users'
optimization might be another’s performance pothole.  And sometimes
we need to delete an optimization that no longer pays for itself, like BL.
In both cases (adding and deleting) if somebody shows us a problem, we’ll
fix it.  But in both cases we need to make progress.

BL is more than just a sunk cost and an innocuous add-on.  It is an ongoing
maintenance burden which slows us down.  (Like CMS was, in fact.)
It has been costly through its entire run, more than many similar features.
It seems simple, but as a transparent implementation of Java’s locking
semantics, it needs to handle every corner case, and that least to nightmarish
complexity.

Something like BL would be nice to have, but it can’t just piggy-back on
Java’s current locking model, barring heroics we don’t want to perform.
Something more explicit is required to make it feasible, an API or user model
that ties an object more firmly to the thread that needs to work on it.  We
are exploring this space in Panama under the rubric of “confinement”, for
foreign resources.  I hope it will also bear fruit for the Java object model.

For now, I will be glad to see us prove (by experience) that BL is no longer
needed on today’s workloads and hardware, and can be deleted.  Current
evidence indicates this is possible. Barring new evidence, we need to clear
the decks here for future work.

— John

On Nov 26, 2019, at 4:28 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> 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