Call for reviews: JEP 189: Shenandoah: A Low-Pause Garbage Collector

[Per Liden]

Hi Roman,

On 11/28/18 12:44 PM, Roman Kennke wrote:
> Hi Per,
> 
> I removed the sentence under Non-Goals and changed the sentence under
> success metrics to remove the heap-size part:
> 
> "This project will be a success if we can keep consistent short gc pause
> times."
> 
> Does that sound good enough?

Sure, good enough for me.

In general, I'd recommend you to under promise and over deliver when in 
comes to success metrics in the JEP. Otherwise you're just exposing 
yourself to the risk that someone claims that you haven't fulfilled the 
success metrics and that the project isn't ready to to in yet.

cheers,
Per

> 
> Roman
> 
>> Hi Roman,
>>
>> On 11/28/18 11:48 AM, Roman Kennke wrote:
>>> Hi Per,
>>>
>>>
>>>> Under "Non-Goals" the JEP says:
>>>>
>>>> "The GC pause time is bounded by the time required to scan all of the
>>>> thread stacks[...]"
>>>>
>>>> This is not quite true, is it? I'd say the theoretical worst cases pause
>>>> in Shenandoah is still bound by the live-set and heap size.
>>>>
>>>> I can think of a few scenarios:
>>>>
>>>> 1) Reference processing is still done in a pause, but the theoretical
>>>> worst case scenario for reference processing is bound by the live-set
>>>> size. For example, marking of FinalReference objects during reference
>>>> processing can in the worst case require marking the whole live-set (and
>>>> in non-worst cases a substantial part of the live-set).
>>>>
>>>> 2) Weak root cleaning (e.g. StringTable/JNIGlobalRefs) is still done in
>>>> a pause, but this has a theoretical worst case scenario of being bound
>>>> by the heap size. For example, every object on the heap is a String
>>>> which has been interned, so the time to scan/clean the StringTable will
>>>> be bound by the heap size.
>>>
>>> Ok, right. What do you suggest then? Mention those scenarios in the JEP?
>>> We don't intend to implement concurrent stringtable/weakrefs/etc
>>> processing at this point. We might do so in the future, but that is not
>>> certain either.
>>
>> I'm not sure I have a really a good answer. In the "Non-Goals" section I
>> guess you could just leave that sentence out completely. The "Success
>> Metrics" now says:
>>
>> "This project will be a success if we can keep consistent short gc pause
>> times regardless of heap size."
>>
>> And I guess that would kind of need to be adjusted too. Maybe something
>> like:
>>
>> "This project will be a success if average GC pause times are keep short."
>>
>> cheers,
>> Per
>>
>>>
>>> Roman
>>>
>>>> cheers,
>>>> Per
>>>>
>>>> On 11/27/18 11:52 AM, Roman Kennke wrote:
>>>>> Hi there,
>>>>>
>>>>> I just noticed that we have only one 'Reviewed-by:' entry in the
>>>>> Shenandoah JEP. I know that several people have reviewed it in the
>>>>> past,
>>>>> as I've incorporated several suggestions into the JEP. I believe the
>>>>> JEP
>>>>> cannot move forward to 'proposed to target' without at least one more
>>>>> added reviewer.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8046179
>>>>>
>>>>> If you have reviewed the JEP in the past, and/or feel like reviewing it
>>>>> now, please don't forget to add your 'Reviewed-by:' entry. I believe
>>>>> any
>>>>> Reviewer familiar with the relevant field of expertise (GC and/or
>>>>> Hotspot in this case) can review it and add his name to it.
>>>>>
>>>>> Thanks!
>>>>> Roman
>>>>>
>>>
>