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

Roman Kennke rkennke at redhat.com
Tue Jun 21 16:49:17 UTC 2016


Am Dienstag, den 21.06.2016, 17:16 +0200 schrieb Erik Helin:
> On 2016-04-25, Roman Kennke wrote:
> > 
> > Am Mittwoch, den 20.04.2016, 19:54 +0200 schrieb Roman Kennke:
> > > 
> > > Am Montag, den 18.04.2016, 10:50 -0700 schrieb Jon Masamitsu:
> > > > 
> > > > 
> > > > 
> > > > On 04/18/2016 04:50 AM, Roman Kennke wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > Am Freitag, den 15.04.2016, 14:30 -0700 schrieb Jon
> > > > > Masamitsu:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 4/15/2016 12:17 PM, Roman Kennke wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > I just noticed that I made the patch against the jdk9
> > > > > > > repository,
> > > > > > > instead of jdk9-dev. There was a small change to make to
> > > > > > > require_marking()/retain_entry(). The updated webrev is
> > > > > > > here:
> > > > > > > 
> > > > > > > http://cr.openjdk.java.net/~rkennke/jdk-8154343/webrev.01
> > > > > > > /
> > > > > > > 
> > > > > > > And I also forgot to post a link to the jira entry:
> > > > > > > https://bugs.openjdk.java.net/browse/JDK-8154343
> > > > > > > 
> > > > > > > Please let me know what you think, and if I can commit
> > > > > > > it.
> > > > > > > Thanks!
> > > > > > Roman,
> > > > > > 
> > > > > > You're aware of jprt?  The tool that Oracle uses to build
> > > > > > hotspot
> > > > > > patches on all platforms,
> > > > > > do a minimum amount of testing, and then does the
> > > > > > commit?  For
> > > > > > shared
> > > > > > code
> > > > > > such as in your patch, it is always used.  Sorry if I'm
> > > > > > stating
> > > > > > old
> > > > > > news
> > > > > > but I wasn't
> > > > > > sure what to make of your request to commit (yourself).
> > > > > Yes, I am aware, but wasn't sure if it's still used or if
> > > > > external
> > > > > contributors need to worry about it, because I heard
> > > > > conflicting
> > > > > stories about the possibility to commit patches ourself.
> > > > If a change is to platform specific code and not shared (I'm
> > > > thinking
> > > > Zero and Shark), then the pushes can done by the external
> > > > contributor.
> > > > Please don't quote that as definitive.   It was stated more
> > > > precisely
> > > > somewhere.  But your change is to share code so does not
> > > > qualify.
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > So how would I go about getting a sponsor for a patch like
> > > > > this?
> > > > When it's been reviewed (for anything significant by 2
> > > > reviewers,
> > > > one
> > > > of which needs to have Reviewer status as defined by the
> > > > Bylaws),
> > > > ask
> > > > for a sponsor.
> > Ping! How can we make progress with this change? If there's
> > anything I
> > can do to make it easier, please let me know.
> Hi Roman,
> 
> 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.

> This code hasn't (sadly) seen much changes
> lately, g1SATBMarkQueue.{hpp,cpp} hasn't been changed in the past six
> months and there has only been three changes to ptrQueue.{hpp,cpp}
> during the same period.

Yup. And everytime it happens, I'm pulling my hair out ;-)

The same is true (even more so) for the changes we did to pull CMBitMap
stuff into gc/shared.

> I'm a bit hesitant to move this code to gc/shared, even more when
> this
> is rather old code that is in desperate need of a rewrite.

Could you outline what you have in mind for a rewrite? I'd be happy to
help you out.

Cheers,
Roman



More information about the hotspot-gc-dev mailing list