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