Project proposal: Shenandoah

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