RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

[Per Liden]

Hi,

On 11/28/18 3:24 PM, Roman Kennke wrote:
>>> Hi Per,
>>>
>>>> Hi Roman,
>>>>
>>>> On 11/26/18 10:39 PM, Roman Kennke wrote:
>>>> [...]
>>>>>     *) shared-serviceability
>>>>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceability/>
>>>>>
>>>>>
>>>>>        - The usual code to support another GC
>>>>
>>>> Just had a quick look at the SA part. I was thinking you'd have the same
>>>> problem as ZGC here, with regards to parsing the heap and potentially
>>>> reading garbage when you step on a Klass* which had been unloaded?
>>>
>>> Possible. I am myself not very familiar with SA. I guess it depends on
>>> how SA does it: if it iterates objects via CH::object_iterate() (e.g.
>>> same entry point as, e.g., heap-dumping code), then we should be fine.
>>> We're kicking off a traversal rather than straight scan there. If
>>> however SA somehow makes a raw scan itself, then we'd have the problem
>>> you describe.
>>
>> The SA does a raw scan itself, which is the root of the problem.
>> ObejctHeap.iterateLiveRegions() will locate the first object in a region
>> by doing
>>
>>    OopHandle handle = bottom.addOffsetToAsOopHandle(0);
>>
>> and to get the next object it does
>>
>>    handle.addOffsetToAsOopHandle(obj.getObjectSize());
>>
>> and you'll crash. So I'm afraid this will not work for Shenandoah either.
> 
> Alright. I'll 'disable' it like you did with ZGC then. Thanks for
> pointing it out.
> 
> I'm wondering: this would crash with G1 and
> +ClassUnloadingWithConcurrentMark too, then?

That's a very good point and I think you're actually right. Would be 
good if someone from the G1 camp could confirm.

cheers,
Per