RFR: Optimizing best of two work stealing queue selection

[Zhengyu Gu]

Hi,

>>> My current overall comment of this change is threefold:
>>>
>>> - why not immediately contribute in jdk/jdk? There does not seem to
>>> be anything Shenandoah-specific about it.
>>

I will do the same measurement on ParallelTaskTerminator, if I see 
similar results, I will purpose upstream directly.

Thanks,

-Zhengyu


>> All my observation is based Shenandoah implementation, which has a
>> few parts that diverged from upstream (e.g. termination protocol and
>> queue set)
> 
> This change has no impact on the termination protocol. The change
> itself looks like it almost applies to the current mainline code. I
> will give it a try.
> 
>>>
>>> - I do not see a point in having an optional switch; it seems
>>> obviously superior, and the paper already provided significant
>>> feedback on its usefulness. Aleksey and me will also do
>>> measurements. If there were a switch to enable this I would make
>>> this one runtime (i.e. as parameter to the queueset), and only
>>> maybe, if I really wanted a global, use it as default value for
>>> that parameter.
>>
>> I would love to drop the switch, if you guys measurements can
>> confirm what I observed, and not negative impacts.
>>
>> I am also going to run some tests over the weekend.
> 
> Okay.
> 
>>> - I would try to make some effort to make this "last-queue-id"
>>> thread-local. I guess there will be lots of memory ping-pong
>>> between threads reading/writing to the same cacheline(s) all the
>>> time.
>>>
>>> I.e. at least use a PaddedArray, or pass the last-queue-id to
>>> steal_best_of_2() like the seed parameter.
>>>
>>
>> Yes, it was also in my mind, will fix it.
> 
> In case you opt for the second, instead of adding parameters every time
> you need a new thread local variable, it might be useful to add a
> single "context" struct containing them, and pass only that around.
> 
> Might give nicer looking code.
> 
> Thanks,
>    Thomas
>