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

[Aleksey Shipilev]

On 11/18/19 2:50 PM, David Holmes wrote:
>>    http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-November/004333.html
> 
> The discussion is very similar to the to-and-fro we have also had in Oracle over the past couple of
> years. Some benchmarks show benefit from biased-locking because they (over?) use uncontended locking
> which is exactly what biased-locking was designed to cheapen. But do we care about such benchmarks?
> Do they tell us anything interesting about the impact on real applications?

For the benchmarks that exercise library code, I believe they serve as data points against the idea
that "real code" is already (re)written in such a way that effectively unsynchronized accesses never
acquire (biased) locks. Also partially explains why users see regressions on their stacks with BL
disabled. For example, I suspect the regressions on Xml* workloads is something about what old^W
stable Xalan/Xerces code does (maybe self-written synchronized collections?).

> Can you share which users complained, and for what applications?

Alas, assorted private communications, so I am not at liberty to share the details. But some of
those are proverbial "real applications". This is why I say that disabling BL is questionable from
the performance standpoint, and deprecating the flag is dubious today.

Note that Shenandoah basically did the limited form of the experiment you seem to suggest (disable
BL by default and see if there are many complaints) -- and there were substantial throughput losses
which made us bite the latency bullet and enable BL back. This tells me the larger experiment would
yield even more regression reports, hopefully public ones!

> Well as I said we've already been sitting on this for quite a while. :)

It does not matter how much time anyone spent internally reminiscing about this. What is relevant is
how much time the external users got to notice the regressions and provide their input before the
feature is deprecated/purged. Based on what we had with Shenandoah, I would say it would take a few
short-term-support releases to gather that data. I believe deprecation should be off the table until
that happens.

My bottom line: disabling biased locking experimentally is maybe okay, if you need more data to make
the decision, especially if that default is contained in a short-term release; deprecating BL is not
okay at current juncture.

>From another perspective, if the intent here is to ignore all performance regressions for the sake
of better maintainability, I get that part! But then we should be upfront about this cost, instead
of arguing that No True Scotsman^W^W Real Application is affected. A JEP is probably in order, that
would capture risks, assumptions, and the mitigations that library and application writers can
deploy to recuperate the throughput losses (like "don't use synchronized on the paths are provably
not contended ever; avoid StringBuilder, Vector, Collections.synchronized*(); rewrite synchronized
to atomics/stamped locks; etc.").

-- 
Thanks,
-Aleksey