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

David Holmes david.holmes at oracle.com
Thu Nov 28 04:16:30 UTC 2019


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.

David

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


More information about the hotspot-runtime-dev mailing list