RFR 8231264: Disable biased-locking and deprecate all flags related to biased-locking
David Holmes
david.holmes at oracle.com
Wed Nov 27 00:28:19 UTC 2019
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
>
More information about the hotspot-runtime-dev
mailing list