Patrick Dussud: Garbage Collection - Past, Present and Future

That was great, thanks guys.

They wrote J Script in the time-span of several weekends? And he wrote that in Lisp and then rolled a C translator from scratch?

There is a reason why I could not work at Redmond and that just about summarizes it.

JohnnyAwesome wrote:

They wrote J Script in the time-span of several weekends? And he wrote that in Lisp and then rolled a C translator from scratch?

There is a reason why I could not work at Redmond and that just about summarizes it.

His mentioning that part of his Lisp background is from working on the TI Explorer (TI's lisp machine workstation) at Texas Instruments brings back some memories. My university had a couple of those TI Explorer lisp machines. I never got to do any real work on them, but I loved playing with them. They seemed to be a lot more polished than the Symbolics lisp machines we had.

JohnnyAwesome wrote:

They wrote J Script in the time-span of several weekends? And he wrote that in Lisp and then rolled a C translator from scratch?

There is a reason why I could not work at Redmond and that just about summarizes it.

It's not that difficult, especially if you've done it before, like most people would have in any decent computer science graduate program.

JChung2006 wrote:



JohnnyAwesome wrote: They wrote J Script in the time-span of several weekends? And he wrote that in Lisp and then rolled a C translator from scratch? There is a reason why I could not work at Redmond and that just about summarizes it.

It's not that difficult, especially if you've done it before, like most people would have in any decent computer science graduate program.

Bearing in mind that Computer Science graduate programs didn't exist fifteen years ago, and were a one-year extention of a maths or engineering course.

And now I feel old.

Anyway, GC is one of the problems that I've worked on quite a bit, and they really are facinating. Dussud's right tho. A bad GC makes everything horrible, and a good GC can hide a multitude of sins in a badly written application.

Congrads to Dussud on the CLR GC, it's certainly one of the most impressive out there and is a significant reason as to why managed code doesn't experience the loss of power that most people expected it to.

It's probably not an overstatement to say that his work is contributory to the MSR Singularity's surprisingly good CPU performance review earlier this year, despite expectations that it would be catastrophically bad. Managed code is great because we have guys like Patrick on board.

Downloading it...

Really gettin9 the feel that its gonna be superb...
Thanx Charles...

Can't wait..

littleguru wrote:


Yeah. It's ok. Could you point me to the blog that is mentioned when he talks about the woman that's developing the GC? Thanks!

Maoni Stephens
http://blogs.msdn.com/maoni/

Excellent video Charles - many thanks for helping to make this happen. On the runtimes front is there any chance that the likes of Chris Brumme might get back on the camera soon? And getting back to languages, might we get Ander's and Co. talking about Spec# and C# future?

Something like "Anders on the broad future directions of C#"  would be great.

wow charles ...
i has hoping that we can meet anders every day in & out .....
but as u said at the end of the August or early September ...I m eagerly awaiting it...
go on & hav a great video for us from a great man....

Charles wrote:



dot_tom wrote: Excellent video Charles - many thanks for helping to make this happen. On the runtimes front is there any chance that the likes of Chris Brumme might get back on the camera soon? And getting back to languages, might we get Ander's and Co. talking about Spec# and C# future?

Thanks, dot_tom. 

Chris Brumme no longer works on the CLR team (in fact, he hasn't for well over a year...). I really want to interview him on what he's currently working on, but since it's secret, well, you understand...

You will see Anders on 9 again at the end of August, early Sept. Will be a most interesting interview.....

C 

Thanks Charles and Patrick - good info.  I would like to see Sql and CLR teams (and Anders as the glue) talk about bringing the two type systems even closer.  I notice katmai has some new datetime types that seem to be common with the new clr datetime type, but would like to see complete compat across all clr types so I don't have to think about it.  I think the great Jim Gray was working on something like this.  Things like LINQ still need to use a combination of types to bridge the gap, which is a bit hard to reason about imho.  The Exchange 12 interview on info Patrick pointed out would be great.  

Thanks again  

Thanks, Patrick, Charles, for the great discussion. If Patrick is going to answer any questions in the future, I would be interested in how the CLR and GC will change to work in a world of hundreds of CPU cores, which is not so far away.

The original idea of object oriented programming, as expressed by Kay, was that each object was a computer in miniature. I am interested in how .net will evolve to reduce visible shared state between objects so that concurrent programming can really take off.

Great talk. Never really thought of gc as improving performance, always thought of it as a good thing at a price. While I haven't done extensive testing of it, it rings true, that for non-trivial programs trying to keep track of all the references to an object, or worse trying to "get a copy, rather than point to the original", would be hard, and in general poorly done. Having something that overlooks all of the systems memory seems like it would have a better grasp of what needs to be done. That is why we get Microsoft to hire smart people to figure out good ways of doing things and leave it at that

Also, I've seen spots in the MSDN documentation where it recommends pre-allocating a bunch of objects (ex. the collection documentation) to improve performance. I can see where stuff like that would mess up the garbage collector, now unless I'm adding things to the collection in a simple loop, I think I'll  dynamically resize using the .add or .addrange methods. I know the C++ STL had issues with that because it would use its  copy constructor to move all the old stuff over to  a new object one element bigger, it sounds like  the .Net framework handles it smarter than that.

For a concurrent gc could you create a set of trees of allocations, essentially each potential scope in the source would have at least a leaf in the tree set, as things get allocated in the scope it adds leaves to the tree (sort of like how Sun's ZFS does its "instanteous snapshots" I think), then when it comes time to do gc you find out which scope your in, and every sub tree on a lower node in the set can be safely pruned. Presumably an app isn't just spinning around doing allocations, it actually is adding data to the objects, running through logic etc, so at the cost of adding a step in the allocation process you gain scope level knowledge of the allocations in the app.

You could then whenever the gc gets the CPU (or on a spare one ) mark the node where everything lower than it is dead, and start deleting it. If you get interrupted it would be fine because when you get the CPU back you still know everything below that is dead and can continue. I think in such a scheme the only time you'd have to block execution of the app would be if when the gc gets the CPU back, the app has gone back into something it thinks is dead. Then it would have to force the completion of gc on that part of the tree, before it allows the app to go back into that scope.

Perhaps that is how the gc works now, I'd love there to be another video that goes into the nitty gritties of the gc process.

Hi Patrick,

first let me congratulate for the great job you've done. It's hard to believe that a GC can make apps run faster, but you make this true.

However, there are a number of facts which suggest that Microsoft's overall approach on the subject may be incomplete:

 - in the interview, in reply to a suggestion that the developer could declare the lifetime of an instance, you reply that "if" the developer then starts sharing this instance, this may result in a crash. Are you suggesting that the developer who is clever enough to figure that his app could be tuned that way is not clever enough to carefully handle the issues ?

 - you indicate that instances over 80k are allocated separately, which results in an optimisation since it avoids copying the instance when gc compacts the heaps. What if my app instantiates say 100,000 objects of 79k each ? Why am I missing this optimization then ? Why can't the developer parameterize gc and set ( inside a given range ) the maximum size of objects instantiated in the regular heap ?

 - you confirm that all instances lower in size than 80k are first allocated in the gen 0 heap. Then if the instance survives a gc, it is copied to the gen 1 heap. And later it may be copied to the gen 2 heap, where the long lasting instances live. Don't you think this harms performance in a way which could sometimes be easily improved by the developer ? After all, the developer knows the lifetime of some instances ( not all of them ), so why not let him help gc when he knows that the instance is a long-lasting one and should therefore be allocated immediately in the gen 2 heap ?

 - you reckon that it has taken many years to fully understand the behaviour of all sorts of apps regarding memory, and that at the beginning, gc would dramatically impact performance on servers. You also reckon that the increasing amount of RAM on x64 machines makes it more and more difficult to avoid latencies. Do you really believe that all behaviours can be detected ? Can they even be modelized ? In my belief, many apps have a stochastic behaviour, even at the millisecond level ? Obviously, the adapative policy is good enough to face say 99% of the behaviours for 99% of the needs. Let's even imagine you could detect 99.99% of these behaviours and satisfy 99.99% of the needs. There would still remain 0.01% situations where only the developer himself could be helpful so why deny him the ability to help the gc ?

 - in the interview, you say "developers" shouldn't use gc.collect since this fools gc's behaviour when determining the best policy, but in reply to the question "then why is this API public ?" you say that there are situations where it IS necessary. Isn't this the admission that automatic GC will never be the perfect answer to all situations ?

 - you provide a thorough (and helpful) explanation of the problems you need to solve in order to neatly cleanup instances before they are deallocated. Also, there is currently a lot of litterature around finalizers and the IDisposable interface ? Doesn't this "activity" show a misconception from the beginning ? IMHO, the entire subject is polluted by the heritage of the C++ behaviour of destructors. We're speaking of 2 very different needs here: one is to cleanup objects which hold system resources, and this should be done ASAP, the other is to release memory, which should only be done when memory is needed, or when CPU is available. I think the first need is completely missed with the GC approach, and can anly be satisfied with refcounting. I know that handling refcounting can quickly become a nightmare when instances hold circular references, all c++ developers have had to deal with this when using smart pointers, and I trust you when you say that InterlockedIncrement(&refcount) is much slower than refcount++. However, isn't this slowness insignificant when dealing with objects like database connections or file handles which are precisely the ones for which we NEED an automatic cleanup as soon as they get out of scope ( and not when memory is needed ) ? Also, like -as you observe- most instances actually never survive gen 0 gc, most instances also are only referenced in the stack, which means their refcount would reach 0 as soon as the thread returns from the method where they've been allocated. Do you think that just because this is not always the case is a sufficient reason to not take advantage of the fact ?

 - after all, why should ALL instances follow the same lifetime paradigm ? Why couldn't a particular class or instance be refcounted, and other ones gc'ed ? 

 - in the end, it seems to me that Microsoft is missing the following points:
 - not all .Net developers are dummies when it comes to memory management. The reason for some of us to use C# is not the ease of use, but the fact that it dramatically shortens development time for 99% of the needs, by providing a full-fledged framework and an acceptable (that means good) gc. However, there are areas in an app where good is just nod good enough. Not letting developers manage memory by themselves in these areas because it is inherently unsafe is in total contradiction with the fact that you let them call unsafe code through interop. It is not Microsoft's responsability to trust or not trust developers.
 - not all behaviours can be detected or even modelized. There are situations where only the developer can tell whether it is acceptable or not to be subject to gc latencies, and where therefore only the developer can tell gc what to do and when to do it. The current gc approach makes it almost impossible to use .Net for real-time apps (besides the fact that Windows is missing a real-time API), because it is fundamentally non-deterministic.

However, I do not want to leave the impression that I'm displeased with what has already been done. Java is not doing any better (although the behaviour of the GC can be highly customized). I'm sincerely impressed, even though the current implementation is not perfect.

Also, I wish to say hello from Paris, France, where the weather today is sunny but freezing. Bravo et merci.
 

evildictaitor wrote:



JChung2006 wrote:  JohnnyAwesome wrote: They wrote J Script in the time-span of several weekends? And he wrote that in Lisp and then rolled a C translator from scratch? There is a reason why I could not work at Redmond and that just about summarizes it. It's not that difficult, especially if you've done it before, like most people would have in any decent computer science graduate program.

Bearing in mind that Computer Science graduate programs didn't exist fifteen years ago, and were a one-year extention of a maths or engineering course.

Sorry for not responding to this long ago, but I just happened to want to see this video again and noticed your comment.

Computer science graduate programs existed 15 years ago.  As a matter of fact, I was in one 15 years ago.  While I was there, I wrote an Ada compiler and a Scheme interpreter in the span of a few weeks after taking courses in programming languages and compilers.

Having recently been persuaded to make enhancements to a program that was written in unmanaged C++, I was reminded how much effort goes into taking out the garbage.  Hooray for GC!  Hooray for Moore's Law that gives us the spare cycles that it takes to automate reclamation of disused objects. 

And for some reason very easy to understand, nice accent. Oh wait... I'm French also....

The video link does not work, is says File not found.