Why the garbage collector cannot understand when objects referencing each other are really orphaned

Question

I understand that in a managed language such as Java or C #, this is called a garbage collector, which each time checks to see if there are any instances of objects that are no longer referenced and therefore completely lost, and then cleared from memory. But if two objects do not refer to any variable in the program, but refer to each other (for example, to subscribe to events), the garbage collector will see this link and not clear the objects from memory.

Why is this? Why the garbage collector cannot understand that none of the objects can be a link to any active part of the running program and delete them.

Answer 1

Your presumption is wrong. If the GC "sees" (see below) a circular link of 2 or more objects (during the "Mark" phase), but they are not referenced by any other objects or permanent GC handles (strong links), these objects will be collected (during phase "Sweep").

A detailed look at the CLR garbage collector can be found in this MSDN article and in this blog post .

Note. In fact, the GC does not “see” these types of objects during the label phase, since they are not available and therefore are collected during the sweep.

Answer 2

Most GCs no longer work with reference counting. Usually they (and this happens in both Java and .NET) work with access from the root set of objects. The root set of objects are global and stack reference instances. Everything that is available from this set, directly or indirectly, is alive. The rest of the memory is inaccessible and therefore subject to collection.

Answer 3

I would like to add that the issues associated with subscribing to events are usually related to the fact that the subscriber and the publisher have very different life cycles.

Attach yourself, for example. to the App.Idle event in Windows Forms, and your object will be kept alive for the remaining life of the application. What for? This static application will contain the link (at least indirectly through the delegate) of the registered observer. Although you may have selected your observer, it is still attached to App.Idle. You can build many of these examples.

Answer 4

This is the main disadvantage of a traditional garbage collection reference . The garbage collector property that describes this behavior is an incomplete collector. Other collectors largely fall into the category called trash garbage collectors, which include traditional marking, semi-spatial / compacting and generating hybrids and do not suffer from these shortcomings (but encounter several others). A.

All the JVM and CLI implementations that I know use full collectors, which means that they don’t suffer from the specific problem you are asking for here. As far as I know, of those Jikes, the RVM is the only one that supplies the counting counting collector (one of its many).

Another interesting thing: solving the problem of completeness in counting references to garbage collection, and the resulting collectors demonstrate some interesting performance properties that are difficult to get out of trace collectors. Unfortunately, the most efficient garbage collection algorithms for link counting and most of the completeness modifications rely on the help of the compiler, so converting them to C ++ shared_ptr<T> difficult / does not occur. Instead, we have weak_ptr<T> and documented rules (sorry for the suboptimal link - apparently, the documentation is eluding me) to simply avoid problems. This is not the first time (another mediocre link), we have seen this approach, and we hope that the additional work to prevent memory problems is less than the amount of work needed to support code that does not use shared_ptr<T> , etc.

Middle links are due to the fact that most of my reference material is scattered across notes from the last semester memory management class.

Answer 5

The other answers here are certainly correct; .NET does garbage collection based on object reachability.

What I wanted to add: I can recommend reading Understanding the Garbage Collection in .NET (Andrew Hunter’s simple talk article) if you want more information.