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

[Kim Barrett]

I’ve started looking at this.

> On Jul 27, 2018, at 7:17 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> This change moves SATB related code to gc/shared from where it can be
> used by other SATB GCs. I'm doing it in preparation for Shenandoah.
> 
> It also includes two new interfaces in CollectedHeap to make it
> independent from G1. One is for fetching per-thread-queue from
> GCThreadLocalData, and the other to support filtering.
> 
> I am not sure if the filtering is too performance sensitive to make a
> virtual call there. If it is, we may substitute the virtual call with
> something templated. I actually have such code in Shenandoah, but it's a
> bit ugly (it requires knowledge about GCs that use it to drive code
> geneneration). An alternative might be to move the whole filtering loop
> into (e.g.) CollectedHeap, from where we know the actual type and can
> drive a templated loop. However, I tend to think virtual call might be
> ok, and thought I'd start with something simple and nice.

I’m very concerned about the possible performance impact here.
Such a change really needs to come with some performance testing.
(I’m going to run some of ours, but more would be better.)

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.

> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8154343
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8154343/webrev.00/
> 
> Testing: compiles and passes hotspot/jtreg:tier1
> 
> What do you think?
> Roman

You missed updating precompiled.hpp, which has #include “gc/g1/PtrQueue.hpp”.