[Top][All Lists]

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

Re: Guile bugs

From: Marko Rauhamaa
Subject: Re: Guile bugs
Date: Fri, 21 Jul 2017 13:08:40 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Mark H Weaver <address@hidden>:

> Marko Rauhamaa <address@hidden> writes:
>> Mark H Weaver <address@hidden>:
>>> Marko Rauhamaa <address@hidden> writes:
>>>> address@hidden (Ludovic Courtès):
>>>>> libgc knows which regions it must scan and mmap’d regions like
>>>>> this are not among them.
>>>> Wow, where is that documented? I would have imagined it scanned all
>>>> writable RAM and CPU registers.
>>> It's documented here:
>> Please point out the sentence.
> Read the "Mark phase" section.  In brief, roots are scanned from the
> registers, stack(s), and static data region(s).  The only other areas
> scanned are heap areas specifically managed by libgc.  No pointer is
> considered valid unless it points to a libgc-managed heap block.

If you say so.

Both libgc and Guile would benefit from explicitly mentioning (example)
areas of RAM that aren't considered by GC. This page is quite

   The BDW-GC “just works”, for the most part. [...]

   Thus, the BDW-GC uses a technique called conservative garbage
   collection, to make the local variable list unnecessary. [...]

   Obviously, such a system will occasionally retain objects that are
   actually garbage, and should be freed. In practice, this is not a
   problem. The alternative, an explicitly maintained list of local
   variable addresses, is effectively much less reliable, due to
   programmer error. Interested readers should see the BDW-GC web page
   at <URL:>, for more information.


What you're saying points out a secondary problem that applies to Guile
C programming. If you have stored Guile smob references in, say,
third-party library objects, you'll need to carefully protect and
unprotect them.


reply via email to

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