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

[David Holmes]

On 19/05/2020 8:38 am, Sergey Kuksenko wrote:
> 2. Does "volatile Table[] sharedLocks" need to be volatile?

I think the intent is that the array needs to be published safely - 
though without knowing full details of JMH it is impossible to see how 
the array creation and filling relates to threads being started (ie does 
setup() happen-before any threads are started? If so then publication is 
already safe.) But if the intent is to do safe publication then 
refreshArray is wrong:

   85     void refreshArray() {
   86         sharedLocks = new Table[locksSize];
   87         for (int i = 0; i < locksSize; i++) {
   88             sharedLocks[i] = new Table(i);
   89         }
   90     }

you would need to create a tmp array and fill it, then assign to 
sharedLocks with the volatile write that publishes the array.

> On 5/18/20 1:33 PM, eric.caspole at oracle.com wrote:
>> Hi everyone,
>> Could you review this new JMH for lock contention and wait which 
>> started from trying to simplify what happens in Dacapo H2, but also I 
>> added more parameters to vary the size of time spent in locked and 
>> unlocked regions to cover more scenarios. Some combos of parameters 
>> here do track what we have observed in H2 in builds across 15. This 
>> should be easier to analyze going forward.

Hard to understand the logic unless you already know JMH (which I don't).

>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8245043
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ecaspole/JDK-8245043/01/webrev/

  135             Object waiter = null;
  136             while (waiter == null) {
  137                 waiter = sharedLocks[state.sharedLockIndex];
  138             }

why is the while loop needed? The array entry can't be null (if the 
array is safely published).

Cheers,
David
-----

>>
>> Thanks,
>> Eric