Project proposal: Shenandoah

[Vladimir Kozlov]

As Hotspot Group lead I declare that Hotspot group will sponsor 
Shenandoah project with Christine H. Flood as Project Lead.

Best regards,
Vladimir

On 7/8/15 9:41 AM, Jon Masamitsu wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>
>>
>