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

[eric.caspole at oracle.com]

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

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

> Otherwise looks good.
>