Re: [patch] Move loop structures to gc memory

[Michael Matz <matz at suse dot de>]

Hi,

On Fri, 18 May 2007, Alexandre Oliva wrote:

> >> Why is it not suitable?
> 
> > Because it's garbage collected memory for something that doesn't need
> > to, care about, or will ever be, garbage collected?
> 
> > the memory doesn't need to be garbage collected, it just has some
> > roots in it.
> 
> Do you not realize the contradiction between your two statements
> above?

There is none, as "unsuitable" != "impossible".

> It evidently cares about garbage collection, because it points to 
> GC-able objects.

Unsuitable is no absolute term, which means there are multiple 
interpretation of what is and what is not unsuitable.  It also means that 
you can't dispute the claim of someone finding something unsuitable.  At 
best something like a majority feeling can be obtained.

> > Why should things that don't need to be garbage collected, be in 
> > garbage collected memory?
> 
> They don't have to.  But they can.  It's the logical nonsequitur that
> "GC is unsuitable" that I'm disputing.

But just because they can doesn't mean that "GC is suitable".  It's the 
logical nonsequitur that most are disputing :-)

> But I do take issue with the general claim that GC memory in general is 
> unsuitable for this, or any, purpose.

I'm not sure if anyone here claimed that GC is unsuitable in general for 
any purpose.

> >> If we could make ggc_alloc faster, would it still be unsuitable?
> 
> This was the critial question.  And, in spite of all of your
> reasoning, it was left unanswered.

The answer to that question is "yes".  That reflects my opinion about what 
influences suitability, and what doesn't.  IMHO suitability of 
feature X depends on the most "important" sub-features of X, and if those 
sub-features indeed are necessary.  For GC the most important feature is 
the ability to garbage collect, in order to deal with reclaiming memory 
for stuff whose life-time can't be known precisely.

So, if that ability inherently is not necessary for the implementation, 
then by that definition GC in unsuitable.

If GC also has other sub-features (fastness, inability to handle dynamic 
roots) doesn't matter, if those other sub-features are much less important 
than the most important ones.  IMHO they are, so even those don't make GC 
more suitable.  They might make using GC necessary (as in our very case 
because of the dynamic roots), so there's a mismatch between suitability 
and necessity, which normally are called QoI bugs.  As no matter what you 
do to GC, it still will stay GC (otherwise you've made a non-collecting 
allocator), you can't change the suitability of GC, hence you can only 
try to remove the necessity of GC to fix this QoI bug.  Even the fastest, 
best compacting, rule-the-world GC will still be unsuitable (because for 
one, you could remove the GC part of that allocator and would end up with 
something even faster and smaller, which would be more suitable).

Which is what Zdenek started to do.  Hooray :)


Ciao,
Michael.