Latent bugs?

Latent bugs?

[Marko Rauhamaa]

The Guile manual warns about "a Common Mistake in Allocating Smobs":

http://www.gnu.org/software/guile/docs/guile-ref/A-Common-Mistake-In-Allocating-Smobs.html#A%20Common%20Mistake%20In%20Allocating%20Smobs

Indeed, it seems to me the Guile 1.6.0 source code contains numerous
instances of this common mistake. For example (in scmsigs.c):

  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.

Have I mistaken? What is the right way of constructing and returning the
list above?


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Latent bugs?

[Lynn Winebarger]

On Saturday 28 December 2002 03:49, Marko Rauhamaa wrote:
> The Guile manual warns about "a Common Mistake in Allocating Smobs":
> 
> http://www.gnu.org/software/guile/docs/guile-ref/A-Common-Mistake-In-Allocating-Smobs.html#A%20Common%20Mistake%20In%20Allocating%20Smobs
> 
> Indeed, it seems to me the Guile 1.6.0 source code contains numerous
> instances of this common mistake. For example (in scmsigs.c):
> 
>   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.
> 
> Have I mistaken? What is the right way of constructing and returning the
> list above?
> 
      I believe you are mistaken.  The web page you cite gives an example
of a newly created object whose only references are contained in a structure
in a heap that isn't known to the garbage collector. 
     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.

Lynn



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Latent bugs?

[Marko Rauhamaa]

Lynn Winebarger <owinebar@free-expression.org>:

> 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


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Latent bugs?

[Marius Vollmer]

Marko Rauhamaa <marko@pacujo.net> writes:

> The Guile manual doesn't state that basically all writable memory of
> a process participates in GC:

Hmm.  More needs to be said to get a accurate picture of how GC works
in Guile.

The Guile GC does only manage objects that are represented as a value
of type SCM.  All these objects are either immediate (and thus don't
need to be freed), or they consist of at least a header cell.  Thus,
one can say that the Guile GC only manages these header cells.  A
string, for example, consists of one such header cell and the memory
to hold the characters.  When a string is freed, the cell and the
additional memory is freed together.

Now, to do its thing, the GC needs to find all references between life
objects, and also needs to know about the root set of references.  The
root references can either be known precisely (protecting a object via
scm_gc_protect_object creates such a known, precise root reference) or
they can be searched for in a specified memory region.  During this
search, all words are considered and when the bit pattern can be
interpreted as a SCM reference, it is assumed to actually be one.

When you say that "basically all writable memory of a process
participates in GC", you probably mean that all writable memory of a
process is taken to be in the root set, and is searched for potential
references.  This is not true.  Only the stacks (of all threads) and
the registers are searched in this manner.  The global heap is not
searched.

The GC algorithm has changed somewhat in the recent past, but the
behavior re where root references are found has not been changed.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile