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
