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

[Roman Kennke]

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?

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
>>>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181128/63e2e3e3/signature.asc>