RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks (original) (raw)
Aleksey Shipilev shade at redhat.com
Thu Oct 18 07:24:13 UTC 2018
- Previous message: RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks
- Next message: RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks
- Next message: RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]