Re: [HACKERS] Its not my fault. Its SEG's FAULT! - Mailing list pgsql-hackers

>
>It is surprising, but this simple fact has not yet penetrated into
>popular thought. I have seen large organizations full of very bright
>people spend hundreds of man years chasing leaks without ever wondering
>if there might be an alternative.
>For some reason people cling to the belief ithat if they were just careful
>enough and only let really good programmers touch the code and carried
>a lucky rabbits foot that somehow they could write leak free software.
>


David, you state this is a fact. Ok I am willing to accept that as a fact if
you
can provide "real world applications" which use GC's which
get the job done more efficiently that a comparable system without the
GC.
Please David, not just assertions facts. And I don't consider statements
like "proferssor X says so" to be a factual.

Yes I am aware of "academic experiments" where some claim
that GC's are actually good _general_ purpose solutions. But
everytime I've taken the time to dig into this (and I have taken the time)
it turns out that they seem to massage the results based on (what seems to
be)
some pro GC bias.

And after my personal search I have concluded that GC's are based on
a bad principle. Thisis the principle as I have identified it.

"Pospone until you can pospone no longer".

IMO this principle is not a good principle in _general_.

Again I will state that a GC does not solve any _general_ problem.

1. Can you identify the fundamental difference between allocating/freeing
memory
and opening/closing files?

2. Have you also been reading those so called "optimisation hints" for
Java programs that Sun sends around to Java developers?

3. Have you noticed  that these "hints" are supposted to help the GC
implementation not make a fool of it's self?

4. Have you noticed that the finalize method in Java in useless in general
because you never know if it  will be called?
So if you put any code in it, the code is quite useless, because
maybe it wont be called. (I'm sorry I'm getting to Java specific).

5. Isn't it true that a GC's performance is a function of the number of
active objects in the runtime system?
So adding some new subsystem actually in _general_ decreases
your systems performance (larger memory footprint) _and_ your GC's
performance?
(Assuming the subsystem also uses the GC).

6. Are algorithms to detected circular references? O(n) or event worse?
Last time I checked they where not linear time. I'm certain you
can envision a graph for which it would take some effort on the part of the
GC to determine if a node is freeable.

And sure, I too am able to think up some cases in which this will not be
true.
But in the _general_ case it will, because the GC's performance _is_
a function of the number of objects to be collected. No amount of
prayer is going to change that.

I'm sorry but as far as I am concerned these are facts. Please
supply me with some facts about the merits of these GC's.
I'd also prefer you don't refer me to some researcher who is
obviously biased because he probably spent a few years of his life
researching a lost case.

I prefer you give me results comparing similar systems implemented
with and without GC's.

I have yet to see any "non cosmetic" case where the GC systems wins
in _general_. Many poeple can massage the input of a system
as to show the "merit" of their pet algorithm but it doesn't change the fact
that the _principle_ GC's are based on is a poor one.
If it were not so, GC's would solve general problems (including situations
like opening and closing files.) )Yes those researchers recognize this as
well.)

Isn't it true that good principles are applicable to the general case?
If this is so then GC's just don't pull it.
But maybe you can design a GC based on some better principle?
I certainly would use it if it would prove to work better in general.

>All this in the face of the observation that no-one ever actually _writes_
>leak free software. Personally, I don't know anyone who can write leak
>free software of any size, certainly not in a finite time.
>
Yes, we make mistakes. I make mistakes too. But I am certain that some
of the subsystems I've written are leak free. And I am certain some of them
are not. I just don't know which ones are and which ones are not.

I know you are not trying to say that using GC's will insure that no
programming
error are made. So I'll conclude that with or without GC's we will have
will have errors in our systems.
The challenge/solution is then to design systems which work inspite of the
fact
that we make mistakes.

This leads to _general_ techniques such as using (precondition and
postconditions)
to help us cope with the fact that we are not perfect.

There is a good principle. It works all the time, in any situation
(considering the
context of our discussion.)

Ok, I'll stop now.

Please understand that I have no personal grudge against anyone.

With regards from Maurice.