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

[Florian Weimer]

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

On the other hand, the SWIG binding generator does not systematically
emit such synchronization.  There is an attempt to deal with the
finalization race condition, but I have doubts regarding its
effectiveness because the SWIG-generated code does not ensure object
reachability after JNI calls (which are apparently implemented as
static native methods).

If biased locking were determined important to JNI code, it would be
interesting to consider how its performance gains relate to the
general JNI overhead.