Friday, 6 January 2017
Why no Reference Counting + Garbage Collection in C#?
Answer
Answer
I come from a C++ background and I've been working with C# for about a year. Like many others I'm flummoxed as to why deterministic resource management is not built-in to the language. Instead of deterministic destructors we have the dispose pattern. People start to wonder whether spreading the IDisposable cancer through their code is worth the effort.
In my C++-biased brain it seems like using reference-counted smart pointers with deterministic destructors is a major step up from a garbage collector that requires you to implement IDisposable and call dispose to clean up your non-memory resources. Admittedly, I'm not very smart... so I'm asking this purely from a desire to better understand why things are the way they are.
What if C# were modified such that:
Objects are reference counted. When an object's reference count goes to zero, a resource cleanup method is called deterministically on the object, then the object is marked for garbage collection. Garbage collection occurs at some non-deterministic time in the future at which point memory is reclaimed. In this scenario you don't have to implement IDisposable or remember to call Dispose. You just implement the resource cleanup function if you have non-memory resources to release.
- Why is that a bad idea?
- Would that defeat the purpose of the garbage collector?
- Would it be feasible to implement such a thing?
EDIT:
From the comments so far, this is a bad idea because
- GC is faster without reference counting
- problem of dealing with cycles in the object graph
I think number one is valid, but number two is easy to deal with using weak references.
So does the speed optimization outweigh the cons that you:
- may not free a non-memory resource in a timely manner
- might free a non-memory resource too soon
If your resource cleanup mechanism is deterministic and built-in to the language you can eliminate those possibilities.
Answer
Brad Abrams posted an e-mail from Brian Harry written during development of the .Net framework. It details many of the reasons reference counting was not used, even when one of the early priorities was to keep semantic equivalence with VB6, which uses reference counting. It looks into possibilities such as having some types ref counted and not others (IRefCounted!), or having specific instances ref counted, and why none of these solutions were deemed acceptable.
Because [the issue of resource
management and deterministic
finalization] is such a
sensitive topic I am going to try to
be as precise and complete in my
explanation as I can. I apologize for
the length of the mail. The first 90%
of this mail is trying to convince you
that the problem really is hard. In
that last part, I'll talk about things
we are trying to do but you need the
first part to understand why we are
looking at these options.
...
We initially started with the
assumption that the solution would
take the form of automatic ref
counting (so the programmer couldn't
forget) plus some other stuff to
detect and handle cycles
automatically. ...we ultimately concluded that
this was not going to work in the
general case.
...
In summary:
- We feel that it is very important to solve the cycle problem
without forcing programmers to
understand, track down and design
around these complex data structure
problems.
- We want to make sure we have a high performance (both speed and
working set) system and our analysis
shows that using reference counting
for every single object in the system
will not allow us to achieve this
goal.
- For a variety of reasons, including composition and casting
issues, there is no simple transparent
solution to having just those objects
that need it be ref counted.
- We chose not to select a solution that provides deterministic
finalization for a single
language/context because it inhibits
interop with other languages and
causes bifurcation of class libraries
by creating language specific
versions.
No comments:
Post a Comment