none
Separate Heap like LOH for Objects alive through out the life of the application RRS feed

  • Question

  • Why not have a separate Heap like LOH for Objects that will remain alive through out the life of the application wouldn't that help improve performance of GC.
    Application code can always mark objects during creation for this special heap.
    KP
    Tuesday, April 7, 2009 6:39 AM

Answers

  • I understand that 3rd generation are for long lived objects and it visits this generation rarely but when it does its expensive. 
    The  kind of heap i am describing GC never have to visit this heap where objects are never destroyed.
    KP
    Why is it expensive? Good design implies there should not be much of singletons in application (only some in service layer, like Cache). And usually implementation of Singleton pattern in .NET implies usage of static field. And in case of static fields it is really easy and really fast for GC to track objects referenced by static fields.

    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    • Marked as answer by Kiran Prabhu Wednesday, April 8, 2009 5:10 AM
    Tuesday, April 7, 2009 9:52 AM
  • This goes completely against the grain of what .NET memory management is all about.  Any C/C++ programmer will tell you that explicit memory management is a lot harder to get right than it looks.  Especially exceptions tend to upset assumptions about the lifetime of an object.  It is so difficult that C/C++ programmers tend to avoid raising exceptions to avoid getting their programs to leak like a sieve.  Trading leaks for random undetected and undiagnosable failure.  Besides, the GC is already quite capable of dealing with long-lived objects and it is not expensive.
    Hans Passant.
    • Marked as answer by Kiran Prabhu Wednesday, April 8, 2009 5:10 AM
    Tuesday, April 7, 2009 10:56 AM
    Moderator

All replies

  • Hello,

    GC has three generations. And all objects in the third GC generation are considered to be long living - garbage collection occurs very rarely in this generation. So "special heap" you are describing is already in there - 3rd generation.
    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    Tuesday, April 7, 2009 7:41 AM
  • I understand that 3rd generation are for long lived objects and it visits this generation rarely but when it does its expensive. 
    The  kind of heap i am describing GC never have to visit this heap where objects are never destroyed.
    KP
    Tuesday, April 7, 2009 9:40 AM
  • I understand that 3rd generation are for long lived objects and it visits this generation rarely but when it does its expensive. 
    The  kind of heap i am describing GC never have to visit this heap where objects are never destroyed.
    KP
    Why is it expensive? Good design implies there should not be much of singletons in application (only some in service layer, like Cache). And usually implementation of Singleton pattern in .NET implies usage of static field. And in case of static fields it is really easy and really fast for GC to track objects referenced by static fields.

    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    • Marked as answer by Kiran Prabhu Wednesday, April 8, 2009 5:10 AM
    Tuesday, April 7, 2009 9:52 AM
  • This goes completely against the grain of what .NET memory management is all about.  Any C/C++ programmer will tell you that explicit memory management is a lot harder to get right than it looks.  Especially exceptions tend to upset assumptions about the lifetime of an object.  It is so difficult that C/C++ programmers tend to avoid raising exceptions to avoid getting their programs to leak like a sieve.  Trading leaks for random undetected and undiagnosable failure.  Besides, the GC is already quite capable of dealing with long-lived objects and it is not expensive.
    Hans Passant.
    • Marked as answer by Kiran Prabhu Wednesday, April 8, 2009 5:10 AM
    Tuesday, April 7, 2009 10:56 AM
    Moderator
  • Any C/C++ programmer will tell you that explicit memory management is a lot harder to get right than it looks.  Especially exceptions tend to upset assumptions about the lifetime of an object.  It is so difficult that C/C++ programmers tend to avoid raising exceptions to avoid getting their programs to leak like a sieve.  Trading leaks for random undetected and undiagnosable failure. 
    Hans Passant.

    Reediculous. You must never have programmed in C++. Memory management in C++ is very straightforward. RIA patterns, and smart pointers are a safe and effective method for managing allocated memory. I can't remember the last time I ran into a problem with memory leaks in a production C++ program.

    C++ programmers routinely use exceptions. In contemporary coding styles, exceptions are the preferred method of handling errors, and the use of exceptions is not just routine, but mandatory in the environments in which I develop.

    Ironically, it's far easier to leak critical resources into the heap in C#, where one never knows which objects implement IDisposable, and which require using clauses. And the performance issues with exceptions in .net languages render one of the most important error handling techniques in modern programming languages virtually unusable in .net.
    Thursday, April 16, 2009 1:25 PM
  • Even if there were such a heap, the overhead of walking references within these object would probably dominate the overhead saved by not trying to compact them. These long-lived objects would still have to be walked for references. Effectively, getting promoted to gen3 heap does the same thing -- except that the process is automatic, rather than explicit.

    Thursday, April 16, 2009 1:32 PM
  • Ironically, it's far easier to leak critical resources into the heap in C#, where one never knows which objects implement IDisposable, and which require using clauses.
    Funny :). Do you really believe this, what you've stated? Microsoft invested enormous amount of money in CLR and GC (automatic memory management!) and here you go: it's much easier to introduce memory leaks in automatic memory management system than in manual one!
    And IDisposable has nothing to do with memory leaks .
    But if one never knows whether particular object implements IDisposable or not - the one should never write any code in .NET. It is very easy even in dynamically generated code to check whether object implements IDisposable.
    And the performance issues with exceptions in .net languages render one of the most important error handling techniques in modern programming languages virtually unusable in .net.
    Could you clarify this point and describe it in more details?


    Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/
    Thursday, April 16, 2009 2:07 PM
  • Hmya, maybe he tried to actually measure it.  In which case he won't be back.  Guaranteeing destructor calls is expensive.  Not to mention /EHa and the 32-bit SEH chain.
    Hans Passant.
    Friday, April 17, 2009 1:24 AM
    Moderator