Channel 9 Forums - Coffeehouse - Patrick Dussud interview next week: Questions?

Coffeehouse - Patrick Dussud interview next week: Questions?

Charles — Wed, 30 May 2007 01:18:37 GMT

We're lucky enough to have gotten on Patrick Dussud's calendar for a Going Deep interview to take place next Friday (that's Friday, June 8, 2007). For those who may not know, Patrick is a Distinguished Engineer and creator of the CLR's garbage collector and related technologies. We've wanted to chat with Patrick for a while. Finally, we got him!

So, for those of you out there who have been working with managed code for a while (.NET flavor), got any questions (the more technical, the better, but of course personal is fine since this is Channel 9 and humans make software...)?

What do you want to know about the CLR's GC? What about GCs in general?

Ask away and I'll be sure to include a few of your questions in my next Going Deep.

Thanks!
C

Coffeehouse - Patrick Dussud interview next week: Questions?

sushovande — Wed, 30 May 2007 04:45:02 GMT

Is it true that I should not call GC.Collect() manually because that would adversely affect the garbage collection schedule? How badly will it affect? Is it beneficial to call Collect() just before allocating a large chunk of memory?

Coffeehouse - Patrick Dussud interview next week: Questions?

DoomBringer — Wed, 30 May 2007 08:04:29 GMT

sushovande wrote:

Is it true that I should not call GC.Collect() manually because that would adversely affect the garbage collection schedule? How badly will it affect? Is it beneficial to call Collect() just before allocating a large chunk of memory?

The only time to call GC.Collect() (or its Java equivalent) is when you're absolutely certain of what you are doing. For instance, if you've just finished using 10,000 objects (or more, depending on size) you are never using again and you need to make a whole bunch more, then you might be wise to call it. However, I'm reasonably sure that calling that function could just be ignored (in .NET or Java), as the run-time tends to know better than you do. The vast majority of the time, you're not even working with enough dead objects that it is going to matter. Garbage collection in .NET (in theory; of course, I read this back in version 1.0) only happens when you're running out or low on memory.

(All of the following is based on my memory from a few years back. I could be wrong) Memory in the .NET runtime is different than what the OS does. The OS does some tricks to track what parts of memory are in use, which takes much more time (relatively speaking) than .NET for allocations. .NET just maintains a pointer to the top of the heap, and memory is allocated in chunks. If you're running out, GC.Collect will find blocks of memory that aren't in use and compact. I actually did a presentation on this way back in the day for the MSDN AA, but things could have changed.

This would still be a good question though, because I get the impression that memory management is a bit of a mystery. Covering how .NET works here would be good for all devs to know: knowing how to write code doesn't mean you know what is actually going on. This is why I advocate everyone learning an honest to goodness assembly language like IA-32 or x64. Studying C and C++ was great, but once I saw how things would translate down lower made great sense to me. (Of course, individual instructions carry their own costs, knowing adder and shifter circuit designs shows why one is faster than the other)

Coffeehouse - Patrick Dussud interview next week: Questions?

Herbie Smith — Wed, 30 May 2007 08:40:08 GMT

Personal questions:

What's his background; how did he end up doing what he does?

What does he do in his spare time and does he draw inspiration from that for his work, or does he see many analogies/parallels between his hobbies and work?

Herbie

Coffeehouse - Patrick Dussud interview next week: Questions?

Chadk — Wed, 30 May 2007 19:39:11 GMT

I wanna know a few things

- Where is the GC heading? What are some of the major breaktroughs in the technology that is on the horizon, that will make the current technology better? And how will it change over time? Will it become more intelligent?

- In how many cases is a GC not a good thing? I see that for a operative system like enviroment, you to some extend might wanna do it yourself. While we see that singularity is build in a C#-like language, what are the challenges to make the GC a thing which have less backsides, which allows its to be used in most, if not all, cases?

Coffeehouse - Patrick Dussud interview next week: Questions?

anand.t — Wed, 30 May 2007 20:01:27 GMT

silverlight - challenges/changes to the gc.

Coffeehouse - Patrick Dussud interview next week: Questions?

Stefán Jökull Sigurðarson — Thu, 31 May 2007 14:04:29 GMT

Larry Osterman has said that the GC is one factor that speaks against using managed code for multimedia apps since many multimedia tasks rely on low-latency buffer reads/writes so the GC interrupting that flow (even for just a few milliseconds) can result in audible clicks and pops in audio for example.

Is the GC being worked on to make it more "low-latency friendly" to make managed code more multimedia-friendly?

Coffeehouse - Patrick Dussud interview next week: Questions?

SecretSoftware — Thu, 31 May 2007 17:17:12 GMT

Explain how do objects get marked for Garbage Collection, and why is it the case that we cannot predict when a GC visit will happen? Also, when does the collection actually happen?

What causes an object to move from Generation 0 to Generation 1 or to Generation 2, and why is most process memory in Generation 2?

Can a .NET application have a true memory leak as in the C++ sense where we allocate a chunk of memory and throw away the handle/pointer to it?

What does Garbage Collection for the Garbage Collector?

How does Multi-Core processors improve performance of GC Operations? Can parallelism benifit things in GC? [GC Threads].

In the Database Connection side, why do I have to close and dispose its objects? Isnt that the job of the GC?

Why does GC Halt Program execution as it searches for objects to GC? Isnt this bad for performance?

What happens when the GC is unable to reclaim memory used by objects marked for Garbage collection? How does GC behave under exhaustive system conditions ?

Can GC cause memory corruption?

Thanks

Coffeehouse - Patrick Dussud interview next week: Questions?

SecretSoftware — Thu, 31 May 2007 20:45:44 GMT

littleguru wrote:

Hey Charles,

I have a few:

- What are the challenges in implementing a GC that is also written in managed code?

- Why does WeakReference not have a Event that fires upon the Garbage collector has collected the object (i have seen that WeakReference is integrated very deeply in the CLR - he might perhapshave infos on this)?

- What was the biggest challenge when building GC v1.0? Has the GC been written from scratch for .NET 1.0?

- Why isn't it possible to force the GC to do a collect. I mean GC.Collect() just signalizes that a collect is required, but the GC could decide to do not. Why has this been implemented in that way?

- I have seen that memory is not always returned to the Windows operating system. I know that requesting memory from Windows is slow. What's the threshold here? Does this vary from Windows to Windows? Windows XP vs Windows Server 2003...

- What are the major differences between the GC in the compact framework and the GC in the full desktop framework? What should we look after when we code for the compact framework and want the GC to be efficient?

- Are there any upcoming changes for .NET 3.5? Why does WeakReference still not have a Collected event?

- What was the biggest (big as hardest to fix) bug he ever found in the GC?

- Is the GC building the reachable tree on each run? Or are there caching mechanism build in? How long does an average run take (I don't know if this one is possible to respond to)?

- When a class implements a finalizer and the GC detects that the class is no longer referenced the finalizer is called and the class is put in a separate list and removed in the next run. What were the decissions to build that in this way? Why not clean the immediately after all other classes have been removed - why wait for the next run?

Coffeehouse - Patrick Dussud interview next week: Questions?

Jaz — Thu, 31 May 2007 23:21:38 GMT

my friend (who is to lazy to signup) asks

"

All this discussion is about the collection of unused objects regarding the GC. I'd like to hear about how the memory management and object referencing system knows when an object is garbage and a candidate for collection.

Not just stuff about the collection process."

perhaps you could ask something like that.

*edit*

Coffeehouse - Patrick Dussud interview next week: Questions?

Minh — Sun, 03 Jun 2007 23:27:36 GMT

What's the best practice re: the GC for a performance-sensitive app like a 3D XNA game?

Littleguru wrote:

- Why isn't it possible to force the GC to do a collect. I mean GC.Collect() just signalizes that a collect is required, but the GC could decide to do not. Why has this been implemented in that way?

If this is indeed true, can't we have a GC.Collect(bool meanIt); ?

Coffeehouse - Patrick Dussud interview next week: Questions?

DoomBringer — Wed, 06 Jun 2007 00:32:02 GMT

Minh wrote:

Littleguru wrote:
- Why isn't it possible to force the GC to do a collect. I mean GC.Collect() just signalizes that a collect is required, but the GC could decide to do not. Why has this been implemented in that way?

If this is indeed true, can't we have a GC.Collect(bool meanIt); ?

Probably because the GC knows more about current memory than the developer does 99% of the time. Forcing a GC when there are only a few dozen objects that need cleaning up is a bad idea. GC collection is a high overhead operation and calling it arbitrarily is bad practice nearly all of the time.

Coffeehouse - Patrick Dussud interview next week: Questions?

Minh — Wed, 06 Jun 2007 03:51:54 GMT

DoomBringer wrote:

Minh wrote:

Littleguru wrote:
- Why isn't it possible to force the GC to do a collect. I mean GC.Collect() just signalizes that a collect is required, but the GC could decide to do not. Why has this been implemented in that way?

If this is indeed true, can't we have a GC.Collect(bool meanIt); ?

Probably because the GC knows more about current memory than the developer does 99% of the time. Forcing a GC when there are only a few dozen objects that need cleaning up is a bad idea. GC collection is a high overhead operation and calling it arbitrarily is bad practice nearly all of the time.

I don't agree. The end-result for a GC.Collect is ALWAYS a less fragmented memory space. So there must be a penalty if they don't want us to do this all the time.

I'm guessing that penalty is the runtime becomes unresponsive for a while. In a game, you'd do anything not to have the GC runs its Collect routine in the middle of a game, and if you could, you should minimize that chance when it's OK to run at a lower framerate, say, the user is shopping for a new sword with his loot.

Now, the crazy desktop app programmer who thinks he knows better by running GC.Collect everytime the user click on a button will be punished by having his app run like crap --- but at least that's a positive feedback for him to remove that GC.Collect.

If you can't deterministically run GC.Collect() as a game programmer, you're punished by a run-time that think it knows better.

Coffeehouse - Patrick Dussud interview next week: Questions?

DoomBringer — Wed, 06 Jun 2007 06:34:12 GMT

Minh wrote:

DoomBringer wrote:

Minh wrote:

Littleguru wrote:
- Why isn't it possible to force the GC to do a collect. I mean GC.Collect() just signalizes that a collect is required, but the GC could decide to do not. Why has this been implemented in that way?

If this is indeed true, can't we have a GC.Collect(bool meanIt); ?

Probably because the GC knows more about current memory than the developer does 99% of the time. Forcing a GC when there are only a few dozen objects that need cleaning up is a bad idea. GC collection is a high overhead operation and calling it arbitrarily is bad practice nearly all of the time.

I don't agree. The end-result for a GC.Collect is ALWAYS a less fragmented memory space. So there must be a penalty if they don't want us to do this all the time.

I'm guessing that penalty is the runtime becomes unresponsive for a while. In a game, you'd do anything not to have the GC runs its Collect routine in the middle of a game, and if you could, you should minimize that chance when it's OK to run at a lower framerate, say, the user is shopping for a new sword with his loot.

Now, the crazy desktop app programmer who thinks he knows better by running GC.Collect everytime the user click on a button will be punished by having his app run like crap --- but at least that's a positive feedback for him to remove that GC.Collect.

If you can't deterministically run GC.Collect() as a game programmer, you're punished by a run-time that think it knows better.

It will always be less fragmented, yes, (except the very edge case of course) but the CPU time required for a full GC round is pretty significant. Moreover, with how much memory most systems have these days, your app might not even get any benefit in the long run: if I compact memory after allocating and dropping only a few dozen megabytes, well, that isn't all that great, since you've got hundreds more usually. (The story on the mobile side is different, however, since there is less memory. I don't know the mobile stuff as well really.)

I'm thinking the best time for a GC is after you've blown through a lot of temporary objects, and are moving on to another very large round of allocations. It probably hurts more to get interrupted during the middle of your allocaiton phase, instead of before any at all. I'm talking about a large amount of data here too, something that you know is going to eat up a lot of RAM (several dozen or more megs). The average "Oh Look A WinForm" app isn't going to use all that much.

I don't know how games would deal with it, but I would guess you could build a strategy to deal with it. I'm thinking that the majority of item creations are going to be during load sequences, so having a GC run in there wouldn't be so bad.

Adding a boolean flag to indicate "ya, srsly" to the GC is kind of silly. No developer would ever use false, because they'd all think that they knew what they were doing.

Finally, I just think that if somebody is writing an application that needs ultra-fine-grained control over memory control and demands high performance, then it probably needs to be written in native code. A business app that pops up a WinForm and queries a few databases isn't going to need to have millisecond precision, after all, but Gears of War will.

Coffeehouse - Patrick Dussud interview next week: Questions?

AndyC — Wed, 06 Jun 2007 07:47:25 GMT

Minh wrote:

I don't agree. The end-result for a GC.Collect is ALWAYS a less fragmented memory space. So there must be a penalty if they don't want us to do this all the time.

If you can't deterministically run GC.Collect() as a game programmer, you're punished by a run-time that think it knows better.

The penalty is that things would get pushed into older generations much earlier than they should and consequently are much more like to live longer and hog memory unnecessarily.

Games programming requires a slight shift in mindset. You shouldn't ever get punished by the GC because you shouldn't really be doing any allocations during the critical path. It's all about reserving resources in advance and then reusing them efficiently.

Coffeehouse - Patrick Dussud interview next week: Questions?

Zhou Yong — Wed, 06 Jun 2007 07:49:23 GMT

Is it possible to build the weak event paradigm directly into CLR so that we ain't need to rely on some out of band techniques to tackle the lifetime management issue related to CLR events?

Sheva

Coffeehouse - Patrick Dussud interview next week: Questions?

Minh — Wed, 06 Jun 2007 14:35:26 GMT

DoomBringer wrote:

I don't know how games would deal with it, but I would guess you could build a strategy to deal with it. I'm thinking that the majority of item creations are going to be during load sequences, so having a GC run in there wouldn't be so bad.

Which spawn another question for me. So while a true GC.Collect() is under way, does the entire runtime stop? Are all objects unavailable to the app? What's the refresh scenario in this situation?

DoomBringer wrote:

Adding a boolean flag to indicate "ya, srsly" to the GC is kind of silly. No developer would ever use false, because they'd all think that they knew what they were doing.

It's not silly. Of course all the devs would pass in true, but in my case it'd be appropriate

DoomBringer wrote:

Finally, I just think that if somebody is writing an application that needs ultra-fine-grained control over memory control and demands high performance, then it probably needs to be written in native code. A business app that pops up a WinForm and queries a few databases isn't going to need to have millisecond precision, after all, but Gears of War will.

Well, MS is positioning XNA as a viable Xbox Live Arcade framework. It's not Gears of War, but the last thing you want to see a game sputter during mid-play.

Well, that's another question:

How's the GC on the Xbox different than the PC one?

Coffeehouse - Patrick Dussud interview next week: Questions?

Minh — Wed, 06 Jun 2007 14:40:26 GMT

AndyC wrote:

Games programming requires a slight shift in mindset. You shouldn't ever get punished by the GC because you shouldn't really be doing any allocations during the critical path. It's all about reserving resources in advance and then reusing them efficiently.

I agree. But take this scenario. During a level load, I allocate all my objects. Fine. Played the level. Time to load another level. What I would like to do is to "deallocate" the previous level. Do a GC.Collect(true);. Then load the new level.

I realize that I can unreference the previous level, load the new level, and if there was memory pressure during the new load, a Collect will be done. But I don't know what other factors can create a memory pressure during gameplay.

Coffeehouse - Patrick Dussud interview next week: Questions?

DoomBringer — Wed, 06 Jun 2007 22:34:48 GMT

Minh wrote:

DoomBringer wrote:

I don't know how games would deal with it, but I would guess you could build a strategy to deal with it. I'm thinking that the majority of item creations are going to be during load sequences, so having a GC run in there wouldn't be so bad.

Which spawn another question for me. So while a true GC.Collect() is under way, does the entire runtime stop? Are all objects unavailable to the app? What's the refresh scenario in this situation?

DoomBringer wrote:

Adding a boolean flag to indicate "ya, srsly" to the GC is kind of silly. No developer would ever use false, because they'd all think that they knew what they were doing.

It's not silly. Of course all the devs would pass in true, but in my case it'd be appropriate

DoomBringer wrote:

Finally, I just think that if somebody is writing an application that needs ultra-fine-grained control over memory control and demands high performance, then it probably needs to be written in native code. A business app that pops up a WinForm and queries a few databases isn't going to need to have millisecond precision, after all, but Gears of War will.

Well, MS is positioning XNA as a viable Xbox Live Arcade framework. It's not Gears of War, but the last thing you want to see a game sputter during mid-play.

Well, that's another question:

How's the GC on the Xbox different than the PC one?

I'm not sure. The runtime might have to stop a particular thread while things are being cleaned up for that thread, but these are good questions.

Coffeehouse - Patrick Dussud interview next week: Questions?

Charles — Thu, 07 Jun 2007 00:05:07 GMT

Great questions. We'll get some answers from the person who knows best

Coffeehouse - Patrick Dussud interview next week: Questions?

Ion Todirel — Thu, 07 Jun 2007 21:20:35 GMT

whats next (CLR-GC)??

Coffeehouse - Patrick Dussud interview next week: Questions?

Chadk — Sun, 28 Oct 2007 13:52:30 GMT

Siyavash wrote:

hm... I was bored.... so I went to page "1392" and dug up this thread, just for fun. I'm probably the first one doing such a useless thing here.

Just stop bloody necroing. Its SO not cool.

Coffeehouse - Patrick Dussud interview next week: Questions?

GoddersUK — Sun, 28 Oct 2007 15:22:26 GMT

I did notice the other day that this thread and one other that were that had fairly recent last post dates were on the very last page under heaps of older threads (last post date 2004 threads).

Any reason?

Coffeehouse - Patrick Dussud interview next week: Questions?

Bent Rasmussen — Sun, 28 Oct 2007 17:21:27 GMT

SecretSoftware wrote:

Can a .NET application have a true memory leak as in the C++ sense where we allocate a chunk of memory and throw away the handle/pointer to it?

Hopefully not in safe code, but there is unsafe.

SecretSoftware wrote:

How does Multi-Core processors improve performance of GC Operations? Can parallelism benifit things in GC? [GC Threads].

I find this fascinating as well. I seem to recall Bertrand Meyer (Eiffel) contemplating a GC "processor".

...Bah, moot thread anyway...