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

Per Liden per.liden at oracle.com
Thu Oct 18 08:13:06 UTC 2018

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

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.

Ah, sounds good.

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

We initially did that in ZGC, but found that forcing the GC to be in a specific state before you can do certain operations just wasn't very attractive (more complex code, potentially stalled operations, strange error paths, etc). So, I think you made the right choice ;)

cheers, Per

More information about the hotspot-runtime-dev mailing list