This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gc and alloca()


Aleksey Demakov <avd@gcom.ru> writes:

> Christian Lynbech <chl@tbit.dk> writes:
> 
> > >>>>> "Greg" == Greg Harvey <Greg.Harvey@thezone.net> writes:
> > 
> > Greg> ... also referenced by other stack variables; it shouldn't be a
> > Greg> problem, but it also doesn't fill me with confidence.
> > 
> > Exactly our feelings. 
> > 
> > Moreover, a colleague also pointed that it may be even worse. The
> > portable alloca implementation expects to be called frequently
> > (perhaps just as alloca(0)) in order to be able to clean up. As I
> > understand it, it examines stack pointers to see if some of the alloca
> > frames need to be freed,
> 
> I think this entire problem is not that hard to solve. AFAIK, portable
> alloca maintains internal list of all allocated memory blocks. If we make
> the garbage collector checking this blocks as if they were on the stack
> then all will be ok. The gc should also check whether this blocks are
> "above" or "below" the top of the stack. It might clean up allocated
> memory itself or just call alloca(0).

It would be easier, if you're going to end up mallocing the memory
anyway, to create a new scheme type for the thing you want to alloca
(if it contains scheme objects... if it doesn't, you don't have to
care, so alloca like mad), and let the gc clean things up for you;
that's it's job, after all. Adding the special case code to handle the
portable alloca in the gc, for the benefit of one place in the code,
seems to me like a lot of wasted work to get the same behaviour. Now,
what's really needed is to have the smob space increased, so you don't
have to worry about exhausting smobs while doing this (is anybody
currently working on this? I seem to recall this was supposed to be a
Real Soon Now(tm) thing after the 1.3 release).
 
> >                           but will this work with a multithreaded
> > application which has several stack spread out across the memory?
> 
> Hmm... Does guile work this way? I mean, can gc currently handle
> multiple stacks?

Yep. It marks the stack of each thread during a gc when you're using
threads (see scm_igc), so that shouldn't be a problem (though the
alloca is, it's not because the gc doesn't know about the stacks).

-- 
Greg