Re: Re: Re: my garbage collector sucks

Mark Hahn wrote:

> Paul Prescod wrote:
> 
>>It is probably not a deciding factor, but if you put performance
>>aside, reference counted languages can make guarantees about object
>>finalization that m&s garbage collected languages cannot.
> 
> 
> It turns out that is a myth.  As an outcome of the turing halt theorem, you
> cannot predict when and on which instruction the count will go to zero for
> different program inputs.


The Halting Problem only applies to *computer programs* trying to 
predict the behaviour of other *computer programs*. I am talking about a 
human being trying to predict the behaviour of a computer program. 
Anyhow, this is blindingly obvious if you write the following Python 
program:

for i in range(0, 10000):
	file = open(str(i)+".txt", "w").write("Hello world")

Maybe there is no *computer program* that can see that this would have 
different behaviour in Python versus Jython/Java but I can see it with 
my own two eyes. In Jython it will open somewhere between 1 and 10000 
files simultaneously and in Python there will never be more than two 
files open at a time.

 >...
> The reason Java and .NET are using tracing has to do with control.  You
> cannot change the ref counting algorithm and behavior.  With tracing you can
> fine tune the algorithm.  Ref counting has a problem with cascading deletes.
> One ref count going to zero can cause an arbitrarily large number of objects
> to need to be deleted and cause an arbitraily long pause to the system.

Right: reference counting gives the programmer more control by giving 
them a predictable guarantee of when things will be finalized. With 
garbage collection the language designer says: "I won't give you any 
guarantees and then I'll have complete control of tuning and algorithm."

That's great for the implementer and maybe it results in faster code for 
the programmer, but it is a net loss of control and predictability.

  Paul Prescod