Re: Speeding up GC

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20020604165254.A697@wotan.suse.de> you write:
>> This is kind of the "next level" of what I was proposing.  Once you
>> have this "enter short-term mode" thing, you can have the "exit
>> short-term" call just reset the state of all the temporary GC pools as
>> if GC has been run on them and no references had been found.
>
>Just doesn't this bring all the bugs back that got fixed by the GC introduction?
>

Yes and no.

The bugs may be back, but their consequences are entirely different.
See, the obstack stuff was buggy, because you had to track down memory
usage to ensure you weren't using a dereferenced address, and that was
pervasive to the whole compiler.

Now, you still have the GC to take care of all icky parts. And you can
probably design the pooling stuff so that it just degrades performance if
you have a liveliness bug---not crash outright.

Plus, there are definitely parts of the compiler where local allocation is
reasonably obvious.

One issue that comes to mind, though, is that, as far as possible, the
interface should be designed so that you can fall back down to the `normal'
gc, and have checks the whole way (e.g., that temporary arenas are indeed
dead when they get freed). In the event you run into a bug, it becomes much
easier to track down, because the memory infrastructure more or less makes
the bug trivial.

Am I making sense ?