RFR: JDK-8209118: Abstract SATBMarkQueueSet's ThreadLocalData access

[Kim Barrett]

> On Aug 8, 2018, at 11:35 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Hi Kim,
> 
> Thanks for reviewing!
> 
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8209118
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8209118/webrev.00/
>>> Testing: hotspot/jtreg:tier1 (fastdebug)
>>> 
>>> Can I please get reviews?
>>> 
>>> Thanks,
>>> Roman
>> 
>> Oops, we seem to have mis-communicated; I was working on a similar
>> change.  You published first, so we'll go with yours; it makes for an
>> easy review, since the code looks very familiar :)
> 
> Oh, sorry. Well possible that I missed something between travelling and
> some crazy stuff here.

I think we just left it unclear which of us was going to do this part.

>> One other piece of work related to sharing the SATB buffer code is
>> G1SATBBufferEnqueueingThresholdPercent.  That's going to need to be
>> renamed or something, which will involve the CSR process.
> 
> Yeah. Or else introduce new $GCSATBBufferEnqueueingThresholdPercent ;-)

If it’s going to be a product flag (like the present G1 flag is), that’s going to need
the CSR process too.  And we’ll also need to change how it’s checked, since
it is presently a direct reference to the option in what we want to be shared code.
Probably the way to do that would be to add a member to the QSet that is
initialized (from GC-specific code with the GC-specific value).

Let’s deal with this separately from this change though.

> Incremental:
> http://cr.openjdk.java.net/~rkennke/JDK-8209118/webrev.01.diff/
> Full:
> http://cr.openjdk.java.net/~rkennke/JDK-8209118/webrev.01/
> 
> Better?

Looks good.