[master] RFR: JVMTI: Don't use object header for marking

Roman Kennke rkennke at openjdk.java.net
Thu Mar 24 19:18:54 UTC 2022


On Wed, 23 Mar 2022 19:16:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> JVMTI marks objects in order to track whether or not it has already visited objects during heap walking. This uses the usual GC marking bits in the object header. However, this proves to be confusing and brittle because some GCs also uses those header bits for marking and/or indicating forwarded objects. In particular, it becomes unreliable for Shenandoah GC to distinguish JVMTI marked objects from forwarded objects.
> 
> JVMTI should have no business in marking objects in their header. This change proposes to let JVMTI use its own (temporary) marking bitmap instead. This decouples JVMTI better from GCs.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2
>  - [ ] tier3

I've reworked the change as follows:
- Added GC interface ObjectMarker and ObjectMarkerController by which JVMTI can interact with GC to do object marking.
- I provide two implementations: HeaderObjectMarker - which is 1:1 the existing implementation and BitmapObjectMarker which is the new implementation using a bitmap (still without any possible optimizations).
- Add a flag, mostly for testing, to switch implementations. Shenandoah may hardwire the flag later, or we drop the flag altogether and hardwire init_object_marker() in the CollectedHeap subclass.

This seems much cleaner than the previous implementation and also cleaner than the previous proposed change (no in-place constructor, no global state (except temporary global pointer to ObjectMarker impl), proper separation of concerns, etc).

-------------

PR: https://git.openjdk.java.net/lilliput/pull/45


More information about the lilliput-dev mailing list