Project proposal: Shenandoah

[Roman Kennke]

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