RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector
rkennke at redhat.com
Wed Nov 28 14:24:00 UTC 2018
>> Hi Per,
>>> Hi Roman,
>>> On 11/26/18 10:39 PM, Roman Kennke wrote:
>>>> *) 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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev