unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Marko Rauhamaa <marko@pacujo.net>
Cc: bug-guile@gnu.org
Subject: Re: Latent bugs?
Date: 28 Dec 2002 10:35:56 -0800	[thread overview]
Message-ID: <m3isxeousz.fsf@lumo.pacujo.net> (raw)
In-Reply-To: <0212280430350A.21210@locke.free-expression.org>

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


  reply	other threads:[~2002-12-28 18:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-28  8:49 Latent bugs? Marko Rauhamaa
2002-12-28  9:30 ` Lynn Winebarger
2002-12-28 18:35   ` Marko Rauhamaa [this message]
2002-12-28 19:22     ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3isxeousz.fsf@lumo.pacujo.net \
    --to=marko@pacujo.net \
    --cc=bug-guile@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).