guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latent bugs?


From: Lynn Winebarger
Subject: Re: Latent bugs?
Date: Sat, 28 Dec 2002 13:46:52 -0500

Redirected to guile-devel from bug-guile because this list gets read 
more often.

On Saturday 28 December 2002 13:35, Marko Rauhamaa wrote:
> Lynn Winebarger <address@hidden>:
> 
> > On Saturday 28 December 2002 03:49, Marko Rauhamaa wrote:
> > > 
> > >   return scm_list_2(scm_cons(scm_long2num(old_timer.it_interval.tv_sec),
> > >                              scm_long2num(old_timer.it_interval.tv_usec)),
> > >                     scm_cons(scm_long2num(old_timer.it_value.tv_sec),
> > >                              scm_long2num(old_timer.it_value.tv_usec)));
> > > 
> > > If I understand it correctly, this statement contains several
> > > allocations, each of which can potentially trigger garbage collection
> > > and delete any of the intermediate results.
> >
> >      The code above, though it is not explicit, will store the
> > intermediate return values (references) on the stack, where the
> > garbage collector will see them (and thus not free the newly created
> > object). It's just how the traditional model of a C machine works.
> 
> I took a glance at gc_os_dep.c and I was surprised. It appears the GC
> actually sweeps through all data segments, the stack segment and CPU
> registers and heuristically locates pointers into the heap. I've used
> that technique myself before, but I wouldn't have thought that was an
> effective way of implementing a Lisp machine.
> 
> The Guile manual doesn't state that basically all writable memory of a
> process participates in GC:
> 
>   
> http://www.gnu.org/software/guile/docs/guile-ref/Memory-Management.html#Memory%20Management

      Guile's GC got an overhaul earlier this year.  I don't know how
well the documentation reflects that.
       Anybody?

Lynn



reply via email to

[Prev in Thread] Current Thread [Next in Thread]