Jason Zander - Discussing the architecture and secrets of .NET and the CLR

Posted By: The Channel 9 Team | Nov 23rd, 2004 @ 10:22 AM | 42,054 Views | 7 Comments
"Show us the architecture of .NET on the whiteboard," is what we asked Jason Zander and that started out an interesting discussion of what .NET is.

That led into a discussion of .NET's garbage collector and determinalistic finalization that developers will find interesting (Charles Torre, developer on Channel 9, was asking the questions). It ends up with a discussion of "secrets of the CLR."

This is the final piece of our tour of the CLR team. Thanks Jason and to your team for giving us an interesting inside look at .NET.

The other segments of the tour/interview are here:

CLR Tour, Part 1
CLR Tour, Part 2
CLR Tour, Part 3
About the CLR
Media Downloads:
Rating:
1
0
#Nov 23rd, 2004 @ 11:43 AM
JasonZ
JasonZ
Beer28 wrote:
I know this sounds silly and simple, but why can't you guys just do a flat out reference count on allocated memory handles in the JIT compilation process?

This is the classic ref counting vs tracing debate.  Brian Harry's explanation of the trade offs is still the best explanation of this.  Highly recommended reading.
#Nov 23rd, 2004 @ 12:14 PM
JasonZ
JasonZ
Beer28 wrote:

thank you very much. I honestly read about half of it. Though all of this complexity over easy memory management makes me just want to use new and delete.

Good idea, tracking down bit hoses from dangling pointers and double deletes is far surperior <g>

Seriously, no memory allocation system is going to be a silver bullet.  I do believe that automatic memory handling in general has been a huge win, and I wouldn't change the decisions we made on the product.

btw, the Dispose pattern and using keyword were created as a result of the dicussion Brian's aticle generated.
#Nov 23rd, 2004 @ 1:01 PM
rhm
rhm
I was going to mention the Dispose pattern - this is really under-emphasised in the .NET 1 documentation IMO.  When people talking about deterministic memory management in C++ they are usually talking about deterministic cleanup of the object's internal state - they do a bunch of stuff in the destructor to delete any objects they own among other things. A lot of people come to .NET (and did to Java as well) thinking that finalizers are the equivalent of the C++ destructor and then complaining that they have no control of the calling of the finalizer or even a guarantee that it will ever be called.

If instead you think of Dispose() being the equivalent of the destructor and do all your cleanup there, you call Dispose() on the object instead of using the delete statement, you have almost the same situation you have in C++ - the only difference being that the actual memory isn't freed immediately and I believe there are very few situations were that matters much.

Personally I find the using statement in C# to be rather ugly. I am rather impressed by the way the new C++/CLI implements the Dispose pattern to make your code look like trational C++ with automatic/stack allocation. Jason says in the video that the compiler generates a lot of code to do that but I think that's irrelevant becuase if you wanted the lifetime of the object to be controlled you would have to write that code yourself anyway.
#Nov 24th, 2004 @ 6:27 AM
andyandy
andyandy
Chris Sells(www.sellsbrothers.com) got a grant from MSR to study about doing refcounting in .NET, using SSCLI/Rotor. Read his/their findings here: http://www.sellsbrothers.com/tools/RotorRefCounting.doc

More interesting is their conclusions, which can be found here: http://www.sellsbrothers.com/writing/refcount_rotor.doc.

Seems like performance is the major problem refcounting introduces.
#Nov 24th, 2004 @ 4:00 PM
dotnetjunkie
dotnetjunkie

Lookout is indeed an amazing app!!!

Do you have plans to integrate the functionality of it in the next version of Outlook?  That would be fantastic.

#Nov 26th, 2004 @ 10:27 PM
John Melville-- MD
John Melville-- MD
Equality Through Technology

Personally I find the using statement in C# to be rather ugly. I am rather impressed by the way the new C++/CLI implements the Dispose pattern to make your code look like trational C++ with automatic/stack allocation. Jason says in the video that the compiler generates a lot of code to do that but I think that's irrelevant becuase if you wanted the lifetime of the object to be controlled you would have to write that code yourself anyway.


I couldn't disagree more.  Under C++ most destructors were just calling other destructors anyway, and all that's gone with automatic memory management.  Thus classes that hold scarce resources and actually need to be disposed ought to be, and in my experience are, somewhat rare.  I don't mind having syntax to remind me that this class holds a scarce resource.

IU hope the C++/CLI team is smart enough to only provide deterministic finalization of ojects that implement IDisposable, otherwise theyu are generating a look of code for no benefit.

#Nov 27th, 2004 @ 4:04 AM
rhm
rhm
Hmm, you sound like you missed the point of IDispose.

If you have a class that needs to free resources, implement IDispose and free those resources there, calling other object's Dispose() methods if necessary. In C++/CLI, the delete statement calls Dispose on managed objects if they implement IDispose. Additionally it calls it when managed objects allocated automatically go out of scope.

Forget about finalizers - they always were and even more so now are just a last resort. They can free resources for objects were lazy client code forgot to call Dispose() by calling Dispose() themselves, or you could add code to your debug build so that if the finalizer gets called for a class that implements IDispose, it logs an error. Then you can trace what would be memory leaks in the equivalent native C++ code.
Microsoft Communities