Project proposal: Shenandoah
Roman Kennke
roman at kennke.org
Mon Jul 6 10:03:24 UTC 2015
Hi all,
What is the status of this Shenandoah project proposal? Has the Hotspot
group leadership issue been resolved? We still need a Hotspot group lead
to announce support for project creation...
Kind regards,
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
> >>>>>
> >>>>>
> >>
> >
>
>
More information about the discuss
mailing list