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

[Sergey Kuksenko]

Looks well.

Some minor questions:

1.

>  58     static class Session {
>  59 
>  60         int id;


Name "id" implies that the id unique. But it is inited with random value 
which maybe not unique. That confusing at start, later it's 
understandable that it's doesn't matter.

2. Does "volatile Table[] sharedLocks" need to be volatile?

3.

   96     @State(Scope.Thread)
   97     public static class ThreadState {
   98
   99         int threadCompute = random.nextInt(Runtime.getRuntime().availableProcessors());
  100         Session perThreadLock = new Session(threadCompute);
  101         int sharedLockIndex = random.nextInt(locksSize);
  102     }

I understand that it doesn't matter for this benchmark behavior, but I 
think  it would be better to add @Setup method to ThreadState and use 
"org.openjdk.jmh.infra.ThreadParams" for control and get rid of 
"Runtime.getRuntime().availableProcessors()".



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.
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8245043
>
> Webrev:
> http://cr.openjdk.java.net/~ecaspole/JDK-8245043/01/webrev/
>
> Thanks,
> Eric