Re: Guile bugs

[Marko Rauhamaa]

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:  http://www.hboehm.info/gc/gcdescr.html
>>
>> 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
dismissive:

   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: http://www.hboehm.info/gc/>, for more information.

   <URL: https://www.gnu.org/software/guile/manual/html_node/Conservativ
   e-GC.html>


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.


Marko