Garbage Collection
Sanyin
Image how many delphi developers are not aware of memory leaking.I think
most of them are not.
I didn't know few years ago that c++ has it.At least I didn't think about
that.
Why not to implement that?
I know for QC, but I need to know of drawbacks of GC (for classes of
course)..Any?
Oliver Townshend
> Image how many delphi developers are not aware of memory leaking.I think
> most of them are not.
Somehow I think you've just discovered the issue :)
> I didn't know few years ago that c++ has it.At least I didn't think about
> that.
> Why not to implement that?
> I know for QC, but I need to know of drawbacks of GC (for classes of
> course)..Any?
Its in the .Net version of Delphi, and there were about 3 years worth of
discussions in this (and other newsgroups) on the issue. Why don't you read
those posts?
Oliver Townshend
Sanyin
"Oliver Townshend" <oliveratcodelegaldotcomdotau> wrote in message
news:478d...@newsgroups.borland.com...
> Its in the .Net version of Delphi, and there were about 3 years worth of
> discussions in this (and other newsgroups) on the issue. Why don't you
> read those posts?
3 years of discussion for that?
OK, in short, is main issue maybe performace loss when using garbage
collector?
Oliver Townshend
> collector?
I think its the non-deterministic nature of it. There's also a problem with
objects referencing each other which prevents the items releasing.
If you get hold of fastmm4, it helps you to find your memory leaks. I think
you'll find that better value.
Oliver Townshend
Sanyin
"Oliver Townshend" <oliveratcodelegaldotcomdotau> wrote in message
news:478d...@newsgroups.borland.com...
>> collector?
>
> I think its the non-deterministic nature of it. There's also a problem
> with objects referencing each other which prevents the items releasing.
>
> If you get hold of fastmm4, it helps you to find your memory leaks. I
> think you'll find that better value.
yes, but delphi is here for many years, and this problem (leaking) is not
emphasized enough.
They could at least provide us with some MM that helps, instead of few words
in manuals, etc
Mark A. Andrews
> It is very sad that delphi odesn't have an garbage collector.
NO, it ISN'T!
> Image how many delphi developers are not aware of memory leaking.I think
> most of them are not.
Any Delphi developer who has written any program of any size in Delphi
most certainly is aware of memory leaking.
> I didn't know few years ago that c++ has it.At least I didn't think about
> that.
Delphi is NOT C++. Delphi is NOT C#. Delphi is NOT Java. And thank God
it isn't.
> Why not to implement that?
Because it isn't needed.
> I know for QC, but I need to know of drawbacks of GC (for classes of
> course)..Any?
>
I, for one, am happy that Delphi (Win32) doesn't have garbage
collection. Properly designed and coded applications don't need garbage
collection. If you assign an object an owner, Delphi will automatically
free objects that are still lingering when the parent object is
destroyed. However, depending on this is poor design and should be
considered a fail-safe only.
Design your application correctly and you won't need garbage collection.
Garbage collection leads to sloppy, bloated, inefficient code! Not
having garbage collection is one of the assets of Delphi; it is not a
liability.
However, being human, you are going to create memory leaks. Use FastMM
and it will help you find all those memory leaks you inadvertently
create. Also, doing a periodic, thorough walk-through of your code will
let you see them (and find other problems as well). When you fix the
leaks, your application will use memory more efficiently, won't cause
the computer to slow to a crawl over time and will keep the user of your
software happy. You won't be wasting the computer user's precious cpu
cycles (which you DON'T own) on a GC process just because you didn't
want to deal with deallocating memory.
GC will never replace a good, well defined, software engineering
process. Don't ever depend on the computer to pickup your dirty
underwear. Grow up, be an adult and do it yourself!
Mark
Cesar Romero
> I, for one, am happy that Delphi (Win32) doesn't have garbage
> collection. Properly designed and coded applications don't need
> garbage collection. If you assign an object an owner, Delphi will
> automatically free objects that are still lingering when the parent
> object is destroyed. However, depending on this is poor design and
> should be considered a fail-safe only.
>
> Design your application correctly and you won't need garbage
> collection. Garbage collection leads to sloppy, bloated, inefficient
> code! Not having garbage collection is one of the assets of Delphi;
> it is not a liability.
>
> However, being human, you are going to create memory leaks. Use
> FastMM and it will help you find all those memory leaks you
> inadvertently create. Also, doing a periodic, thorough walk-through
> of your code will let you see them (and find other problems as well).
> When you fix the leaks, your application will use memory more
> efficiently, won't cause the computer to slow to a crawl over time
> and will keep the user of your software happy. You won't be wasting
> the computer user's precious cpu cycles (which you DON'T own) on a GC
> process just because you didn't want to deal with deallocating memory.
>
> GC will never replace a good, well defined, software engineering
> process. Don't ever depend on the computer to pickup your dirty
> underwear. Grow up, be an adult and do it yourself!
Mark, you told exactly what I was about to write here...
--
[]s
Cesar Romero
Sanyin
"Mark A. Andrews" <KE...@KE4MA.com> wrote in message
news:478e07ec$1...@newsgroups.borland.com...
> Sanyin wrote:
Delphi has GC, for arrays, strings, records.
So it has 3/4 of it :)
Only class gc is missing, thats all what I need.
I know pascal is not c++, and maybe gc produces slopy code, but I dont
think its matter for classes.
You said that developers are aware of leaking.Yes, but theres no ANY tools
for that ,except commercial or recently, fastmm4.
Memory leaking should be there, becase, when you create class, you'll
optimize its methods, not destroying or creating.
You said "Grow up, be an adult and do it yourself!" but thats very stupid
thinking.
GC is there (arrays, records,strings).
Also, you cannot define prog.engineering programming only with pascal.
Please, be an adult and program with pointers.
Be an adult and dont use records, strings, or dynamic arrays!
(that souns like asm?)
Kostya
> It is very sad that delphi odesn't have an garbage collector.
> Image how many delphi developers are not aware of memory leaking.I think
> most of them are not.
Speechless
JC
> It is very sad that delphi odesn't have an garbage collector.
> Image how many delphi developers are not aware of memory leaking.I think
> most of them are not.
> I didn't know few years ago that c++ has it.At least I didn't think about
> that.
The ultimate solution for unhappy delphi coder would then be like this
var
done : boolean;
begin
done := False;
repeat
try
SomeClass.Create(....
done := True;
except on E : EOutOfMemory do DoGarbageCollection;
end;
until done;
end;
Sanyin
"Kostya" <thanks@but_no_thanks.com> wrote in message
news:478e0ebb$1...@newsgroups.borland.com...
If it is speechless, then dont speak
Ivan Rakyta
but before you get EOutOfMemory, windows will swap and swap for couple of
minutes and the whole system will become unusable.
That's what I experience with some .NET stuff
"JC" <j...@gmail.com> wrote in message
news:478e1159$1...@newsgroups.borland.com...
Rudy Velthuis [TeamB]
> It is very sad that delphi odesn't have an garbage collector.
> Image how many delphi developers are not aware of memory leaking.I
> think most of them are not. I didn't know few years ago that c++ has
> it.
Hey, I'm sure most of the C++ gurus, like Stroustrup, Sutter, etc.
don't even know. <eg>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"I think it would be a good idea."
-- Mahatma Gandhi (1869-1948), when asked what he thought of
Western civilization
Rudy Velthuis [TeamB]
> > OK, in short, is main issue maybe performace loss when using
> > garbage collector?
>
> I think its the non-deterministic nature of it. There's also a
> problem with objects referencing each other which prevents the items
> releasing.
That may be true for reference counted objects, and perhaps for some
other simple or clumsy attempts at garbage collection, but most modern
garbage collectors don't have any problems with mutual or circular
references.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"You got to be careful if you don't know where you're going,
because you might not get there." -- Yogi Berra
us...@domain.invalid
> It is very sad that delphi odesn't have an garbage collector.
> Image how many delphi developers are not aware of memory leaking.I think
> most of them are not.
Smart delphi developers have been aware of Memory trace tools for years,
Memproof was such a tool which works quite well and is free. As
developers progress, they become more aware of the type of code which
leads to memory leaks. My understanding is that this is called "learning
the hard way".
Rudy Velthuis [TeamB]
> Design your application correctly and you won't need garbage
> collection. Garbage collection leads to sloppy, bloated, inefficient
> code!
I've seen that mentioned often, but I have never ever seen any evidence
of that. Oh, I'm sure someone could create or point to an inenfficient
garbage collector and then show me how inefficient or bloated it is,
but a good modern garbage collector is not.
Garbage collection relieves you of a whole class of errors, errors that
are by far the most common errors made and often also very hard to
debug. So garbage collection is, IMO, certainly something very
beneficial.
WRT the sloppy code, this depends on the programmer. If the programmer
gladly accepts the benefits of a garbage collector, but otherwise keeps
on programming the same cautious way you advocate, the resulting code
will be a lot better, not worse.
I also notice that hardly anyone ever complained about the fact that in
Delphi, strings or dynamic arrays are more or less garbage collected.
<g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"No Sane man will dance." -- Cicero (106-43 B.C.)
Rudy Velthuis [TeamB]
> Both are perfectly legitimate points of view. There could indeed be
> built-in support into Delphi for chasing memory leaks. Why not?
Indeed. C++Builder has CodeGuard, AFAIK.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"If quantum physics doesn't confuse you then you don't
understand it." -- Niels Bohr
Steve Thackery
would disagree with him about "most" Delphi developers being unaware of
memory leakage, he does raise a couple of points that might warrant some
thought and discussion:
"Delphi has GC, for arrays, strings, records.
So it has 3/4 of it :)"
"You said that developers are aware of leaking.Yes, but theres no ANY tools
for that ,except commercial or recently, fastmm4.
Memory leaking should be there, becase, when you create class, you'll
optimize its methods, not destroying or creating."
Both are perfectly legitimate points of view. There could indeed be
built-in support into Delphi for chasing memory leaks. Why not? Especially
when, with the best will in the world, Delphi code can be prone to memory
leaks unless the designer is especially careful. (And whom amongst you
doesn't make mistakes?).
The point that arrays, strings and records are already better looked after
than objects is something I hadn't thought much about, and again I wouldn't
want to dismiss it with the derisory snort some of you have used.
Without people challenging existing paradigms, nothing would change.
SteveT
Rudy Velthuis [TeamB]
>
> "Mark A. Andrews" <KE...@KE4MA.com> wrote in message
> news:478e07ec$1...@newsgroups.borland.com...
> > Sanyin wrote:
>
> Delphi has GC, for arrays, strings, records.
You mean reference counting. That is merely a poor man's version of
garbage collection.
Oh, and FWIW, records don't have reference counting. Neither do arrays,
in general. Only dynamic arrays are reference counted. And you forgot
interfaces, widestrings and variants.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"They show you how detergents take out bloodstains. I think if
you've got a T-shirt with bloodstains all over it, maybe your
laundry isn't your biggest problem." -- George Carlin
Alexandre Machado
Count me in!
Regards,
Alexandre C. Machado
Cesar Romero
> > Design your application correctly and you won't need garbage
> > collection. Garbage collection leads to sloppy, bloated, inefficient
> > code!
>
> I've seen that mentioned often, but I have never ever seen any
> evidence of that. Oh, I'm sure someone could create or point to an
> inenfficient garbage collector and then show me how inefficient or
> bloated it is, but a good modern garbage collector is not.
I did, lot of times, and you can just read .NET and Java Newsgroups to
see people that uses, complaining about that.
well, you dont need go so far, go to oodesign and you will see people
finding a way to avoid the CG in .NET
[]s
Cesar Romero
Eric Grange
> Delphi, strings or dynamic arrays are more or less garbage collected.
> <g>
However, those are value types.
Automated cleanup for value types is a "natural" behaviour, for which
none of the GC quirks materialize (assuming you don't involve pointers
to said value types, and that your GC is a deterministic one, like
Delphi's for strings & arrays).
Objects, being references, are a completely different story.
A non-deterministic GC behaviour also makes for a completely different
story, going as far as requiring the introduction of "warts", such as
IDispose, to reintroduce determinism.
Eric
Mark A. Andrews
> Delphi has GC, for arrays, strings, records.
> So it has 3/4 of it :)
> Only class gc is missing, thats all what I need.
> I know pascal is not c++, and maybe gc produces slopy code, but I dont
> think its matter for classes.
>
Code included by the compiler to allocate/deallocate memory for a
string, integer, record, array, etc is NOT garbage collection. Those
types are specifically managed when the compiler inserts code at compile
time to allocate/deallocate the required memory.
Garbage collection is a runtime process that happens at some
non-specific interval, managed by the framework in which your
application is dependent, whereby it trolls the memory space of your
application, eats up cpu cycles, looks for abandoned (thrown away, ie.
"garbage") memory structures and makes a determination on whether to
return that memory to the heap. It's inefficient, it slow, and its
unacceptable.
The Delphi compiler is smart enough to know that when you destroy a
parent object it should insert code in your program to destroy all its
children, if they still exist, and return the memory they occupy to the
heap. However, this isn't garbage collection as defined by the
"enlightenend" languages, but a compiler generated code specific to the
application running.
>
> You said that developers are aware of leaking.Yes, but theres no ANY tools
> for that ,except commercial or recently, fastmm4.
> Memory leaking should be there, becase, when you create class, you'll
> optimize its methods, not destroying or creating.
>
Huh? Not sure what you mean by this last sentence. If you create an
object, you can destroy an object. When destroyed, all the memory
allocated to it's properties, methods, vars, etc. are returned to the heap.
The best tools for finding memory leaks are your eyes, your brain, good
coding practice and a well defined software engineering process.
I don't define my software engineering process by Pascal. I've worked in
many programming languages over the last 31 years and the same software
engineering process works for all of them. A computer language is merely
a tool, nothing more. I happen to believe that Delphi for Win32 is the
best tool around for Windows development.
Mark
Craig Stuntz [TeamB]
> Probably less than developpers that are aware that with a GC,
> destructor calls have to be replaced by strict nil'ing of references,
> and that those nil'ings have to be protected by try...finally and
> similar patterns just like destructor calls are.
Only if you scope them wrong. I think you're actually talking about
disposing, which generally does need to be done in a try/finally, but
that's entirely different from nilling references.
Failing to dispose in a try/finally has the consequence that the
referenced classes will take an extra generation to finalize. That's
not fatal, but it's less than idea.
Bad scope is not good in any form of memory management.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com
Rudy Velthuis [TeamB]
> > I've seen that mentioned often, but I have never ever seen any
> > evidence of that. Oh, I'm sure someone could create or point to an
> > inenfficient garbage collector and then show me how inefficient or
> > bloated it is, but a good modern garbage collector is not.
>
> I did, lot of times, and you can just read .NET and Java Newsgroups to
> see people that uses, complaining about that.
I have no idea what these people have been doing, so I have no idea how
valid such complaints are. I am reading some C# and .NET newsgroups,
since a few weeks, but haven't encountered such complaints yet. I don't
read Java groups.
> well, you dont need go so far, go to oodesign and you will see people
> finding a way to avoid the CG in .NET
Really? I must have missed that. I do know that people will, often
irrationally, try to avoid something they *perceive* as evil.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Yes, I'm fat, but you're ugly and I can go on a diet."
-- bumper sticker
Rudy Velthuis [TeamB]
> > I also notice that hardly anyone ever complained about the fact
> > that in Delphi, strings or dynamic arrays are more or less garbage
> > collected. <g>
>
> However, those are value types.
Huh? They are reference types. Hence the *reference* counts. <g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Inanimate objects can be classified scientifically into three
major categories; those that don't work, those that break down
and those that get lost." -- Russell Baker.
Eric Grange
FWIW, a non-deterministic GC falls under the "premature optimization"
category in my book, ie. being non-deterministic brings only performance
benefits to the table, but those benefits happen only in specific
situations, and they come at a price.
Eric
Rudy Velthuis [TeamB]
> Code included by the compiler to allocate/deallocate memory for a
> string, integer, record, array, etc is NOT garbage collection. Those
> types are specifically managed when the compiler inserts code at
> compile time to allocate/deallocate the required memory.
That is a simple ("poor man's") form of deterministic garbage
collection alright.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"An effective way to deal with predators is to taste terrible."
Eric Grange
> most of them are not.
Probably less than developpers that are aware that with a GC, destructor
calls have to be replaced by strict nil'ing of references, and that
those nil'ings have to be protected by try...finally and similar
patterns just like destructor calls are.
Failure to properly dereference quickly leads to memory loss, and this
is a widespread issue amongst Java & .Net applications f.i.
Try running random .Net libraries in an environment where memory and
resources are limited, like a PocketPC, and you'll quickly realize how
poorly the typical developper understands GC-based memory management quirks.
Eric
Rudy Velthuis [TeamB]
> Probably less than developpers that are aware that with a GC,
> destructor calls have to be replaced by strict nil'ing of references,
> and that those nil'ings have to be protected by try...finally and
> similar patterns just like destructor calls are.
Huh? What are you talking about?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"I am become death, shatterer of worlds."
-- Robert J. Oppenheimer (1904-1967) (citing from the
Bhagavad Gita, after witnessing the world's first nuclear
explosion)
Rudy Velthuis [TeamB]
> > A non-deterministic GC behaviour
>
> FWIW, a non-deterministic GC falls under the "premature optimization"
> category in my book
GC is not meant to do optimization, it is about preventing one of the
most common errors in programming. Of course, a good GC should be fast
and inobtrusive, but I think that all library code should be optimized.
Deterministic GC is not necessarily faster or better, since it
generally collects immediately, instead of waiting for a better time.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"I invented the term Object-Oriented, and I can tell you I did
not have C++ in mind." -- Alan Kay
Eric Grange
You skipped two words, I explicitly wrote "non-deterministic GC"
The difference between a "deterministic GC" and a "non-deterministic GC"
is all about an attempt at premature optimization.
Eric
Eric Grange
Nope, they are implemented internally as reference types, but at the
language levels, they are treated as value types.
Being a value type means that if you code
A:=B
you get a copy of B in A than can be altered without altering B.
Being a reference type means that if you code
A:=B
then you get a copy of the reference, ie. altering A will alter B as
they are references to the same object.
Eric
Alexandre Machado
"Rudy Velthuis [TeamB]" wrote:
> Garbage collection relieves you of a whole class of errors, errors that
> are by far the most common errors made and often also very hard to
> debug. So garbage collection is, IMO, certainly something very
> beneficial.
I like automatic cars, but it is just because I know how to drive, and I
know how to change gears.
IMHO, GC is the victory of incompetence: "If we can't do it right, let's
invent something else!", or
"If our developers can't free the memory they have allocated, let's create a
garbage collector". Most developers I know today *LOVE* .NET or Java's GC,
and most of them in fact are "relieved" because they don't have to *THINK*
about memory, objects, (something else?) anymore....
But I can live with and even like GC just as I like automatic cars ;-)
Regards,
Alexandre C. Machado
Craig Stuntz [TeamB]
> Huh? What are you talking about?
See my post. I think Eric is confused.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Everything You Need to Know About InterBase Character Sets:
http://blogs.teamb.com/craigstuntz/articles/403.aspx
Bob Dawson
>
> I have no idea what these people have been doing,
As a participant, I'd have to say Cesar is misinterpreting the conversation
a bit.
bobD
Eric Grange
Letting the GC be able to recycle the memory of parts of a
collection/datastructure before the whole collection/datastructure
itself leaves the scope.
If you're only dealing with small collections/datastructures (relatively
to available memory) that's not an issue, but whenever that's not the
case, that's IME the #1 source of memory usage "bloat" in your typical
.Net/Java apps, leading to "spikes" in memory usage until the whole
processing has completed.
F.i. one recently encountered situation, if you have something like
{
list = new ListOfSomething()
for all item in list
item.DoSomeStuff()
}
where DoSomeStuff() involves allocation of memory referred in item (such
as data being pulled from a DB, work structures, etc.), said memory
won't be recoverable until the for loop has ended, unless the loop is
changed to include nil'ing:
list[index].DoSomeStuff()
list[index] = nil;
which would be a list[index].free in a non-GC world.
Of course that can be a little more involved to solve if instead of a
list, you actually get an iterator that maintains the list internally...
Eric
Craig Stuntz [TeamB]
> where DoSomeStuff() involves allocation of memory referred in item
> (such as data being pulled from a DB, work structures, etc.), said
> memory won't be recoverable until the for loop has ended,
IOW: It turns out that using the wrong data structure for the problem
at hand is a problem no matter what kind of memory management you use.
Fancy that.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it's good: http://tinyurl.com/7hgfr
Mark A. Andrews
Good example. Say some programmer with a limited data set and a
non-deterministic garbage collector has to iterate through this 10 times
during testing. No problem, the ndgc works fine. But when you put that
same situation in the real world where you might have to iterate through
50,000 items, periodically the user is going to curse the computer when
he can't move the mouse because some background garbage collection
process steals his cpu while managing all this memory that has been
abandoned.
I anticipate that some of you will come back and say "Well then he
should just go ahead and deallocate the memory manually in the
process.." to which I will reply "Then what's the point of having a
non-deterministic garbage collector?"
I repeat, good coding practice and a good, well-defined software
engineering process is the best garbage collector.
Mark
Mark A. Andrews
>
> That is a simple ("poor man's") form of deterministic garbage
> collection alright.
Call it what you will, but it doesn't have the performance hit that
non-deterministic gc has in languages such as Java and the .net ilk (and
to some extent Classic VB).
The best garbage collector is the one that sits between your ears.
Mark
Cesar Romero
Maybe I was not so clear in my comments, but that do not means that CG
will be the wonderful world, and do not bring others disign issues,
people complain often about VCL Interface RefCount, I really appreciate
the way it works, but I have sometimes to deal in some issues and
resolve them, the same will be in CG, and in your threads the comments
shows that somethimes is necessary to deals with the time life of the
objects and do not let CG do the work.
I do prefer control the time live of my objects and have the control of
what is happening, but that is the nature of my work, is the way that I
like to do my job.
I appreciate all you comments about the experiences you guys have, and
after read all, Im happy to keep the way I do, and by while not leat to
CG manage that.
--
[]s
Cesar Romero
Rudy Velthuis [TeamB]
> F.i. one recently encountered situation, if you have something like
>
> {
> list = new ListOfSomething()
> for all item in list
> item.DoSomeStuff()
> }
>
> where DoSomeStuff() involves allocation of memory referred in item
> (such as data being pulled from a DB, work structures, etc.), said
> memory won't be recoverable until the for loop has ended
Why not? On the next iteration, item won't reference that list entry
anymore, so the extra memory used by it is free to be collected.
Anyway, like Craig said, you seem to be confusing
dispising/closing/releasing non-memory resources with garbage
collection.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"The de facto role of the US armed forces will be to keep the
world safe for our economy and open to our cultural assault."
-- Major Ralph Peters, US Military
Rudy Velthuis [TeamB]
> F.i. one recently encountered situation, if you have something like
>
> {
> list = new ListOfSomething()
> for all item in list
> item.DoSomeStuff()
> }
>
> where DoSomeStuff() involves allocation of memory referred in item
> (such as data being pulled from a DB, work structures, etc.), said
> memory won't be recoverable until the for loop has ended
The above doesn't make sense. List is empty, I assume.
So, I assume you also added items to the list. Then they won't be
collected until they are removed from the list. This has NOTHING to do
with the loop at all.
But say, in the loop, in DoSomeStuff, you allocate extra memory,
referenced locally in that routine. Immediately after DoSomeStuff ends,
the extra memory is up for grabs again. There is NO NEED to set
anything to nil.
Of course, you should not make that memory reference a member of the
class, but hey, that would be bad design anyway. GC doesn't prevent bad
design, unfortunately.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Quote me as saying I was mis-quoted."
-- Groucho Marx
Rudy Velthuis [TeamB]
> > Huh? What are you talking about?
>
> Letting the GC be able to recycle the memory of parts of a
> collection/datastructure before the whole collection/datastructure
> itself leaves the scope.
That should be impossible, if the data structure is referencing these
parts. Could you give an example?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Don't stay in bed, unless you can make money in bed."
-- George Burns (1896-1996)
Rudy Velthuis [TeamB]
>
> "Rudy Velthuis [TeamB]" wrote:
>
> > Garbage collection relieves you of a whole class of errors, errors
> > that are by far the most common errors made and often also very
> > hard to debug. So garbage collection is, IMO, certainly something
> > very beneficial.
>
> I like automatic cars, but it is just because I know how to drive,
> and I know how to change gears.
Huh? My mother never learned how to change a gear and she was a good
driver. She just always drove automatics.
But you should not see GC as something that makes you lazy (like
auto-shift does), it is designed to be something that helps you take
care of a host of possible errors: memory and pointer errors.
Oh wait, REAL programmers probably don't make such errors anyway, right?
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Men have become the tools of their tools."
-- Henry David Thoreau (1817-1862)
Rudy Velthuis [TeamB]
> Maybe I was not so clear in my comments, but that do not means that CG
> will be the wonderful world
Of course not. It won't cure cancer either.
See it like another means to add some safety to your programs. Unless
you do extremely weird things (things you should not, IMO, do anyway,
unless you REALLY REALLY know what you are doing and are sure to be
able to maintain it for a long time), GC removes a whole class of
possible errors. It does not relieve you from thinking.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"If you need more than five lines to prove something, then you
are on the wrong track"
-- Edgser W. Dijkstra's mother [ibid, p. 55]
Alexandre Machado
> Oh wait, REAL programmers probably don't make such errors anyway, right?
Well, I don't know. I do not consider myself a REAL programmer nor better
than any other programmer in the world. I don't care about doing some *cool*
coding...
But I DO have 14 years experience in (team) programming and I DO know about
LAZY programmers. I do know about things that improve software quality and
productivity, and about other things that are make some programmers even
lazier, just like GC.
Regards,
Alexandre C. Machado
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
>
> >
> > That is a simple ("poor man's") form of deterministic garbage
> > collection alright.
>
> Call it what you will, but it doesn't have the performance hit that
> non-deterministic gc has in languages such as Java and the .net ilk
I must say I have never encountered such a performance hit (I don't do
Java, only .NET). Can you give an example?
I think the fact that a deterministic deallocation is performed on the
spot, and that deterministic allocation and deallocation usually
involve searching and updating free lists, etc., IOW, are often pretty
complex, it may not be a good idea to do this in a tight loop either.
And outside tight loops, I doubt you'll ever notice the difference.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Hell is a half-filled auditorium." -- Robert Frost (1874-1963)
Rudy Velthuis [TeamB]
> > Bad programmers won't get better with a GC. But they won't be better
> > without one either. Sure is that without a GC, they are bound to
> > cause many more memory and pointer errors. <g>
>
> Sure. What I tell to my big boss is: If a programmer doesn't know how
> or when deallocate memory, try another programmer, not another
> development tool. ;-)
I'm not so sure a boss will buy that in a decade from now.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"We all agree that your theory is crazy, but is it crazy enough?"
-- Niels Bohr (1885-1962)
Craig Stuntz [TeamB]
> Why not? On the next iteration, item won't reference that list entry
> anymore, so the extra memory used by it is free to be collected.
No, it will, in this highly contrived situation. Of course, it would
with or without GC. The code example given is a bit pathological --
it's an example of how someone determined to do something incorrectly
can do so no matter what constraints are set in place to try and
prevent it.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: http://learningtowhistle.blogspot.com
Rudy Velthuis [TeamB]
> But I DO have 14 years experience in
> (team) programming and I DO know about LAZY programmers.
Bad programmers won't get better with a GC. But they won't be better
without one either. Sure is that without a GC, they are bound to cause
many more memory and pointer errors. <g>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Deliver yesterday, code today, think tomorrow." -- unknown
Rudy Velthuis [TeamB]
> > Huh? They are reference types. Hence the reference counts. <g>
>
> Nope, they are implemented internally as reference types, but at the
> language levels, they are treated as value types.
This is certainly not true for dynamic arrays. If, say, dynA and dynB
are dynamic array variables of the same type, then assigning dynB to
dynA will NOT copy the payload, only the pointers, so now, both point
to the SAME array. This is what defines a reference type.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"To sit alone with my conscience will be judgment enough for me."
-- Charles William Stubbs
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
>
> > Why not? On the next iteration, item won't reference that list entry
> > anymore, so the extra memory used by it is free to be collected.
>
> No, it will, in this highly contrived situation.
I'm not sure what exactly you mean, i.e. what will do what.
Oh, the list will of course reference the entry, but hey, that happens
without a loop as well, of course. I don't quite see what the example
is supposed to prove.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Life would be so much easier if we could just see the source
code." -- unknown
Rudy Velthuis [TeamB]
> You're haven't turned on GC derangement.
That is because the Delphi compiler has no switch for it. Time to QC
this? <eg>
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Everywhere I go I'm asked if I think the university stifles
writers. My opinion is that they don't stifle enough of them."
-- Flannery O'Connor (1925-1964)
Craig Stuntz [TeamB]
> I'm not sure what exactly you mean, i.e. what will do what.
>
> Oh, the list will of course reference the entry, but hey, that happens
> without a loop as well, of course. I don't quite see what the example
> is supposed to prove.
You're haven't turned on GC derangement. One who is completely
determined to dislike GC no matter what the facts might contrive
something like this:
procedure TMyListItem.DoSomething;
begin
FSomeField := TReallyBigInstance.Create;
FSomeField.DoSomething;
end;
destructor TMyListItem.Destroy;
begin
FSomeField.Free;
inherited;
end;
This is pathological code (the allocation/free should be symmetrical,
but they aren't here, and lazy instantiation is entirely inappropriate
for this problem as described), but it would result in the behavior
Eric describes, with or without GC.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Rudy Velthuis [TeamB]
> > GC is not meant to do optimization,
>
> You skipped two words, I explicitly wrote "non-deterministic GC"
I don't quite see how the fact that it is non-determistic is relevant.
Of course, one hopes that system/runtime library routines are optimized
as much as they can be. This is why FastMM and the FastCode routines
are used in Delphi's RTL for Win32, and FastCode is still busy
optimizing others.
That is not premature optimization, IMO. System routines should be
optimized, and so should the GC. After all, such optimizations don't
waste your time, like true premature optimization often does.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Democracy does not guarantee equality of conditions - it only
guarantees equality of opportunity." -- Irving Kristol
Alexandre Machado
> without one either. Sure is that without a GC, they are bound to cause
> many more memory and pointer errors. <g>
Sure. What I tell to my big boss is: If a programmer doesn't know how or
when deallocate memory, try another programmer, not another development
tool. ;-)
Regards,
Alexandre C. Machado
Craig Stuntz [TeamB]
> Sure. What I tell to my big boss is: If a programmer doesn't know how
> or when deallocate memory, try another programmer, not another
> development tool. ;-)
You are thinking in a very closed box there. How would you implement
something like LINQ without GC? You wouldn't, because in a GC-less
world you don't go there. So as long as you constrain your thinking to
the sort of problems which are easily solveable with a certain method
of memory management, you won't see the need for any other method.
Most DB servers run (a form of) garbage collection, for example,
because it's well-suited for lazy evaluation, and SQL is all about lazy
evaluation.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
>
> > I'm not sure what exactly you mean, i.e. what will do what.
> >
> > Oh, the list will of course reference the entry, but hey, that
> > happens without a loop as well, of course. I don't quite see what
> > the example is supposed to prove.
>
> You're haven't turned on GC derangement. One who is completely
> determined to dislike GC no matter what the facts might contrive
> something like this:
>
> procedure TMyListItem.DoSomething;
> begin
> FSomeField := TReallyBigInstance.Create;
> FSomeField.DoSomething;
> end;
>
> destructor TMyListItem.Destroy;
> begin
> FSomeField.Free;
> inherited;
> end;
>
> This is pathological code (the allocation/free should be symmetrical,
> but they aren't here, and lazy instantiation is entirely inappropriate
> for this problem as described), but it would result in the behavior
> Eric describes, with or without GC.
Ah, I addressed that in one of my other posts. In this case, it should
not be a field (unless you really needed it, later on, but then it
should not be collected anyway), it should be a local variable:
procedure TMyListItem.DoSomething;
var
Big: TReallyBigInstance;
begin
Big := TReallBigInstance.Create;
try
Big.DoSomething;
finally
Big.Free;
end;
end;
I guess that most C# advocates would actually do something like:
procedure TMyListItem.DoSomething;
var
Big: TReallyBigInstance;
begin
Big := TReallBigInstance.Create;
Big.DoSomething;
end;
In that case, there would be no need for a try-finally, nor for a call
to Free or to setting something to nil or some such.
But like you say, this is true for deterministic deallocation using
Free as well.
I still can't think of a real world application where this would be
done. If the items are stored in the list, I assume they are supposed
to stay there for a while. Otherwise, they can just as well be
allocated and deallocated in the loop, thus entirely removing the need
for a list.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Three o'clock is always too late or too early for anything you
want to do." -- Jean-Paul Sartre (1905-1980)
Remy Lebeau (TeamB)
"Sanyin" <prevo...@hotmail.com> wrote in message
news:478e0615$1...@newsgroups.borland.com...
> They could at least provide us with some MM that helps,
> instead of few words in manuals, etc
They already have. FastMM has already been incorporated as the new memory
manager, and it has leak detection and reporting capabilities.
Gambit
Remy Lebeau (TeamB)
> It is very sad that delphi odesn't have an garbage collector.
It doesn't need one.
> Image how many delphi developers are not aware of memory
> leaking. I think most of them are not.
Most Delphi users are plenty aware. They may not always be good at managing
memory, but that usually occurs when they do things like passing memory
between threads, or separate memory operations across multiple
functions/modules and lose track of what owns what.
> I didn't know few years ago that c++ has it.
No, C++ does not have any kind of garbage collector.
> Why not to implement that?
Why need to implement it?
Gambit
Remy Lebeau (TeamB)
> Delphi has GC, for arrays, strings, records.
> So it has 3/4 of it :)
Garbage collection is when freed memory is marked as unused but remains
allocated so it can't be reused right away, and then a separate background
collector process goes through at frequent intervals returning marked memory
back to the system for later reallocation. That is not how Delphi manages
its memory in Win32. Freed memory is available for immediate reuse. There
is no marking involved. There is no background collector running. Records
and static arrays that are not dynamically allocated reside on the stack and
are "freed" when the stack is cleared. Strings and DynamicArrays are
reference counted and freed immediately when all references to them are
gone. None of that is related to garbage collection.
Gambit
David Clegg
> Failing to dispose in a try/finally has the consequence that the
> referenced classes will take an extra generation to finalize. That's
> not fatal
That depends on the CLR implementation :-)
I had a bug a while back in a Compact Framework application
which illustrates this point nicely.
Because forms on the CF always take up the entire screen, we had
'faked' an edit dialog by displaying a panel to simulate a modal form.
A customer reported to us that the time it took the application to
respond after clicking the 'OK' button to close the dialog was slowly
increasing. The increase was such that after a weeks of continuous
usage, it took 10 minutes for control to return back to the user.
We had originally suspected memory fragmentation due to SqlCE database
calls, as we'd run into memory problems in this area before (memory
leaks though, not fragmentation). But to our surprise, after much
profiling it was discovered that the problem was with a call to
Panel.Hide, and could be duplicated even when the Panel contained no
child controls.
The solution to the problem was a call to Panel.Dispose. IOW, leaving
the calling of IDisposable.Dispose for the Panel to the GC (as opposed
to explicitly calling it ourselves) was what caused the increasing
delay.
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.codegear.com/Author/72299
QualityCentral. The best way to bug CodeGear about bugs.
http://qc.codegear.com
"I didn't need that fact...now I forgot who won Bud Bowl 8." - Homer
Simpson
Craig Stuntz [TeamB]
fewer diagnostics....
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
Sean Cross
blog post on Delphi and GC (why and how to do it). It will be a
http://sourceitsoftware.blogspot.com/ once I finish it, probably later
today.
I haven't seen so much FUD since the last microsoft linux papers. There
seem to be a large number of delphi users (here at least) with strong
and mostly uninformed views. I get the feeling that many vocal Delphi
users haven't spent much time with other languages.
This debate has been had many times in the last few years. The result
is that nearly every recent language has GC. Even C++ is getting in on
the act.
"IMHO, GC is the victory of incompetence"
Really? I thought is was about writing less code, and writing better
code.
If you only view a gc as a way of getting rid of .free then you won't
get most of the benefits. And there are many benefits. It's not
perfect, and gc is not suited for many applications (memory constrained
devices come to mind) but for most apps it is an improvement..
Oh, if you want a gc for Delphi, look at
http://codecentral.codegear.com/Item/21646. I have made some minor
changes to this, and I will blog on them later.
Sean
---------------------------------------
Sean Cross
mailto:se...@sourceitsoftware.com
Pics Print - The photo printing solution for Windows.
http://www.picsprint.com
Rental Property Manager - Rental management made easy
http://www.sourceitsoftware.com
David Clegg
> CF is just about a topic unto itself. Little memory, few options,
> fewer diagnostics....
Indeed. Great place to gain the required discipline when moving to a GC
based world. :-)
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.codegear.com/Author/72299
QualityCentral. The best way to bug CodeGear about bugs.
http://qc.codegear.com
"I think Smithers picked me because of my motivational skills. Everyone
says they have to work a lot harder when I’m around." - Homer Simpson
Andre Kaufmann
> "Sanyin" <prevo...@hotmail.com> wrote in message
> news:478dcf28$1...@newsgroups.borland.com...
>
> No, C++ does not have any kind of garbage collector.
AFAIK it will have in the next C++0x standard.
And currently it has RAII, which I sometimes miss in Delphi.
>
Andre
Jolyon Smith
> It is very sad that delphi odesn't have an garbage collector.
The problem is far worse in .net where the garbage collection leads
people to think that they don't need to worry about memory management
when in fact the issues are arguably more complex and in some cases
harder to actually deal with.
With Delphi you learn that you have to manage memory, then you apply
that lesson.
--
JS
TWorld.Create.Free;
Jolyon Smith
> Sanyin wrote:
> > It is very sad that delphi odesn't have an garbage collector.
>
+1 for me
> Any Delphi developer who has written any program of any size in Delphi
> most certainly is aware of memory leaking.
+1 for me.
> Delphi is NOT C++. Delphi is NOT C#. Delphi is NOT Java. And thank God
> it isn't.
+10 for me!
> > Why not to implement that?
>
> Because it isn't needed.
+20!
> GC will never replace a good, well defined, software engineering
> process. Don't ever depend on the computer to pickup your dirty
> underwear. Grow up, be an adult and do it yourself!
+8
(apply a 90deg rotation transform to the second char in that)
:D
--
JS
TWorld.Create.Free;
Rudy Velthuis [TeamB]
> The best garbage collector is the one that sits between your ears.
Actually, no, on the contrary.
A GC, once programmed and tested properly, will not make mistakes or
forget things. It will not get tired or bored. The one between my ears
tends to get bored or tired, and to forget things like closing
parentheses, variable declarations, calls to Free, etc., occasionally.
Assuming you are human too, the same should be true for yours.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"Quote me as saying I was mis-quoted."
-- Groucho Marx
Craig
> > Image how many delphi developers are not aware of memory leaking.I think
> > most of them are not.
>
> most certainly is aware of memory leaking.
>
This is most certainly not the case. For the top 25 % of developers,
they are aware of memory issues and watch for them and fix them. The
middle 50 % really start to go blank when you start talking about such
things. I'm talking about the vast majority of developers that never
read tech newsgroups, go to conferences or even have a PC at home
which they use for anything more than writing a letter to their
mother. I have seen *many* companies where it is standard practice for
clients to be told they have to restart their servers every night.
Why? Because the software leaks like a drain and the developers have
no idea how to fix it. This is not the exception, this is normal.
Craig.
Rudy Velthuis [TeamB]
> The problem is far worse in .net where the garbage collection leads
> people to think that they don't need to worry about memory management
They generally don't have to worry about memory management. But they
should not forget the protection of all others resources.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"You can get more with a kind word and a gun than you can with a
kind word alone." -- Al Capone (1899-1947)
Sean Cross
So far I have seen comments about laziness and incompetence, spurious
analogies to automatic cars and a fair amount of 'I know how to free
memory (usually) therefore it must be a good thing', but nothing of any
substance.
You don't have to like garbage collectors, you don't have to use a
garbage collector (so long as you use delphi for the rest of your life)
but you should at least learn enough to have an informed opinion.
Nearly every recent programming language is garbage collected (I say
nearly, but I don't know of any recent language that isn't) so you will
probably need to use it sooner or later.
DS
> I have no idea what these people have been doing, so I have no idea how
> valid such complaints are. I am reading some C# and .NET newsgroups,
> since a few weeks, but haven't encountered such complaints yet. I don't
> read Java groups.
Well, I have pretty good idea.
I'm partly responsible for this SCADA-ish application, which collects
various data from TV and FM transmitters and some other stuff (UPS,
triggers, ...). It does this by reading values from various PLC/OPC
controllers, or via SNMP, or even HTML parsing [ :-( ] on various locations.
This data is then processed and sent to central location, where 'monitoring
system' with various visualizations runs.
Usually, there's not that much going on, but events tend to be cascading -
e.g. when power failure occurs, more or less everything goes haywire and
there is quite a surge of inputs to be processed. Which implies lots of
allocating and juggling of memory. This is usually the moment when GC kicks
in.
Trouble with (at least current) .net is, when GC collects, it efectivelly
'freezes' all other threads (and this aplication has /lots/ of them, mostly
those input readers). And then - in real time - data gets lost.
Now, there are strategies and semi-workarounds possible (and even using
server GC seems to somewhat help), but all in all - it's pain in the arse.
That being said, with some effort - it works. Now.
Otherwise, for application of this magnitude, I'd be probably still chasing
memory leaks.
At the end, there's no magic wand to solve the problems, it seems...
LP,
Dejan
DS
In some infinite wisdom, probably induced by smoking something illegal,
Microsoft decided in XP SP2 that 10 half-open connections is all you need
(if someone wonders, before SP2 it was 65k). This /supposedly/ helps with
protection against worms and such.
Well, what do you know - I have here perfectly good-willing application,
which must communicate with several /dozens/ of somewhat slow devices (8-bit
embedded microcontrollers, f.e.), so 10 is most definitely not enough...
Nevermind, I'll just adjust the setting in... (now, where could it be...)
- some GUI setting? nope,
- command line utility? nope,
- registry tweak? nope,
WTF?
...it turns out the only way to increase the limit is either:
a) install W2k3 server, or
b) binary patch the TCPIP.SYS system file.
Idiots.
</OT rant>
LP,
Dejan
Remy Lebeau (TeamB)
"Andre Kaufmann" <andre.kaufm...@t-online.de> wrote in message
news:478e66e4$1...@newsgroups.borland.com...
> AFAIK it will have in the next C++0x standard.
Ouch.
> And currently it has RAII, which I sometimes miss in Delphi.
RAII is not garbage collection, though. And with constructors and
destructors added to records in D2007, RAII techniques can now be done in
Delphi as well.
Gambit
Kostya
As long as it is optional/partial as in D language or an upcoming c++0x
there are no arguments from my side. But when it is mandatory
and introduces problems in some scenarios - I'd call it an
arm twister and it decreases value of tool/technology.
Sean Cross
> It is very sad that delphi odesn't have an garbage collector.
> most of them are not.
> that.
>
> Why not to implement that?
> course)..Any?
>
>
I have stuck a blog posting at http://sourceitsoftware.blogspot.com/
covering why and how to use a GC with delphi win 32.
Sean
---------------------------------------
Sean Cross
mailto:se...@sourceitsoftware.com
Pics Print - The photo printing solution for Windows.
http://www.picsprint.com
Rental Property Manager - Rental management made easy
http://www.sourceitsoftware.com
Sean Cross
I wouldn't want it mandatory either, but having it optional out of the
box, that I would go for.
Sean
---------------------------------------
Sean Cross
mailto:se...@sourceitsoftware.com
Pics Print - The photo printing solution for Windows.
http://www.picsprint.com
Rental Property Manager - Rental management made easy
http://www.sourceitsoftware.com
Jolyon Smith
> Can you guys come up with some real arguments against garbage collection?
A one-size fits all jacket will never fit as well as a tailored one.
The 2 (current) gc's of practical significance (Java and .NET) suffer
major flaws in heavily loaded, multi-threaded environments. In a CPU
bound/intensive case with significant amounts of memory use/churn,
situations where the GC eventually HAS to step in to recover memory
result in those highly paralleled processes grinding to a halt whilst
the GC does it's thing.
Given that the trend is toward parallel software and multi-core
processors, this is a significant potential issue.
The result being that your application may appear to be flying along at
a great pace until suddenly hitting a brick wall (at the point at which
the GC is forced to step in, halting everything else whilst it clears
things up).
In apps that spend most/a lot of their time idle, it's not a big deal
since the GC is unlikely to ever have to impose itself in this way.
Which I guess is one reason that GC's work quite well on things like web
servers etc, where a lot of time is spent twiddling electronic thumbs
between discrete client requests.
> Nearly every recent programming language is garbage collected (I say
> nearly, but I don't know of any recent language that isn't) so you will
> probably need to use it sooner or later.
The true test of course would be if/when any of those recent languages
become widely used for developing a wide variety of applications or
remain primarily specialist languages. And of course whether they are
still around in as many years time as all those fuddy-duddy old non-GC'd
languages that have stood the test of time (GC aint new, either as an
idea or an implementation - the spare CPU horses needed to make it
viable in a wider variety of apps are).
--
JS
TWorld.Create.Free;
Mark A. Andrews
> That being said, with some effort - it works. Now.
> Otherwise, for application of this magnitude, I'd be probably still
> chasing memory leaks.
>
The BIG difference here is that YOU can FIX the memory leaks. You have
very little control over the gc.
Mark
Lee Grissom
> Can you guys come up with some real arguments against garbage collection?
Memory leaking is still a problem in garbage collected environments.
The primary difference is that you won't see access violations as much,
but instead you'll run out of RAM. This is especially true with event
handlers and consumers that don't call Dispose. Our team has spent
several weeks in depth training on how to deal with memory leaks in
.NET, and the problems are very real, and much trickier to track down
than in Delphi. I wish I had the time to write up a detailed report
for the rest of the world to see that GC is not the silver bullet
solution for memory leaks. You just trade one set of problems for
another.
--
Lee
Mark A. Andrews
>>
>
> I have stuck a blog posting at http://sourceitsoftware.blogspot.com/
> covering why and how to use a GC with delphi win 32.
>
From now on, before quoting me in a blog post, please do me the
courtesy of asking my permission to do so.
Thanks,
Mark
Mark A. Andrews
>
> The true test of course would be if/when any of those recent languages
> become widely used for developing a wide variety of applications or
> remain primarily specialist languages. And of course whether they are
> still around in as many years time as all those fuddy-duddy old non-GC'd
> languages that have stood the test of time (GC aint new, either as an
> idea or an implementation - the spare CPU horses needed to make it
> viable in a wider variety of apps are).
>
Which takes me back to my long standing question that I've been asking
for nearly 10 years. I've had to modify it since the advent of .Net -
Name ONE major commercial/shareware/freeware application that is written
primarily using Java or .Net.
Just one, that's all I ask.
The only one that comes close is StarOffice/OpenOffice. When it finally
overtakes Office, I'll concede. :-)
And the argument of not having seen a recently introduced language that
doesn't include gc brings up images of lemmings all jumping off a cliff.
Mark
Sean Cross
I personally have never claimed that GC is a silver bullet or that it
solves memory leak problems. I have seen catastrophic memory leaks that
involved shutting down $5,000,000 machinery and 100s of staff standing
around while the pc restarts. The problem wasn't the gc, but programmer
error. GC certainly won't fix sloppy programming, and you can easily
get memory leaks.
I don't want a GC to stop memory leaks, I can do that by myself. I want
a gc so that I can write better code.
I also don't want mandatory GC. I just want the option.
Sean
---------------------------------------
Sean Cross
mailto:se...@sourceitsoftware.com
Pics Print - The photo printing solution for Windows.
http://www.picsprint.com
Rental Property Manager - Rental management made easy
http://www.sourceitsoftware.com
Jolyon Smith
> Jolyon Smith wrote:
> >
> > The true test of course would be if/when any of those recent languages
> > become widely used for developing a wide variety of applications or
> > remain primarily specialist languages. And of course whether they are
> > still around in as many years time as all those fuddy-duddy old non-GC'd
> > languages that have stood the test of time (GC aint new, either as an
> > idea or an implementation - the spare CPU horses needed to make it
> > viable in a wider variety of apps are).
> >
>
> Which takes me back to my long standing question that I've been asking
> for nearly 10 years. I've had to modify it since the advent of .Net -
>
> Name ONE major commercial/shareware/freeware application that is written
> primarily using Java or .Net.
I'm sure there will be one. The real test is if it will ever become the
norm. But point taken. :)
> And the argument of not having seen a recently introduced language that
> doesn't include gc brings up images of lemmings all jumping off a cliff.
Ah, sadly a myth. But again, point taken.
"...to boldly follow, where everyone has gone before"....
LOL
--
JS
TWorld.Create.Free;
Anders Isaksson
> Mark A. Andrews wrote:
>
> > Code included by the compiler to allocate/deallocate memory for a
> > string, integer, record, array, [...]
>
> That is a simple ("poor man's") form of deterministic garbage
> collection alright.
IMO that's not "garbage collection", it's "lifetime management", and
there's nothing "poor man's solution" about it. Deterministic lifetime
management is always better than non-deterministic (if it can be done),
as resources are locked as little as possible.
A GC that doesn't know anything about lifetimes, only pointers to
memory, and instead has to iterate through memory marking used
pointers, and once more collecting the 'unused' ones, keeping track of
different levels of 'unusedness', seems more of a "poor man's solution"
to me.
It's like reformatting your hard disk, reinstalling Windows and all
programs except one, instead of just deleting the single program.
--
Anders Isaksson, Sweden
BlockCAD: http://web.telia.com/~u16122508/proglego.htm
Gallery: http://web.telia.com/~u16122508/gallery/index.htm
Anders Isaksson
> The best garbage collector is the one that sits between your ears.
Unfortunately, this has proven untrue a long time ago. Experiments in
lisp has shown that humans are notoriously inadequate at determining
lifetime for objects. A well constructed GC is much easier to prove
correct.
Ref: "Anatomy of Lisp", McGraw-Hill 1978. Author John Allen. I just
googled it, it seems I should take good care of my old book, it might
be an investment for the future :-)
http://portal.acm.org/citation.cfm?id=542865
Sanyin
"Remy Lebeau (TeamB)" <no....@no.spam.com> wrote in message
news:478e...@newsgroups.borland.com...> news:478e0c5b$1...@newsgroups.borland.com...
>
>> Delphi has GC, for arrays, strings, records.
>> So it has 3/4 of it :)
>
> Garbage collection is when freed memory is marked as unused but remains
> allocated so it can't be reused right away, and then a separate background
> collector process goes through at frequent intervals returning marked
> memory back to the system for later reallocation. That is not how Delphi
> manages its memory in Win32. Freed memory is available for immediate
> reuse. There is no marking involved. There is no background collector
> running. Records and static arrays that are not dynamically allocated
> reside on the stack and are "freed" when the stack is cleared. Strings
> and DynamicArrays are reference counted and freed immediately when all
> references to them are gone. None of that is related to garbage
> collection.
>
Yes, but at least, lifetime management of classes is more than needed.If
exists for arrays and records, than why not for classes.Most memory leaking
is from classes, and you can always use pointer and manual allocating...
Anders Isaksson
> Eric Grange wrote:
>
> > FWIW, a non-deterministic GC falls under the "premature
> > optimization" category in my book
>
> GC is not meant to do optimization, it is about preventing one of the
> most common errors in programming.
IMO, you're wrong here. The rationale for a GC is the fact that a
resource (memory) needs to be used in an 'optimized' way.
The really simple (and fast) solution that doesn't introduce any
pointer problems at all is to *never* re-use memory, just allocate
more. This only works if we have unlimited amounts of memory (and
address space) available.
As we know this doesn't work, we have to introduce re-use, either by
explicit lifetime management (stacks, refcounts, etc.), or by implicit
(GC). Either way, it's an optimization of memory use.
I don't think "preventing one of the most common errors in programming"
was high up on the agenda when GC:s were introduced. Memory
optimization was.
Eric Grange
Then I guess it's not the only thing you don't quite see about GCs ;)
Eric
Eric Grange
???
Sorry but none of what you wrote made any sense to me.
Eric
Eric Grange
> done. [...]
uh... have you ever looked at the VCL?
Practically every component does things like that ie. allocate
datastructures, generate/download/compute data, and offer processing or
evaluation methods on said data, even if said data is oftimes just a
string, array or record, the pattern is quite ubiquitous.
As for the difference a GC makes, well not being able to "free" objects
after used them, means you must dereference them if you want the them
freed (at some point, by the GC)... which was my original point in case
you forgot.
Eric
Jan Derk
> Name ONE major commercial/shareware/freeware application that is written
> primarily using Java or .Net.
>
> Just one, that's all I ask.
>
> The only one that comes close is StarOffice/OpenOffice. When it finally
> overtakes Office, I'll concede. :-)
OpenOffice is written in C++.
Jan Derk
Caleb Hattingh
> I don't want a GC to stop memory leaks, I can do that by myself. I want
> a gc so that I can write better code.
Hi Sean
Could you explain this point a little bit further?
Thanks
Caleb
Henrick Hellström
> "Delphi has GC, for arrays, strings, records.
> So it has 3/4 of it :)"
The memory for those types is released deterministically. Strings and
dynamic arrays are released by the means of reference counting. Records
and other value types are released when the declaration goes out of
scope (e.g. when the method returns if it was declared as a local
variable). None of them are, in a strict sense, garbage collected.
Rudy Velthuis [TeamB]
I'd rather see you tell me how it is relevant.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"People demand freedom of speech to make up for the freedom of
thought which they avoid."
-- Soren Aabye Kierkegaard (1813-1855)
Henrick Hellström
> Mark A. Andrews wrote:
>
>> The best garbage collector is the one that sits between your ears.
>
>
> A GC, once programmed and tested properly, will not make mistakes or
> forget things. It will not get tired or bored.
Actually, I don't believe that to be true. As long as the language
supports class vars and global vars, no garbage collector in the world
could possibly detect every single leaks introduced that way. How could
it possibly know whether the class var you have assigned is something
you really intend to use after a couple hours, or that you forgot to add
the timer that was supposed to dispose of it if not used within five
minutes?
Alexandre Machado
> of asking my permission to do so.
>
> Thanks,
>
> Mark
Same here!
Sean's blog post was at least unelegant. Take my words out of context to
prove yourself right is not the right thing to do.
Regards,
Alexandre Machado
Rudy Velthuis [TeamB]
The big difference is that he can also program for a non-determinisitic
GC, by thinking what an allocation means. Re-using allocations,
object-pools, etc. can relieve both kinds of code from memory concerns.
If memory issues are a problem, deterministic (in this case, determined
by the programmer) deallocation can also cost a lot of time, and cause
the same problems as he is describing.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"The wit makes fun of other persons; the satirist makes fun of
the world; the humorist makes fun of himself."
-- James Thurber (1894-1961),
in Edward R. Murrow television interview