CFV: New Project: ZGC

[Volker Simonis]

Hi Per,

thanks for your further clarifications.

Please be assured that all the concerns I've raised so far are solely
related to the overall OpenJDK participation rules. I just want to
make sure we avoid redundancy as much as possible and work together
trustfully and with equal rights.

I always welcome technical contributions and I'm happy to support this
new project with my vote.

Best regards,
Volker



On Fri, Oct 27, 2017 at 10:12 AM, Per Liden <per.liden at oracle.com> wrote:
> Hi Volker,
>
> On 2017-10-26 17:42, Volker Simonis wrote:
> [...]
>>
>> 1. What are the benefits / advantages of ZGC over Shenandoah?
>
>
> In my proposal I outlined some of the benefits we expect to achieve through
> the current ZGC design.
>
> With respect to an evaluation of specifics of the ZGC implementation with
> other approaches, I believe that's something that makes most sense to
> discuss once the ZGC code is actually open source, and starts to move ahead
> as part of the OpenJDK Community in a Project of its own, rather than in a
> vacuum.
>
>> 2. Does it make sense to have both, ZGC and Shenandoah in the main code
>> line?
>> 2.1 If yes, why?
>> 2.2 If no, why you propose ZGC at all and not contribute to
>> Shenandoah? It's there since more than two years! That you already
>> worked on ZGC for some time as well doesn't count here because we (the
>> OpenJDK community) couldn't see that and had no chance to contribute
>> to it.
>
>
> As Roman and Andrew have already mentioned, there are multiple possible
> outcomes here (pick one, have both, merge them, etc), and only time and
> experience with both code bases will help us here. This is just a proposal
> for a new, independent ZGC project. It's not a proposal to merge ZGC into
> the JDK itself.
>
> An important part here is that we make sure that adding GCs doesn't come
> with an explosion in maintenance cost. The ongoing collaboration between
> Oracle and Red Hat on the GC and Barrier APIs is key to making sure that
> doesn't happen.
>
>> 3. Oracle has just deprecated CMS and other collectors because
>> according to Oracle it was just too expensive to maintain that many
>> collectors in parallel. Now I wonder how yet another new collector
>> fits into the picture?
>
>
> The CMS code base is complex to maintain. It's also not a collector we at
> Oracle believe is a good foundation for any future work. By deprecating CMS
> we've freed up resources at Oracle that can be invested in collectors we
> believe will serve everyone better going forward.
>
> cheers,
> Per