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

[Florian Weimer]

* David Holmes:

> Hi Florian,
>
> On 28/11/2019 8:30 am, Florian Weimer wrote:
>> * David Holmes:
>> 
>>> For a micro-benchmark like that sure. But is that at all representative
>>> of real modern code? We know some of the really old benchmarks used
>>> synchronized collections and StringBuffer extensively and so they also
>>> benefit from biased-locking. But more modern benchmarks are not showing
>>> any benefit.
>>>
>>> We'd like to know the impact on real applications but we have no way to
>>> know that a-priori. So we're either stuck with the burden of supporting
>>> biased-locking forever, or we flip the switch to turn it off and see if
>>> it causes too many issues. Unless you see another way to determine this?
>> 
>> How important is biased locking for JNI libraries which use
>> synchronization to prevent incorrect concurrent use of objects (with
>> JNI resources) from resulting in arbitrary memory corruption?
>> 
>> I've always thought that biased locking is really attractive for this
>> scenario because these locks are just overhead if the library is used
>> correctly.  One wouldn't want to use ReentrantLocks here precisely
>> because of the benefits of biased locking.
>
> It depends on exactly what you mean. If you use the JNI MonitorEnter 
> function it revokes any bias and inflates the monitor thus making 
> BiasedLocking irrelevant to that scenario. If JNI calls a synchronized 
> Java method it works the same as a non-JNI call of that method.

Sorry, I meant synchronized wrappers in Java code, calling JNI methods
which do no synchronization.  Kind of what SWIG does for delete(),
only consistent for everything.