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

Per Liden per.liden at oracle.com
Mon Dec 3 09:05:52 UTC 2018

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::objectiterate() (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

More information about the build-dev mailing list