Re: alloca and GC

[Michael Livshin]

[ moved to *-devel ]

Dirk Herrmann <address@hidden> writes:

> On 30 Jan 2001, Michael Livshin wrote:
> 
> > Keisuke: you already have two versions of your VM, one GCC-specific
> > and the other generic ANSI C, right?  no problem then, let those
> > non-gcc using folks suffer. ;)
> 
> Actually, I rather think that even if alloca was available, that it is
> questionable whether it should be used, following the argumentation that
> was posted to this list before by others:  The stack has to be
> conservatively scanned, i. e. alloca-ting large regions on the stack for
> bytecode increases the amount of memory that has always to be scanned,
> independent of how clever a potential generational garbage collection
> might be implemented.

that's right, assuming we don't change the GC to deal with bytecode
stacks intelligently.  which is possible to do, I believe.  you just
need to somehow "mark" the beginning and the end of the stack regions
where the bytecode is executing.

the GC is not this stupid unchangeable thing, it can and should be
made to cooperate with the evaluator in every possible way.

this assumes, of course, that the layout of the bytecode-executing
stack is well-defined and predictable.  I don't see why not.

> Maybe I missed some point in the beginning of the discussion, but what
> is the major benefit of using alloca in contrast to an ordinary
> malloc in this particular case?  Doesn't bytecode have to be stored on the
> heap anyway, belonging to some function object?

so you can `alloca' enough space on the current stack frame for all
the locals.  you get the number of locals from the (compiled)
applicable object (closure, smob, ...) that you are about to execute.
but I didn't look at Keisuke's code yet.

-- 
Computer Science is embarrassed by the computer.
                -- Alan Perlis