RFR (S) : JDK-8245043 : Simplified contention benchmark
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Jun 3 17:28:36 UTC 2020
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
>>> 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.
>> *) "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
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...
> 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