RFR: JDK-8154343: Make SATB related code available to other GCs

[Kim Barrett]

> On Jul 27, 2018, at 7:02 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Am 28.07.2018 um 00:44 schrieb Kim Barrett:
>> 
>> I’m also not sure I like the proposed new interfaces generally, but
>> I’m still thinking about what I might like as an alternative.  Performance
>> may drive some of that.
> 
> I also don't like the new interfaces much. Especially polluting
> CollectedHeap with something that GCs might not need (and in-fact, only
> two known GCs currently need, and only one of them is currently in
> mainline OpenJDK).
> 
> Maybe we can define an interface like SATBSupport that provides these
> new methods and have GCs pass in an implementation subclass at creation
> time?
> 
> With regards to performance, I think we can templatize the filter-loop:
> filter() would call out to SATBSupport::filter_driver() which would call
> back to SATBMarkQueue::filter_impl<SATBSupportType> with known
> SATBSupportType which would then call the non-virtual and inlineable
> SATBSupport::retain_entry() of the speficied type. This should solve all
> performance concerns I think.

I have in mind something that I think will be simpler than that, but need
to spend some time working through the details.  I’ll let you know what
I come up with.

>> You missed updating precompiled.hpp, which has #include “gc/g1/PtrQueue.hpp”.
> 
> Ha, oops. And here I thought I'm doing something good by always building
> with --disable-precompiled-headers ;-)

Our automated build system does both, else I would have missed it too, since
I always do my local builds without precompiled headers.

I think the simplest solution in this case is to just remove the two offending
includes.  I don’t think there are enough references to those classes to make
“including" them everywhere worthwhile anyway.