From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.user Subject: Re: Guile bugs Date: Fri, 21 Jul 2017 13:08:40 +0300 Message-ID: <87r2xa6r13.fsf@elektro.pacujo.net> References: <87lgtajpkc.fsf@web.de> <87h8y7ruuz.fsf_-_@gnu.org> <877ez384eu.fsf@elektro.pacujo.net> <87k2333qx9.fsf@gmail.com> <87pocvc5ya.fsf@elektro.pacujo.net> <87poculu2v.fsf@gnu.org> <87inimd9yy.fsf@elektro.pacujo.net> <87k232cu3p.fsf@netris.org> <877ez2co3j.fsf@elektro.pacujo.net> <877ez2cfnn.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1500631753 20545 195.159.176.226 (21 Jul 2017 10:09:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Jul 2017 10:09:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-user@gnu.org To: Mark H Weaver Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jul 21 12:09:08 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dYUrs-00055C-61 for guile-user@m.gmane.org; Fri, 21 Jul 2017 12:09:08 +0200 Original-Received: from localhost ([::1]:42104 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYUrx-00027R-TU for guile-user@m.gmane.org; Fri, 21 Jul 2017 06:09:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYUrX-00026k-0B for guile-user@gnu.org; Fri, 21 Jul 2017 06:08:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dYUrT-0007rg-5N for guile-user@gnu.org; Fri, 21 Jul 2017 06:08:46 -0400 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=44292 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dYUrS-0007qB-TM; Fri, 21 Jul 2017 06:08:43 -0400 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Fri, 21 Jul 2017 13:08:40 +0300 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Fri, 21 Jul 2017 13:08:40 +0300 In-Reply-To: <877ez2cfnn.fsf@netris.org> (Mark H. Weaver's message of "Fri, 21 Jul 2017 05:17:48 -0400") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13967 Archived-At: Mark H Weaver : > Marko Rauhamaa writes: > >> Mark H Weaver : >> >>> Marko Rauhamaa writes: >>> >>>> ludo@gnu.org (Ludovic Court=C3=A8s): >>>> >>>>> libgc knows which regions it must scan and mmap=E2=80=99d 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 =E2=80=9Cjust works=E2=80=9D, 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 , 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. Marko