RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks (original) (raw)

Aleksey Shipilev shade at redhat.com
Thu Oct 18 07:46:26 UTC 2018

On 10/18/2018 09:38 AM, Per Liden wrote:

On 10/18/2018 09:24 AM, Aleksey Shipilev wrote:

On 10/18/2018 09:13 AM, Per Liden wrote:

Tracing. Scanning would require to carry around complete marking info (to be able to avoid holes of dead objects with recycled Klass*), which we don't.

So that makes me wonder why you needed JDK-8211955 (GC abstraction for LAB reserve) and why you insert filler objects at all? Am I missing something? I think Roman meant that Shenandoah does tracing for external heap walk, e.g. for heap dumps. The internal heap walks, e.g. for evac/update-refs, are still pretty much scanning the self-parsable heap, which requires us doing fillers right. Don't you have the problem of potentially stepping on an object with a stale klass pointer in that case too?

No, we do not. Objects below TAMS would be walked using marking bitmap data, which would bypass dead objects, and object above TAMS would be walked as self-parsable heap, but those objects (and their klasses) are guaranteed to be alive.

Shenandoah does tracing for external heap walks, on the off chance external walk is requested mid-marking. There are other ways to do this, e.g. wait for marking to complete before doing external walk, which gets us back to heap parsability :)

-Aleksey

More information about the hotspot-runtime-dev mailing list