RFR (S) : JDK-8245043 : Simplified contention benchmark

eric.caspole at oracle.com eric.caspole at oracle.com
Wed Jun 3 17:24:20 UTC 2020

On 6/3/20 11:39 AM, Aleksey Shipilev wrote:
> On 6/3/20 5:25 PM, eric.caspole at oracle.com wrote:
>> Hi Aleksey,
>> Thanks for your comments! I simplified the whole thing while still
>> getting the behavior and profiles I am looking for, that is, all the
>> recursive locking and throwing can make this micro spend several percent
>> in the Hotspot C++ locking code in enter/exit/inflate etc. So the point
>> of this is to make a relatively easy way to exercise the locking code by
>> setting the parameters as needed.
>> http://cr.openjdk.java.net/~ecaspole/JDK-8245043/02/webrev/
> *) "ThreadParam params" is unused in both cases?

Good catch, I will fix it.

> *) Does it still make sense to have separate update1, update2?

It spends a few percent more time in the locking code when the update1 
middle method is used, I think it is a little better for testing these 

Although I could add a second benchmark method that calls update2 
directly, that may be useful for regression tracking.

> Otherwise looks good.

More information about the hotspot-runtime-dev mailing list