Coffeehouse Thread

24 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Patrick Dussud interview next week: Questions?

Back to Forum: Coffeehouse
  • User profile image
    Charles

    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

  • User profile image
    sushovande

    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?

  • User profile image
    DoomBringer

    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)

  • User profile image
    Dr Herbie

    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

     

  • User profile image
    Chadk

    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?

  • User profile image
    anand.t

    silverlight  - challenges/changes to the gc.

  • User profile image
    Stebet

    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?

  • User profile image
    Secret​Software

    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

  • User profile image
    Secret​Software

    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?

  • User profile image
    Jaz

    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*

  • User profile image
    Minh

    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); ?

  • User profile image
    DoomBringer

    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.

  • User profile image
    Minh

    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.

  • User profile image
    DoomBringer

    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.

  • User profile image
    AndyC

    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.

  • User profile image
    footballism

       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

  • User profile image
    Minh

    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 Wink

    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?

  • User profile image
    Minh

    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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.