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

Per Liden per.liden at oracle.com
Wed Nov 28 14:21:51 UTC 2018


On 11/28/18 3:00 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.

cheers,
Per

> 
> Roman
> 
> 


More information about the hotspot-gc-dev mailing list