How heap memory scan (or object graph traversal) works in garbage collector?

Question

I recently started to study garbage collectors (GCs) used in languages like Java. Among them, I am particularly interested in tracing (or mark-and-sweep) GCs like G1 (garbage-first). After reading some articles and wikis, I think I now get the high-level view.

However, I am still confused with some details in an object-graph traversal performed to mark reachable objects in the mark phase.

From my understanding, starting from roots, the G1 GC scan the heap memory of a visited object and find reference variables (stored in its region) to find other objects to visit (rather than maintaining the actual object graph at runtime and traversing it).

Regarding heap memory scan, could anyone explain how the G1 GC determines which memory location in an object stores a reference variable?

For example, given an object A, it could contain N reference variables as class members. For the object A, how does the GC know how many reference variables are there and at which offset they are stored...?

I am aware of techniques using remembered sets, card tables, etc. However, from my understanding, those are all for optimization. I am specifically curious about the way of memory scanning.

In addition, please do not say just like "the GC stores some metadata to figure out those information". I hope to hear about the actual (or detailed) implementations if possible.

Thanks all in advance, and hope you a happy new year!

Answer 1

The definition of the class of the object A specifies which fields are references. (And the object A contains, in an always predictable location -- the object header -- a reference to its class that holds that information.) That's really the whole answer.