You are not logged in.
- Topics: Active | Unanswered
#1 2011-12-09 13:05:58
Avoiding Garbage Collector: Delphi and Apple side by side
Among all trolling subject in forums, you'll find out the great Garbage Collection theme.
Fashion languages rely on it. At the core of the .Net and Java framework, and all scripting languages (like JavaScript, Perl, Python or Ruby), you'll find a Garbage Collector. New developers, just released from schools, do learn about handling memory only in theory, and just can't understand how is memory allocated - we all have seen such rookies involved in Delphi code maintenance, leaking memory as much as they type. In fact, most of them did not understood how a computer works. I warned you this will be a trolling subject.
And, in Delphi, there is no such collector. We handle memory in several ways:
- Creating static variables - e.g. on the stack, or globally;
- Creating objects with class instances allocated on heap - in at least three ways: with a try..finally Free block, with a TComponent ownership model in the VCL, or by using an interface (which creates an hidden try..finally Free block);
- Creating reference-counted variables, i.e. string, array of, interface or variant kind of variables.
It is a bit complex, but it is also deadly powerful. You have several memory allocation models at hand, which can be very handy if you want to tune your performance and let program scale. Just like manual recycling at home will save the planet. Some programmers will tell you that it's a waste of cell brain, typing and time. Linux kernel gurus would not say so, I'm afraid.
Then came the big Apple company, which presented its new ARC model (introduced in Mac OS X 10.7 Lion) as a huge benefit for Objective-C in comparison with the Garbage Collection model. And let's face it: this ARC just sounds like the Delphi memory model.
Feedback from http://blog.synopse.info/post/2011/12/0 … -same-side
Offline
#2 2011-12-09 13:18:06
Re: Avoiding Garbage Collector: Delphi and Apple side by side
Very nice comment of Eric at http://sergworks.wordpress.com/2011/12/ … -in-delphi page:
String are a very different problem, they can't cross-reference themselves, and so reference counting them provides a correct solution memory-management-wise, so the cost is justifiable.
For interfaces, that's not the case, the reference-counting is insufficient as a form of memory-management, hence the need for weak reference and void implementations, which still end up costing time even when they are doing nothing.
If you don't want to see performance issue with interfaces, you need to be careful: only pass them as "const" parameters, don't have functions or methods returning interfaces.
The InitInstance initialization is a major waste, it could be handled by the compiler, this was QC'ed way back in the early days of interface support in Delphi.
As for Apple's ARC, well, it's intended to solve an objective-C shortcoming (of manually having to addRef & Release), and doesn't provide an alternative to GC, as they state in the link you provided; as it has to be since reference-counting doesn't handle graphs.
In the introduction they diss pointers as involving a risk of leaks and dangling references, and some paragraphs further they introduce weak references, which are a new name for the the same thing, see "ARC Enforces New Rules" in the link your provided and then "ARC Introduces New Lifetime Qualifiers".
Offline
#3 2011-12-15 09:28:06
Re: Avoiding Garbage Collector: Delphi and Apple side by side
About interfaces, there is a very clear explanation about their use, and problem of reference-counting at http://oreilly.com/catalog/delphi/chapt … html#34776
Offline
#4 2011-12-22 06:24:05
- esmondb
- Member
- From: London
- Registered: 2010-07-20
- Posts: 299
Re: Avoiding Garbage Collector: Delphi and Apple side by side
Is it just the fashion?
Oberon 2 also implements garbage collection. From my superficial understanding it seems to add complexity for questionable benefits. But why does a non-commercial language so adverse to 'bells and whistles' that it drops the 'for' loop decide to implement garbage collection 
It's not directly relevant but I've just come across this interesting talk by Niklaus Wirth from earlier this year. Someone mentions at the end that the GUI operating system he created is around 200kb - somewhat smaller than OSX or Windows.
Offline
#5 2012-01-13 09:20:48
Re: Avoiding Garbage Collector: Delphi and Apple side by side
Just found out this article:
http://www.finalbuilder.com/Resources/B … ences.aspx
I'll certainly add such a similar feature in mORMot, in order to allow explicit use of interfaces weak references.
The author uses an interface wrapper, which solves issues I face when considering another implementations (like maintaining a list at the original interface level).
Any feedback is welcome.
Offline
#6 2012-02-01 16:59:26
Re: Avoiding Garbage Collector: Delphi and Apple side by side
Very nice answer in SO:
http://stackoverflow.com/questions/4873 … -in-delphi
One idea that you might want to explore is to keep the standard lifetime management for your objects, and let the graph objects keep track of the dependencies instead.
Let each graph object have a list of other objects that it has connections with. Now you can simply free any of the objects, and the housekeeping code for the list will remove all references to the object being destroyed from all other objects. If you want to modify the graph you simply free the nodes that you want removed, and the dependencies will be updated. If you want to destroy the whole graph, just destroy all nodes. Basically you have a list of nodes (ownership, lifetime management) and another data structure for describing the graph.
Source code is available here.
Offline