RFR [14]: 8231707: Improve Mutex inlining

David Holmes david.holmes at oracle.com
Wed Oct 2 22:46:07 UTC 2019


Hi Claes,

That seems fine to me.

Thanks,
David

On 3/10/2019 12:56 am, Claes Redestad wrote:
> Hi,
> 
> gcc thinks Mutex::lock(Thread*) is too big to be inlined into
> Mutex::lock(), which means we often do an extra call when grabbing a
> mutex. By outlining the contended loop into a separate method, then
> (uncontended) lock(Thread*) gets inlined into lock(), which means
> uncontended mutex locking will perform one less call. This speeds
> things up somewhat in targetted microbenchmarks[1].
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8231707/open.00/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8231707
> 
> Robbin Ehn and I also did a more elaborate experiment[2] to make
> Mutex::lock/try_lock/... inlineable in full. This interestingly does
> slightly worse on the targetted micro, while increasing the size
> of the JVM more aggressively.
> 
> Test: tier1-3
> 
> Thanks!
> 
> /Claes
> 
>   [1]
>   Reference.hasReferencePendingList will use a mutex in the VM:
>   http://cr.openjdk.java.net/~redestad/8231707/ReferenceBench.java
> 
>             Mode  Cnt   Score   Error  Units
>   baseline  avgt   20  70.913 ± 2.381  ns/op
>   patch     avgt   20  61.014 ± 3.545  ns/op
> 
>   [2] http://cr.openjdk.java.net/~redestad/8231707/alternative.00
>             avgt   20  63.150 ± 4.135  ns/op


More information about the hotspot-runtime-dev mailing list