From: Marko Rauhamaa <marko@pacujo.net>
To: Mark H Weaver <mhw@netris.org>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-user@gnu.org
Subject: Re: Guile bugs
Date: Fri, 21 Jul 2017 13:08:40 +0300 [thread overview]
Message-ID: <87r2xa6r13.fsf@elektro.pacujo.net> (raw)
In-Reply-To: <877ez2cfnn.fsf@netris.org> (Mark H. Weaver's message of "Fri, 21 Jul 2017 05:17:48 -0400")
Mark H Weaver <mhw@netris.org>:
> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> Mark H Weaver <mhw@netris.org>:
>>
>>> Marko Rauhamaa <marko@pacujo.net> writes:
>>>
>>>> ludo@gnu.org (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
next prev parent reply other threads:[~2017-07-21 10:08 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-12 23:56 How to make GNU Guile more successful Amirouche
2017-02-13 0:21 ` Amirouche
2017-02-13 11:06 ` Arne Babenhauserheide
2017-02-13 12:14 ` Arne Babenhauserheide
2017-02-13 20:20 ` Amirouche
2017-02-13 23:08 ` Arne Babenhauserheide
2017-02-13 20:28 ` Panicz Maciej Godek
2017-02-13 20:42 ` Amirouche
2017-02-13 22:34 ` Marko Rauhamaa
2017-02-13 23:56 ` Arne Babenhauserheide
2017-02-14 0:18 ` David Kastrup
2017-02-14 22:21 ` Arne Babenhauserheide
2017-02-15 17:03 ` Christopher Allan Webber
2017-02-16 19:18 ` sirgazil
2017-02-16 20:26 ` Amirouche
2017-02-14 5:59 ` Marko Rauhamaa
2017-02-14 19:36 ` Linas Vepstas
2017-02-14 20:54 ` Marko Rauhamaa
2017-02-14 22:20 ` Arne Babenhauserheide
2017-02-13 22:54 ` Arne Babenhauserheide
2017-02-14 9:54 ` Panicz Maciej Godek
2017-02-14 21:35 ` Arne Babenhauserheide
2017-03-01 19:21 ` Amirouche
2017-03-10 20:23 ` Amirouche
2017-07-14 21:54 ` Linas Vepstas
2017-07-14 21:59 ` Marko Rauhamaa
2017-07-15 10:10 ` Jan Wedekind
2017-07-15 12:55 ` Nala Ginrut
2017-07-15 12:58 ` Nala Ginrut
2017-07-15 22:17 ` Jan Wedekind
2017-07-16 9:54 ` Nala Ginrut
2017-07-17 18:52 ` Arun Isaac
2017-07-18 11:22 ` Ernest Adrogué
2017-07-16 8:30 ` Freja Nordsiek
2017-07-16 9:18 ` Marko Rauhamaa
2017-07-16 10:11 ` Freja Nordsiek
2017-07-16 10:31 ` Marko Rauhamaa
2017-07-16 10:39 ` Freja Nordsiek
2017-07-16 10:45 ` Freja Nordsiek
2017-07-20 15:28 ` Guile bugs Ludovic Courtès
2017-07-20 16:22 ` Marko Rauhamaa
2017-07-20 18:26 ` Taylan Ulrich Bayırlı/Kammer
2017-07-20 18:35 ` Marko Rauhamaa
2017-07-20 20:41 ` Ludovic Courtès
2017-07-20 22:23 ` Marko Rauhamaa
2017-07-21 4:05 ` Mark H Weaver
2017-07-21 6:15 ` Marko Rauhamaa
2017-07-21 8:16 ` Chris Vine
2017-07-21 8:27 ` Marko Rauhamaa
2017-07-21 9:17 ` Mark H Weaver
2017-07-21 10:08 ` Marko Rauhamaa [this message]
2017-07-21 10:22 ` David Kastrup
2017-09-09 21:14 ` Linas Vepstas
2017-09-09 22:31 ` Marko Rauhamaa
2017-09-09 23:02 ` Linas Vepstas
2017-07-21 16:33 ` Taylan Ulrich Bayırlı/Kammer
2017-07-21 17:12 ` Marko Rauhamaa
2017-07-21 14:19 ` Matt Wette
2017-09-09 20:30 ` Linas Vepstas
2017-09-10 13:11 ` Ludovic Courtès
2017-09-10 19:56 ` Linas Vepstas
2017-09-11 7:26 ` Ludovic Courtès
2017-09-11 8:10 ` Marko Rauhamaa
2017-09-11 11:34 ` Ludovic Courtès
2017-09-14 17:54 ` Linas Vepstas
2017-09-15 7:56 ` Ludovic Courtès
2017-09-19 11:04 ` Linas Vepstas
2017-09-19 20:18 ` Chris Vine
2017-09-19 20:21 ` Chris Vine
2017-09-19 23:39 ` Nala Ginrut
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=87r2xa6r13.fsf@elektro.pacujo.net \
--to=marko@pacujo.net \
--cc=guile-user@gnu.org \
--cc=ludo@gnu.org \
--cc=mhw@netris.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).