Project proposal: Shenandoah

[Jon Masamitsu]

Roman,

We don't have a Hotspot group lead just yet.

The vote among members has been completed but
there is still some approval process that needs to be done.
I was told governing board approval or something
like that.

Jon

On 07/06/2015 03:03 AM, Roman Kennke wrote:
> 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
>>>>>>>
>>>>>>>
>>
>