Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

[David Holmes]

Hi,

On 16/05/2016 10:44 PM, Erik Helin wrote:
> I'm moving this thread to hotspot-dev since this JEP affects all of
> hotspot. I guess that the members from the runtime team and compiler
> team will want to comment on the changes to the interpreter, C1 and C2.
>
> On 2016-05-13, Christine Flood wrote:
>> OK, I've put together a pdf document which summarizes our changes.

For the benefit of others:

http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160513/cde124dd/ShenandoahProposal-0001.pdf

David
-----

> Thank you for writing this up. Will you incorporate most of this
> document into the JEP?
>
>> I'm happy to go into more detail or answer questions.
>
> Reading through the document, I have a few initial high-level questions:
> - Which platforms does Shenandoah run on (CPUs/OSs)? Which platforms do
>   you intend Shenandoah to run on?
> - For the goal of the JEP, do you have any particular benchmark in mind
>   for determining when you have reached the goal? You have stated less
>   than 100 ms pauses on 100 GB, but variables such as allocation rate,
>   live set, etc. also tend to affect the GC. It might be easier to
>   determine that you have reached your goal if you have a specific setup
>   (OS, CPU, RAM) and a specific benchmark in mind.
> - When you state "most" GCs will be below 100 ms, do you have any number
>   in mind? 99% of all GCs? 99.9%?
> - Who will maintain the Shenadoah code?
>
> Reading through the JEP, I noticed the line "...as opposed to G1 which
> focuses on young generation collection to help limit remembered-set
> size." The main reason for the young collections in G1 is to improve
> throughput, not to limit the size of the remembered sets. If an
> application follows the generational hypothesis, then a young generation
> can be quite a boost to throughput. We still have a remembered set per
> young region, but it only keeps track of pointers from old regions to
> young regions (not pointers between young regions). Would you please
> remove this statement from the JEP?
>
> Thanks,
> Erik
>
>>
>> Christine
>>
>>
>> ----- Original Message -----
>>> From: "mark reinhold" <mark.reinhold at oracle.com>
>>> To: hotspot-gc-dev at openjdk.java.net, "Christine Flood" <chf at redhat.com>, "Roman Kennke" <rkennke at redhat.com>
>>> Sent: Wednesday, May 4, 2016 10:56:21 AM
>>> Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector
>>>
>>> HotSpot GC developers -- Christine recently moved this JEP [1] to the
>>> Submitted state.  Roman has made point proposals for some preparatory
>>> changes but there's been little response, so far, from anyone else on
>>> this list.  As noted in JEP 1 [2], having consensus around a proposal
>>> is an essential part of moving a JEP forward.  I'd therefore like to
>>> hear your views, not just on Roman's first proposals but on Shenandoah
>>> as a whole, especially with regard to the additional read and write
>>> barriers that would be needed and the potential for those to affect
>>> the existing collectors and also the run-time system.
>>>
>>> Christine and Roman -- I think it'd help for you to post a detailed
>>> plan of all that you'd want to change outside of Shenandoah itself, so
>>> that others can understand its potential impact.  Such a plan would be
>>> easier to evaluate than a series of point changes, and can eventually
>>> be merged into the text of the JEP for the record.
>>>
>>> - Mark
>>>
>>>
>>> [1] http://openjdk.java.net/jeps/189
>>> [2] http://openjdk.java.net/jeps/1
>>>
>
>