[Top][All Lists]
[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
- Re: Latent bugs?,
Lynn Winebarger <=