RFR: 8201316: Move G1-related static members from JavaThread to G1BarrierSet

[Per Liden]

Hi Aleksey,

Yep, I'll integrate both changes at the same time.

I don't actually think this causes a lot of work for you. As you say, 
you can just continue to hack into G1 for now (not a lot of work, and no 
better or worse than what you do now), and break that dependency at some 
point later (doesn't look like a lot of work either, unless I'm missing 
something).

cheers,
Per

On 04/10/2018 04:16 PM, Aleksey Shipilev wrote:
> On 04/10/2018 02:09 PM, Per Liden wrote:
>> On 04/10/2018 01:19 PM, Aleksey Shipilev wrote:
>>> On 04/10/2018 01:05 PM, Per Liden wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201316
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8201316/webrev.0
>>>
>>> I actually think we should instead move SATB machinery into gc/shared (Shenandoah uses it!), and
>>> leave these static members in the JavaThread.
>>
>> I agree, and I don't think this change stops you from working towards that goal. As you know, we're
>> working towards having more appropriate abstractions to make GCs more pluggable, which this RFE and
>> the followup change JDK-8201318 (sent to hotspot-dev) is trying to address.
> 
> All right, fine! As long as these changes go in hand-in-hand, Shenandoah can temporarily hack into
> satbMarkQueue and inject the reference to it in its own BarrierSet and ThreadLocalData.
> 
>> With the G1-specific stuff is cleaned out from JavaThread, I think it will be easier for you to see
>> what G1-dependencies you really have in Shenandoah, and start work to break those dependencies or
>> move code to gc/shared if needed.
> 
> We do know what dependencies Shenandoah has. The development convenience is about the choice between
> the destructive cleanup that requires dealing with immediately, or the cleanup that can still be
> worked around to keep the project functional, albeit in a hacky way. This pair of changes seems the
> be the latter.
> 
> Thanks,
> -Aleksey
> 
>