0

I'm wondering why weak references are not built-in types which are treated similar to standard object references by the garbage collection. In C#, you must either use the WeakReference class (which has a significant performance and memory impact as it is created on the managed heap itself and uses a finalizer for cleanup) or manually allocate a GCHandle (which later has to be freed manually again).

In principle, I would implement the GC for weak references in the following way:

  1. To identify the live objects, the GC has to walk the object tree starting from all roots. If it finds a reference to an object, the object is marked as reachable. In contrast, if it finds a weak reference to an object, this would be ignored in the first step.

  2. In the second step, the GC looks where the unreachable memory blocks are located and compacts the managed heap (or at least parts of it). When it does this, it has to walk the object tree again and update all references (normal and weak) to objects which have been moved. Additionally, if it finds a weak reference to an object not marked as reachable, it has to be set to null (or some other well defined invalid memory location) to mark it as invalid.

LionAM
  • 1,271
  • 10
  • 28
  • You should be asking the designers of the language why they made that decision. SO didn't design C#, so we can only guess at what they were thinking. (Waits for an Eric Lippert reply to this post.) – Servy Sep 07 '12 at 20:57
  • @Servy So it's unlikely that'll get an answer from him here since 1) Eric works on C#, not the CLR 2) He's been inactive for a few months. – CodesInChaos Sep 07 '12 at 21:06
  • @CodesInChaos 2) Yes, I know, but one can always hope. 1) that's true, but there's still a good chance he'd be able to speak about why someone else made the decision, since it's likely someone he works closely with, even if it's not a decision he would be personally involved in. – Servy Sep 08 '12 at 04:30
  • A somewhat more interesting question would be whether there are any problems with having weak references included as part of a runtime rather than a library. Personally, I would like to see in addition to weak references (which would become `null` if the target existed) a "telescoping" reference type which, if it identified an object descended from `TelescopingObject` [which in turn had a private field `KnownEquivalent`] would on each GC cycle replace all references to that object with references to the object identified by its `KnownEquivalent`. This could be useful with immutable types... – supercat Jun 21 '15 at 20:30
  • ...if there were a method `MergeEquivalents` which, when passed references to two objects of the class which invokes it, would select one of the objects to be retained, and cause all references to the other to become references to the one that's retained. It's *almost* possible to efficiently do that without GC support, but solutions which are efficient in the common case will have memory leaks given worst-case sequences of object creation, comparison, and abandonment. Integrated GC support could avoid that problem. – supercat Jun 21 '15 at 20:36

2 Answers2

2

Probably because they tend to be needed insufficiently often to merit a more prominent representation.

Thom Smith
  • 13,916
  • 6
  • 45
  • 91
  • 1
    I was especially thinking about weak events - which should be much more prominent as the normal events can lead to an "managed memory leak" which I suffered recently. – LionAM Sep 09 '12 at 09:11
0

The garbage collector already does a very good job with regular reference, even in the presence of cyclic reference. (In a reference counted world it is a very different story). You can have cyclic reference between your object and in most case it will be correctly cleaned up. That mean it is very rare you need a WeakRef, and so it probably didn't warrant being built-in the CLI.

Laurent Bourgault-Roy
  • 2,774
  • 1
  • 30
  • 36
  • Weak references and weak delegates are needed in many situations where an object is holds a reference to another object *for the sole purpose of doing things on behalf of other entities that also hold a reference to it*. That's actually a very common pattern; more often than not, both objects will have similar lifetimes, but that's a dangerous thing to rely upon. – supercat Oct 30 '12 at 03:13