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

[Roman Kennke]

Am Dienstag, den 21.06.2016, 14:46 -0400 schrieb 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.

Yep.

> 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.

Ok.

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

I don't think it needs to go into JDK9 at this point. Would be glad to
discuss it, and when jdk10 starts rolling, go into that. Unless you
think that's not a good idea :-)

> 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).

Ok, good to know.

> 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.

Ok, so I'll probably just wait for those patches for now.

Thanks,
Roman