Re: Garbage Colletor

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Larry Smith wrote:
In fact, in .NET the runtime is smart enough to recognize when a reference is not actually used throughout a function, and will in that case release the reference _earlier_ than would be the case for C++.

When an object's reference is no longer accessible, the call to "Finalize()" is non-deterministic.

So what? The finalizer isn't part of the behavior of a correctly written program. You should forget all about the finalizer. It only is relevant when you have a bug.

GC is also a very expensive process.

I have not found it to be so and, even if it were, as I pointed out whatever cost garbage collection has is at least partially, if not completely, mitigated by the fact that releasing an object is a constant-order operation (O(1)), whereas it's O(n) for conventional free/alloc implementations (where n is the number of individually referenced objects in the tree rooted by the object being released).

People who know a lot more about the garbage collector than I do have in this very newsgroup provided very good explanations as to how very efficient garbage collection actually is. The garbage collector doesn't take nearly as much time to do its work as you seem to think it does.

[...]
The bottom line in any case is that you have no choice but to release your resources explicitly if you can't wait for the GC to invoke "Finalize()".

That is simply not true. As I have pointed out several times already, the only time you need to release your resources explicitly is when you have unmanaged resources. And that's an artifact of mixing GC with free/alloc. It's not a problem inherent in garbage collecting.

One more time: if your object references only managed data, then the instant your object is no longer referenced itself, ALL memory resources referenced by that object are also no longer referenced, and are released in the same instance the root level object is.

The finalizer is completely irrelevant and in fact would not even need to exist in a purely garbage-collected environment. It exists only because of the unmanaged, non-garbage-collected resources and it's either a mistake or an outright lie to try to point to the finalizer as some inherent problem with garbage collection.

I'll assume that in this case, it's just a mistake on your part. But you really should stop bringing it up. It's just not relevant.

[...]
So not only is the code no "uglier", the lifetime of the object in .NET much more exactly matches its actual use than it does in C++.

How do you arrive at that conclusion.

Because it's true. An object is eligible for garbage collection after the last statement that references it. The garbage collection need not wait for the variable referencing the object instance to go out of scope, or be set to null, or anything else like that.

And of course, as I have already pointed out, the moment the object is eligible for garbage collection, it is effectively released. It doesn't have to actually be collected for it to be considered logically returned to the collection of available memory resources.

The call to "Finalize()" is non-deterministic but the call to a C++ destructor isn't.

And again, you need to forget about the finalizer. It's not relevant at all in this part of the discussion.

That occurs as soon as it exits its scope which you have complete control over. The destructor is also syntactically cleaner than relying on a "using" statement or calling "Dispose()" directly.

But those statements are also irrelevant to this part of the discussion. They exist for explicit releasing of resources, but they aren't needed unless you a) want to keep the object for later reuse, but release resources (in which case it's exactly the same as C++) or b) you want to ensure that unmanaged resources are also freed (in which case it's not at all relevant to the question of the general paradigm of garbage collection).

In other words, in neither case does "using" or Dispose() have anything to do with any difference there might exist between the free/alloc paradigm and the garbage collection paradigm.

Pete
.

Relevant Pages

  • Re: Garbage Colletor
    ... It's extremely easy to handle resources in C++ as you stated but the ... Logically speaking, the memory is still in fact available, the moment you release your last reference to it. ... The "using" statement and IDisposable exist for one purpose: to explicitly release resources held by an object without releasing the object itself. ... In fact, the garbage collection model is, at least for that particular operation, much more efficient, because there's no need to go through the entire object cleaning things up. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why C# and Java have got it wrong
    ... Do you have any references to the claim that there is a fixation ... on garbage collection? ... that there have been "don't need to manage my resources" evangelizing ... >Java and C# actually provide poor tools for resource management. ...
    (comp.programming)
  • Re: Boxing and Unboxing ??
    ... Well, more to the point, a language that supports garbage collection ... the theory is that an _object_ counts references to ... An int, however, isn't an object. ... C# and Java don't do reference counting. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Boxing and Unboxing ??
    ... Well, more to the point, a language that supports garbage collection ... the theory is that an _object_ counts references to ... An int, however, isn't an object. ... of ever directly dealing with pointers. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: garbage collection / cyclic references
    ... I was reading and Googling about garbage collection, ... Python actually has reference counting backed up by garbage collection. ... Most objects are destroyed as soon as all references to them disappear. ... I once modified BeautifulSoup, the HTML parser, to use weak pointers ...
    (comp.lang.python)