Comments on Entropy Overload: Commonly Confused Tidbits re .NET Garbage Collecto...

You simply can't embed "GC-ness" in ...

2009-12-18T17:30:04.312Z

You simply can't embed "GC-ness" in the type or the variable declaration. All variables (whether they are of a GC type or not, or whether they are of the appropriate declaration or not) need to be findable by the garbage collector in order for it to make sure it doesn't collect an allocation prematurely. If you're going to search a non-GC heap looking for GC references into the GC heap, you've already lost a big chunk of the benefit from GC. And if you try and get around the issue by using some kind of wrapper (like GCHandle in the .NET world) to keep GC references alive from the non-GC world, you lose substantial chunks of usability.

A GC-world by default with selective manual allocation is far more workable than the converse, manual allocation by default with selective GC.

Re "a GC service in the background" - the majority of throughput-oriented collectors do not collect in the background, but rather when an allocation is made which cannot be satisfied without doing a collection. GC services run concurrently usually to reduce GC-induced latencies, typically for GUI applications.

I think somebody has suggested this idea before. ...

2009-12-18T15:44:47.946Z

I think somebody has suggested this idea before. How about adding keyword for out of scope gc object?

var
aStrings: TStringList gc;
aList: TList gc;
aBitmap: TBitmap gc;

This methods doesn't need a gc service to be running at the background at all. of course, user is not allowed to return these objects as a function result (compiling error?)

How about having a set of GC safe common objects t...

2009-12-18T03:41:17.121Z

How about having a set of GC safe common objects that developers could opt to use, TGCStringList, TGCList, TGCBitmap, etc. That would reduce the overall use of try/finally/free by about 90%

Arseny, yes it's possible for the GC to collec...

2009-12-17T16:50:13.936Z

Arseny, yes it's possible for the GC to collect objects which have existing references in variables that are still in scope, but only if the variable is not referred to in subsequent code.

For example, it is even possible for the 'this' reference in C# (equivalent to Self in Delphi) to be garbage collected even while code is executing in a method of the instance, so long as there is no reference to fields or virtual methods etc. in the remainder of the method.

is it possible for an object to be collect by GC w...

2009-12-17T14:40:59.148Z

is it possible for an object to be collect by GC while its is in scope of running function? i

Jolyon, in my experience, in approx 95% of the cas...

2009-12-17T12:25:15.175Z

Jolyon, in my experience, in approx 95% of the cases, doing manual GC is trivial. However, sometimes doing manual GC can get pretty complex (think cases where an object's lifetime isn't related to the call stack nor is owned by a single other object), making it a burden even for highly experienced developers, and forces more complex designs than would have been possible in a language/environment with automatic GC. So even the best developers can benefit a lot from automatic GC because it means one can use simpler (more effective) designs and have one less design issue to take care of.
Quite a few people have asserted that it is generally the best developers who benefits the most from advances in programming languages and technology, not the mediocre ones and I believe automatic GC is one such advancement. It also is an enabler for programming in a more functional style, which in many cases is vastly superior to imperative style.

zurosevic, I can't speak for future Delphi pla...

2009-12-15T23:40:13.863Z

zurosevic, I can't speak for future Delphi plans. Speaking personally, I'd like to see GC be an option, but there are problems with grafting GC onto a language not designed with it in mind, so I'm not sure a native Delphi (as it currently exists) + GC would really extract all the possible benefits.

Barry, thanks for a nice and concise explanation o...

2009-12-15T23:06:29.375Z

Barry, thanks for a nice and concise explanation of most important points about GC...

Does this discussion published by one of the Delphi architects (yourself) mean that potential benefits of GC might bring one (GC) or something similar to Delphi (native) world as well?

Cheers, B.

Very interesting, thanks. I would like to read the...

2009-12-15T20:41:01.641Z

Very interesting, thanks.
I would like to read the explanations of the new programming conceptions from other languages independently whether they will appear in Delphi or not.

Jolyon, from past experience I know there's li...

2009-12-15T20:33:27.649Z

Jolyon, from past experience I know there's little win from arguing with you, so I won't expend much effort.

Briefly:

Type and memory safety combined - which do not by themselves require GC but are a lot easier to implement with GC - make several classes of bugs impossible: dangling pointer, double-free, buffer overflow, uninitialized memory writes, unsafe typecasts, etc.

Secondly, GC can in fact fix bugs in and of itself: a conservative collector can fix memory leaks in an otherwise unmodified program.

Finally, yes, a GC lets you be lazy with respect to memory allocation. This is in fact its primary benefit. Don't forget, laziness is one of the many virtues of the good programmer. Don't do something by hand when you can easily automate it. The fact that you can be lazy WRT memory means you can put more effort into other areas, such as program correctness, efficiency, maintainability, etc.

"This extra safety is one of the reasons why ...

2009-12-15T19:11:07.796Z

"This extra safety is one of the reasons why GC programs often have less bugs than ones using manual allocation."

What's your source for this assertion?

I would put it to you that the people that make the sorts of mistakes leading to bugs that a GC will pick up are people who are going to make other sorts of mistakes too.

A GC will reduce the number of bugs in code written by such people, because it removes one bullet from the loaded gun, but those people are still going to try to shoot themselves in the foot in other ways.

A GC doesn't reduce bugs in and of itself (applying a GC to code that already contains zero memory allocation/overwrite bugs and other things that a GC would "pick up" for you, is a null-op).

But a GC does allow you to be lazy, and in my experience promoting laziness is a sure fire way to promote carelessness and *more* bugs, not fewer, is the inevitable result.

Really good post, GC its a very interesting topic

2009-12-14T21:29:22.234Z

Really good post, GC its a very interesting topic

Excellent. I have always been bugged with how muc...

2009-12-14T18:34:01.311Z

Excellent. I have always been bugged with how much most .NET developers don't know about the GC. Now I have someplace to point them.

Thanks Barry, a great explanation. Your point ab...

2009-12-14T18:21:28.060Z

Thanks Barry, a great explanation.

Your point about potential false "optimisation" by caching objects particularly stuck with me. I also now understand why I witnessed exactly this mis-conception recently concerning Caching Objects vs Creating "fresh" objects triggered by this post about how Twitter has huge problems with their Ruby GC (http://bit.ly/3YLr8u).