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

[Daniel D. Daugherty]

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


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