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

[Aleksey Shipilev]

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.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181018/d78baa26/signature.asc>