JVM Garbage Collection - Tracking Young Live Objects

Question

Gathering the memory of the young generation, JVM collectors look only at the root objects (obejcts in the heap directly accessible from the root set) that belong to the young generation, and also use a write-protected table stored in memory to identify areas of the old generation that could contain objects containing references to objects in the younger generation.

The question that I have is that if a young collector determines that a particular object in the young generation has only one external link from the object in the old generation , as he knows, if the object of the old generation is not garbage and, therefore, thus, makes the object of the young generation “alive” and has no right to collect? For example, there may be a path from the root set directly associated with this object in the old generation, which, in turn, has a link to the mentioned object of the young generation. Does a young collector usually consider this object of the young generation to be alive or somehow determine whether the object of the old generation pointing to it is living / garbage before deciding to ignore / collect it?

Answer 1

how does he know that the object of the old generation is not garbage?

This is not what the main / complete collection is for. It is assumed that the object of the old generation does not die often.

When a complete collection is executed, it checks all objects, but when a small / young collection is executed, only objects in the young collection are cleared.

Answer 2

Question: "How do you get to this scenario?"

In order to create a link from the old object to the young object, the old object must be accessible, since otherwise we cannot store the link to the young object in it. To subsequently become inaccessible, we need to change at least either: the root link or another old object that previously referred to the old object in question.

As already mentioned, such records are tracked by the JVM, which is crucial, because in order to find that the old object is now referencing the young object, it must know the memory area of ​​the old object (aka map). Basically, since marking a map also means remembering incoming links, gc can now detect that the old object has become inaccessible, even without the main gc. He only needs to consider a modified map (or set of roots) to find out about it. Regardless of whether it works, it depends on environmental factors such as the selected gc algorithm, i.e. Whether you use CMS (wont) or G1 (possibly), and how "mixed collections" or actual memory pressure are configured.

Of course, if you use a parallel collector, there is a chance that a modification that will make the unreachable old object happen when the collection cycle is already ongoing. In this situation, it is possible that a young object is considered reachable during this gc cycle, even if it was not, if the modification occurred only a nanosecond earlier.