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

[eric.caspole at oracle.com]

On 6/3/20 1:28 PM, Daniel D. Daugherty wrote:
> On 6/3/20 1:24 PM, eric.caspole at oracle.com wrote:
>>
>> 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.
> 
> By using update1() -> update2() you get the recursive locking
> that you're look for right? I thought part of the point was to
> optionally throw the exception thru a couple of stack frames
> where the monitor was held in each frame...
> 
> Dan

Yes, that is a case we want to cover here. And having a second case 
without update1 in the middle gives a point of comparison for tracking.

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