File size

File size

File size

File size

File size

719.7 MB

Patrick Dussud is a Technical Fellow at Microsoft who is the author of .NET's garbage collector (GC) - the automatic memory management
infrastructure that makes up most of what is managed in managed code execution. How does GC, work, generally? Why is it important? The GC inside of the CLR is of a specfic type - ephemeral, concurrent (the server version has always been concuurent and now
with Background GC on the client in CLR 4, GC is concurrent on the client as well, but there are differences...).

Patrick takes us through the basics of GC up to the current state of the art in this outstanding conversation with one of the fathers of .NET. Of course, given the other expert in the room - programming language designer Erik Meijer, we have to talk about the
impact that dynamic and functional languages have on the design of general purpose GCs as well as future directions of the CLR's GC, generally. What's Patrick working on these days?

Patrick will be presenting at PDC09 in the the
Technical Leaders track. His talk,
Future of GC, should not be missed. This conversation is a great introduction to what Patrick will be talking about and we highly recommend you watch this before you attend his session (or watch his session after the show shortly after the PDC ends - like
last year, all sessions will be available on-demand...).

I have a question I wish I could've asked for this interview: How is the write-barrier implemented in the CLR?

Patrick explains in the video about the generational aspect of the CLR's collector, but generational collectors require a thing called a write-barrier. This is because you can get away with only scanning gen0 when all the objects in gen0 are only referenced
either by roots (references in stack frames or globals) or other gen0 objects. But the problem is that you can create a new object and assign a reference to it to an older object that might be in gen1 or gen2. The write-barrier therefore has to intercept modifications
to objects in older generations and store any references to objects in gen0 in another area so they can be used as additional roots in the next gen0 collection.

There are two ways to implement a write-barrier (that I know of anyway). One is to have the compiler (or JIT) generate extra code that checks all writes to reference fields and if they lie outside the range assigned to gen0, to jump into a routing that stores
away the reference. The other is to ask the OS to trap writes the memory area allocated to older generations of the heap and have the exception handler deal with it. Both methods have significant pros and cons. I'd love more information on exactly how this
is implemented in the CLR.

There was some discussion about the extra pressure that functional programming places on the garbage collector. Jane Street Capital is a company that uses functional programming extensively (if you google many terms related to functional programming you
are likely to see one of their adverts) using the Objective Caml language. They have stated (though I haven't seen detailed testing evidence) that while F# is interesting due to it's similarity to OCaml and interoperability with the .NET ecosystem, it's not
performant enough for production use, at least in the way they use OCaml, because the .NET garbage collector isn't tuned to the needs of functional programming.

Also there was some discussion of ignoring the stack and allocating everything on the heap. There have been a couple of attempts at doing this for conventional languages. The most well-known is Stackless Python. That is motivated by the issue that stacks
are a huge burden in systems with many many threads. The idea with Stackless Python is to allow you to have thousands of threads and having the OS allocate a separate 1Mb stack for each wouldn't be practical. In this system all stack frames are allocated on
a heap and garbage collected when the functions have returned. It is significantly slower, but if you want to write a system (like a simulation) where you have thousands of objects, each executing within their own thread, it's a solution. The most famous user
of Stackless Python is the MMO game Eve Online - all the entites within the game world are running in their own threads of control in one giant process.

Also, and more relevant to .NET, Mono (the open source re-implemetation of .NET) has added a feature called Tasklets which bring the same thing to .NET world, at least as far as I understand it.

Well, it's actually a pretty high-level question - just one that you'd only ask if you'd spent a lot of time reading about garbage collection.

FWIW, the code (at least as far as v2 of the CLR is concerned) is most likely in the Rotor source. It's just that being production-ready code rather than an accademic exercise, it's pretty hard to find what you want from it.

Why is it so hard to find? Just search the Rotor source for "WriteBarrier". The JIT inserts calls to some helper functions named something like JIT_WriteBarrier. These functions can be found in a file named jithelp.asm.

And for the record: .NET does the same thing. You can see those helper calls with a native debugger.

Suppose that you could have generational GC exactly like .NET has now, but the execution of write barrier related code was free. How much faster would programs run? I know that this question is highly program dependent, but maybe you can give an order of
magnitude guess.

I find it quite intriguing that there is a connection between the CLR and SQL Server because they are both runtimes that execute a language (MSIL and T-SQL). And the connection between functional vs imperative style programming and updates. Hm, looking forward
to hearing more thoughts on this.

On a loosely related subject, It would be interesting to know why SQL Server is still being shipped with two VMs - .NET one and a specialized one to run T-SQL code. Is .NET VM too generic (insufficently specialized) to provide good run-time for T-SQL?

Is it the same or similar reason why guys from Jane Street Capital hint at .NET GC not being quite good enough to meet demands placed on run-time by a functional programming language (F#)?

It looks logical to assume that any engineering solution (software or otherwise) has its range of applicability. Going below or above the applicable range requires some other engineering solutions. Is there any info out there on applicability limits of .NET
GC and .NET VM for that matter (and how one would express those limits anyways - in terms of lattency or memory allocations per unit of measure, when being general purpose VM starts and ends?).

Why is this video so noisy and of such poor quality, even in WMV HD (1,072,801,969 bytes worth). I mean for over a gig of WMV3+audio data, I was expecting the view quality to be superb. Instead there is so much video noise, that it looks like someone compressed
it with the worst video encoder settings available, while still maintaining a very large file size. Is the camera at fault? Other videos presented on channel 9 by the same videographer were decent, what happened here? Did the "good camera" break? Was the "video
engineer" on vacation and this video got re-encoded by a programmer? What gives?

This was a very important interview video with a very important person and I wish more effort was put into a quality presentation.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.