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