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

Per Liden per.liden at oracle.com
Wed Nov 28 11:01:39 UTC 2018


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


More information about the hotspot-gc-dev mailing list