I recently started to study garbage collectors (GCs) used in languages like Java.
I am particularly interested in tracing (or mark-and-sweep) GCs like G1 (garbage-first).
I am 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, how does the G1 GC determine 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.
From my understanding, those are all for optimization.
I am specifically curious about memory scanning.
Please do not just say "the GC stores some metadata to figure out those information".
I hope to hear about the actual (or detailed) implementations.
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.