
Visualising the .NET Garbage Collector - matthewwarren
http://www.mattwarren.org/2016/06/20/Visualising-the-dotNET-Garbage-Collector/
======
lemming
The linked part 1 is excellent, and includes a fascinating example of how to
use the .NET GC outside of .NET itself. This seems like a really interesting
capability, the only general-purpose open source GC I was aware of was the
Boehm one. I'd expect the .NET one to have had a lot more performance tuning.

~~~
matthewwarren
Yeah it was finding that stand-alone sample that inspired me to write that
first part. It's so cool that you can easily run the full .NET GC, albeit in a
simplified environment

------
simfoo
The linked blog post about the crazy hacks needed to lessen the impact of the
gc on a server got me thinking. Is it possible to implement a non-gc language
on top of the CLR? For example could it represent RAII with an imaginary
destructor in C# reasonably well?

~~~
kaushiks
It might be, depending on exactly what you'd like to implement. There are two
things at play here:

1\. The memory that holds the resource. 2\. The resource itself.

C++ RAII lets you control the lifetime of both. In a GCd language, the GC
takes control over (1) but can't, over (2). Instead it gives you the ability
to do 2 yourself (much like C++ does using custom destructors) using
finalizers. Due to the way a GC works though, it is hard to be able to say
when (or in the context of which thread) your finalizer would run. Now, the GC
does what it does so it can guarantee that you are never able to hold a
pointer to something that some other part of your application has deemed dead.
While it is impossible to take over (1), you could imagine a world where (2),
in a GCd environment is still up to the programmer, and is exposed (say) as a
language destructor. In the presence of such a feature you run the risk of
committing errors such as (say) closing a socket twice - but it isn't much
different from say, code calling a poorly implemented Close (IDisposable) on
an object twice.

~~~
junke
You never _rely_ on finalizers to clean up resources. At best, you check that
the resource is properly released and signal an error otherwise, because you
should have released it earlier (you have a bug). That may happen when you
manually manage your resources, but most of the time, you only need to use a
resource inside a delimited block (defer, finally, unwind-protect, with X). If
I understand correctly, this is how RAII works too when you allocate objects
on the stack.

~~~
kaushiks
You're missing the point. The original question (and hence my answer) isn't
about whether or not it is a good idea to use finalizers. I'm merely pointing
out that both in the case of RAII and a GC, only the lifetime of memory
allocated is being managed. _Not_ the resource contained in it. They use
different mechanisms to let the developer deal with the resource. In the case
of RAII the time at which clean up code is executed is deterministic
(destructors), whereas with a GC, it is not (finalizers). Said mechanism, can
be implemented, should a language choose to, regardless of whether or not the
underlying memory allocation scheme is automatic (GC). (IDisposable is mostly
a made up thing that C# has syntactic sugar for, that lets developers eagerly
release resources (other than memory) when they're done with it. My point is,
neither the language nor the runtime makes any effort to enforce its usage,
like it does in the case of memory allocation.)

------
ryanlm
Is the GC open source?

~~~
niftich
Not sure if this is the same exact GC because the family tree of .NET Core is
complicated, but the CoreCLR project has a GC here:

[https://github.com/dotnet/coreclr/tree/master/src/gc](https://github.com/dotnet/coreclr/tree/master/src/gc)

~~~
matthewwarren
The post is about the Desktop GC, but AFAIK everything applies to the CoreCLR
you linked to. I don't think that much has changed (yet) with the GC on
CoreCLR.

------
spo81rty
Great post! Would you mind if I added this to our Prefix profiler? Would be a
fun little feature. In case you aren't familiar:
[http://Prefix.io](http://Prefix.io)

