RFR: 8201316: Move G1-related static members from JavaThread to G1BarrierSet
shade at redhat.com
Tue Apr 10 14:16:22 UTC 2018
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev