Project proposal: Shenandoah

[Roman Kennke]

Looks like the CC to John Coomes bounced. Is he still Hotspot group
lead?

Roman

Am Dienstag, den 24.03.2015, 22:45 +0100 schrieb Roman Kennke:
> Hi Jon and all,
> 
> According to http://openjdk.java.net/projects/#new-project we need a
> Hotspot group lead to declare to sponsor the project:
> 
> "At least one Group Lead must declare that their Group is a sponsor of
> the proposed Project."
> 
> John Coomes (in CC) is the only Hotspot lead, as far as I can see. John,
> do you think the Hotspot group could sponsor the Shenandoah project?
> 
> I don't see any other group that would make sense as sponsor. I'd like
> to put this up for voting as soon as I've got the ok from John Coomes.
> 
> Thanks,
> Roman
> 
> Am Samstag, den 28.02.2015, 12:28 -0800 schrieb Jon Masamitsu:
> > Roman,
> > 
> > Thank you for the further information.   This large a contribution
> > is new territory for us so we'll be taking a bit of time to mull it
> > over.
> > 
> > Jon
> > 
> > On 2/28/2015 5:01 AM, Roman Kennke wrote:
> > > Hi Jon,
> > >
> > >>> Shenandoah is developed and maintained by Red Hat, yes, but the
> > >>> intention is, and has always been, to integrate it into upstream
> > >>> Hotspot, if OpenJDK people think it's feasible. The first step in this
> > >>> direction is the creation of a Shenandoah project (this proposal) and we
> > >>> also want to move forward with the Shenandoah JEP 189.
> > >> I would also like to understand how an integration of Shenandoah into
> > >> Hotspot would affect my day-to-day work.   For example if I build Hotspot
> > >> will I skip the build of Shenandoah sources by default?
> > > Build-wise Shenandoah is a GC like all other GCs. When you build
> > > Hotspot, you build Shenandoah. It will be excluded by setting
> > > INCLUDE_ALL_GCS to false, iirc. We could add a build flag to exclude
> > > Shenandoah, but I don't really see the point of it.
> > >
> > > Shenandoah is a bit special because it requires read and write barriers
> > > in the interpreter, C1, C2 and the runtime. We tried as much as possible
> > > to make this a clean interface, such to avoid scattering Shenandoah code
> > > all over the place. One of our goals is to not impact performance or
> > > behaviour with any other GC. If any other GC in the future requires
> > > similar barriers, it could just implement those interfaces. It is not
> > > perfect yet and needs some cleanup.
> > >
> > > All that being said, the intention of this project proposal is not
> > > directly to integrate Shenandoah into upstream Hotspot yet (that's the
> > > purpose of the JEP, ultimately), but to provide a development space for
> > > Shenandoah under the OpenJDK umbrella, where it belongs, where OpenJDK
> > > people can easily try it out, etc.
> > >
> > > BTW, according to http://openjdk.java.net/projects/#new-project we need
> > > a Hotspot group lead to declare to sponsor the project:
> > >
> > > "At least one Group Lead must declare that their Group is a sponsor of
> > > the proposed Project."
> > >
> > > Best regards,
> > > Roman
> > >
> > >
> > >> Jon
> > >>
> > >>> Best regards,
> > >>> Roman
> > >>>
> > >>>> My impression of Shenandoah was that it would be a project
> > >>>> developed and maintained by Redhat and (I don't recall where
> > >>>> this last part of my recollection comes from) that it would be kept
> > >>>> separate from the OpenJDK hotspot sources.    Is that all
> > >>>> correct?
> > >>>>
> > >>>> Jon
> > >>>>
> > >>>> On 2/19/2015 10:42 AM, Roman Kennke wrote:
> > >>>>> I'd like to discuss the creation of the project Shenandoah with myself
> > >>>>> *and/or* Christine Flood as initial lead and the Hotspot group as
> > >>>>> sponsoring group.
> > >>>>>
> > >>>>> It's aim is to implement a new garbage collector that reduces GC pause
> > >>>>> times for applications that require really large heaps. Existing GCs
> > >>>>> show pause times of several 100ms up to several seconds on heaps >
> > >>>>> 100GB. That is because they need to stop all Java threads for compacting
> > >>>>> the heap. Shenandoah implements a new algorithm that allows to compact
> > >>>>> heap while only stopping the Java threads briefly for root scanning, and
> > >>>>> then evacuates the heap concurrently. This makes pause times unrelated
> > >>>>> to the heap size and only proportional to the root set size.
> > >>>>>
> > >>>>> Shenandoah has so far been developed as part of the IcedTea project:
> > >>>>>
> > >>>>> http://icedtea.classpath.org/wiki/Shenandoah
> > >>>>>
> > >>>>> It has usable implementations for OpenJDK9 and OpenJDK8.
> > >>>>>
> > >>>>> Roman Kennke (me) is Principle Software Engineer at Red Hat, working on
> > >>>>> Shenandoah since two years now. Before this, he worked on Thermostat,
> > >>>>> and contributed to OpenJDK in several areas, most importantly the Zero
> > >>>>> and Shark ports, graphics, and ports to embedded platforms.
> > >>>>>
> > >>>>> Christine H. Flood is a prinicpal software engineer at Red Hat.  Most
> > >>>>> recently she's been working on Shenandoah, before that she worked at
> > >>>>> Oracle/Sun labs on the  Fortress programming language,  and on JVM
> > >>>>> Scalability. She's one of the inventors of both the parallel GC
> > >>>>> algorithm and G1.
> > >>>>>
> > >>>>> Initial committers and reviewers would be me and Christine.
> > >>>>>
> > >>>>> Could we both be project leads? Christine doesn't have an OpenJDK
> > >>>>> idendity yet...
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Roman
> > >>>>>
> > >>>>>
> > >>
> > >
> > 
> > 
> 
> 
>