JVM garbage collection - tracing live objects in young generation

Question

While collecting the young generation memory, JVM collectors scan only those root objects (obejcts in the heap directly accessible from the root set) that belong to the young generation and also use a write barrier backed card table/remembered set to determine regions of the old generation which could possibly contain objects that contain references to objects in the young generation.

The question that I have is that if the young collector determines that a particular object in the young generation only has a single external reference from an object in the old generation, how does it know if the old generation object itself is not garbage and thus making the young generation object 'live' and not eligible for collection? For example, there could be a path from the root set directly to this object in the old generation that in turn has a reference to the said young generation object. Does the young collector typically consider this young generation object as live or does it some how determine whether the old generation object pointing to it is live/garbage before deciding to ignore/collect it?

Answer 1

how does it know if the old generation object itself is not garbage?

It doesn't that is what a major/full collection is for. The assumption is that old gen object doesn't die often.

When a full collection is performed it checks all the objects, but when a minor/young collection is performed only the objects in the young collection are cleaned up.

Answer 2

The question is “how to you get to such a scenario?”

To create a reference from an old object to a young object, the old object must be reachable, as otherwise we can’t store a reference to the young object in it. In order to become unreachable afterwards, we have to modify at least either, a root reference or another old object that previously referenced the old object in question.

As you already mentioned, these kind of writes are tracked by the JVM, which is crucial, as in order to detect that an old object now references a young object, it must know that the memory area of the old object (aka card) has been modified. In principle, since card marking also implies remembering the incoming references, the gc is now capable of detecting that the old object became unreachable, even without a major gc. It only has to consider the modified card (or the root set) to learn about it. Whether it does, depends on environmental factors, like the chosen gc algorithm, i.e. whether you use CMS (won’t) or G1 (might), and how “mixed collections” are configured or the actual memory pressure.

Of course, if you use a concurrent collector, there is the possibility that the modification that will make the old object unreachable happens while a collection cycle is already ongoing. In this situation, it is possible that the young object is considered reachable during this gc cycle, even if it wasn’t if the modification happened just a nanosecond earlier.