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

[Kim Barrett]

> On Jun 21, 2016, at 12:49 PM, Roman Kennke <rkennke at redhat.com> wrote:
>> how does moving ptrQueue.{hpp,cpp} and g1SATBMarkQueue.{hpp,cpp}
>> makes
>> merging easier for you guys? 
> 
> We made some small changes for Shenandoah in those files. Now everytime
> I'm trying to merge a change from you guys, Mercurial flags all of it
> as red, and I need to go through it line by line and figure out what
> actually changed, and incorporate it into our changed version. I know
> it should be easier, I probably did something wrong, but that's how it
> is.

To me, this sounds like something may be messed up in your repo.

Moving files around doesn't seem like something that needs to be done
at this stage in the JDK 9 release cycle.  Some of the other changes
involve substantially more process, e.g. renaming product flags is not
nearly so simple, requiring retention of the old names as deprecated
synonyms.  And there are other changes in there that want to think
about more, and would prefer were their own change sets, to be
considered separately from the file moves.

To move forward right now, an FC extension is required, per the
process described by Mark a couple of weeks ago.

Also, since this is a hotspot change, the right forest to base against
and to be pushed to is presently jdk9/hs (was jdk9/hs-rt, but that
switch occurred right around the time of the initial RFR).

FYI, I have a stack of half a dozen or so pending cleanups and
refactorings in this area, with intent for at least a couple more.
Unfortunately, they didn't finish coming together until JDK 9 FC was
looming, so I'm going to have to sit on them for a while.  It would be
a bit of a merging mess to have those files moved out from under my mq
patches, though I could cope if it were really necessary.  Note that
some of these attempt to reduce the entanglement between these classes
(esp. PtrQueue) and other parts of G1, which may have benefits for
Shenandoah too.

And no, this does not constitute the rewrite Erik suggested this area
needs. I've made a couple of forays in that direction, but have always
been tripped up by various issues, some of which are fixed in that
pending stack.  I may try again once those settle.