RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks

Per Liden per.liden at oracle.com
Thu Oct 18 07:38:40 UTC 2018

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?


More information about the hotspot-gc-dev mailing list