From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 26 19:04:18 2015 Received: (at submit) by debbugs.gnu.org; 26 Jun 2015 23:04:18 +0000 Received: from localhost ([127.0.0.1]:58509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z8cfR-0008V5-Vl for submit@debbugs.gnu.org; Fri, 26 Jun 2015 19:04:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41557) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z8cfP-0008Ut-EF for submit@debbugs.gnu.org; Fri, 26 Jun 2015 19:04:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8cfJ-0000Mp-5m for submit@debbugs.gnu.org; Fri, 26 Jun 2015 19:04:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=5.0 tests=BAYES_50,FORGED_YAHOO_RCVD, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:38403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8cfJ-0000Ml-2y for submit@debbugs.gnu.org; Fri, 26 Jun 2015 19:04:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8cfH-0003bG-Vv for bug-guile@gnu.org; Fri, 26 Jun 2015 19:04:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8cfC-0000KV-PU for bug-guile@gnu.org; Fri, 26 Jun 2015 19:04:07 -0400 Received: from nm20-vm3.bullet.mail.ne1.yahoo.com ([98.138.91.150]:58720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8cfC-0000KP-2B for bug-guile@gnu.org; Fri, 26 Jun 2015 19:04:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435359841; bh=P7Eoyy1ghmr/xXRyFKnQVfqxLvzvf8ecKq8ArsCT7Q8=; h=Date:From:Reply-To:To:Subject:From:Subject; b=aZP7Ow41fL4AqIvwMxs9DqBOHB/ut9AvNUf43CmVHnCxSwHVxGeRHZ32PKDARrKBoqSorOV8mlWFNHj5iM45IkujBdju5npFfawEEHA+zjrN5LyLTKvnvgCKtMKCCJz0ZfW5OfxItoXpUKp54RzTHOHhPM6NL8Xcr8rIs4RJurJRktE0w+Yvwebv7+Z8JtXz+WBanYrTgqVqy8WvNe7eVZ48WrEsClJ0y7xtd6Emgl7aUiYDKxJA6YQyTjbz37GsFBktH8RMde/LWkco1zgD7oq0yN6i5mCWdXeNuSv/qkx9wUR2JAIf5a21OocMDUIUrfCQptBSx6tkxUs6r+tKSQ== Received: from [98.138.100.112] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jun 2015 23:04:01 -0000 Received: from [98.138.89.234] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jun 2015 23:04:01 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 26 Jun 2015 23:04:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 153916.33572.bm@omp1049.mail.ne1.yahoo.com X-YMail-OSG: n8MIyEkVM1k9f1w7H_r1j3Xkswa9TgDB7hK3_ZoSch.74MAcVWzHG3h_2a4OmRz 9Wytx7gX1VQVkGjzRytXYkwJpMFv_nG0fOf1IhghZnO._V94gLLCpmxe61kgAARs0D4Rs6FNk1rN EgEOeD5A8sk6zEXq9fWV..CmJS_CkI3A3oJFuvm.lInLL2lM_r7XiC0L8f8tk1t4vQxqgpeTbLMC D5f7piUlJ.mGVsM2gh7_6ILPXJbc3EOoq6kR.AoRMMe8L2FA80d0WLAPCdjqwz39RILmuj.J0R7d zSiKCzxPSpslb2rpvdIBw3T8m.kLajelRFoSkESY8_9j5ZUb1nDZ3Fx4EOy04s4OeUTGWbf0FN6q jNuuA1Cs6J3JucTH79xMSLt_sel0Yg.4Sg5.mHjyOuFww1FjzoXigKzhtYKbW5VIN6MdsZDSmk41 I0Lqlzrw8PPDZpWT5bngHLagKMUFxmgNnNfUmJbcTDU0VLS9LZK4qNxG54gT_iD0V98Cptt6EhvG i9Q-- Received: by 98.138.101.171; Fri, 26 Jun 2015 23:04:00 +0000 Date: Fri, 26 Jun 2015 23:00:32 +0000 (UTC) From: Mike Gran To: Bug Guile Message-ID: <1019343405.630040.1435359632144.JavaMail.yahoo@mail.yahoo.com> Subject: [PATCH] Manual bug for scm_gc_protect_object MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Length: 897 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mike Gran List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) Manual claims C globals weren't scanned by GC in 1.8. The opposite is true. * doc/ref/api-memory.texi [scm_gc_protect_object]: modified --- doc/ref/api-memory.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/ref/api-memory.texi b/doc/ref/api-memory.texi index 0e37d16..3496cc5 100644 --- a/doc/ref/api-memory.texi +++ b/doc/ref/api-memory.texi @@ -42,7 +42,7 @@ as it was protected. It is an error to unprotect an object more times than it has been protected. Returns the SCM object it was passed. Note that storing @var{obj} in a C global variable has the same -effect@footnote{In Guile up to version 1.8, C global variables were not +effect@footnote{In Guile up to version 1.8, C global variables were scanned by the garbage collector; hence, @code{scm_gc_protect_object} was the only way in C to prevent a Scheme object from being freed.}. @end deftypefn -- 2.1.0 From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 22:00:09 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 02:00:09 +0000 Received: from localhost ([127.0.0.1]:45545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWxLL-00076v-NG for submit@debbugs.gnu.org; Tue, 01 Sep 2015 22:00:08 -0400 Received: from world.peace.net ([50.252.239.5]:43838) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWxLH-00076R-Ht for 20907@debbugs.gnu.org; Tue, 01 Sep 2015 22:00:05 -0400 Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZWxLB-000593-0E; Tue, 01 Sep 2015 21:59:57 -0400 From: Mark H Weaver To: Mike Gran Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object References: <1019343405.630040.1435359632144.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 01 Sep 2015 21:59:21 -0400 In-Reply-To: <1019343405.630040.1435359632144.JavaMail.yahoo@mail.yahoo.com> (Mike Gran's message of "Fri, 26 Jun 2015 23:00:32 +0000 (UTC)") Message-ID: <87wpw97f9i.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20907 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 20907@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi Mike, Mike Gran writes: > Manual claims C globals weren't scanned by GC in 1.8. The opposite > is true. Ludovic wrote that text in 2009, commit f07c349eb38d6c7b160b8980fc4007fb502e3433. Ludovic, what do you make of this? > * doc/ref/api-memory.texi [scm_gc_protect_object]: modified > --- > doc/ref/api-memory.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/ref/api-memory.texi b/doc/ref/api-memory.texi > index 0e37d16..3496cc5 100644 > --- a/doc/ref/api-memory.texi > +++ b/doc/ref/api-memory.texi > @@ -42,7 +42,7 @@ as it was protected. It is an error to unprotect an object more times > than it has been protected. Returns the SCM object it was passed. > > Note that storing @var{obj} in a C global variable has the same > -effect@footnote{In Guile up to version 1.8, C global variables were not > +effect@footnote{In Guile up to version 1.8, C global variables were > scanned by the garbage collector; hence, @code{scm_gc_protect_object} > was the only way in C to prevent a Scheme object from being freed.}. If what you say is true, then this patch would not be sufficient, because the footnote would not make sense. If you're right, then the entire paragraph above should be removed. Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 08:09:00 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 12:09:00 +0000 Received: from localhost ([127.0.0.1]:46019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX6qa-0007fm-9L for submit@debbugs.gnu.org; Wed, 02 Sep 2015 08:09:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43385) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZX6qY-0007ff-NX for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 08:08:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZX6qW-0002X3-3G for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 08:08:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX6qV-0002Wz-WF; Wed, 02 Sep 2015 08:08:56 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:47133 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZX6qU-0000aj-Vi; Wed, 02 Sep 2015 08:08:55 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Mark H Weaver Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object References: <1019343405.630040.1435359632144.JavaMail.yahoo@mail.yahoo.com> <87wpw97f9i.fsf@netris.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 16 Fructidor an 223 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x3D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Wed, 02 Sep 2015 14:08:52 +0200 In-Reply-To: <87wpw97f9i.fsf@netris.org> (Mark H. Weaver's message of "Tue, 01 Sep 2015 21:59:21 -0400") Message-ID: <87a8t5c9bf.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20907 Cc: 20907@debbugs.gnu.org, Mike Gran X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Mark H Weaver skribis: > Mike Gran writes: >> Manual claims C globals weren't scanned by GC in 1.8. The opposite >> is true. > > Ludovic wrote that text in 2009, commit > f07c349eb38d6c7b160b8980fc4007fb502e3433. I think the manual is correct: global C variables were *not* scanned by the GC. As an example, see =E2=80=98scm_sys_protects=E2=80=99 in 1.8: It= =E2=80=99s a global array that was explicitly scanned by the GC, because that=E2=80=99s basical= ly the only mechanism to add new GC root: j =3D SCM_NUM_PROTECTS; while (j--) scm_gc_mark (scm_sys_protects[j]); The 1.8 manual reads: Other references to 'SCM' objects, such as global variables of type 'SCM' or other random data structures in the heap that contain fields of type 'SCM', can be made visible to the garbage collector by calling the functions 'scm_gc_protect' or 'scm_permanent_object'. You normally use these funtions for long lived objects such as a hash table that is stored in a global variable. For temporary references in local variables or function arguments, using these functions would be too expensive. http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Garbage-Collectio= n.html So I think we can close as =E2=80=98notabug=E2=80=99? :-) Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 11:36:18 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 15:36:19 +0000 Received: from localhost ([127.0.0.1]:46622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXA5C-0004DI-8f for submit@debbugs.gnu.org; Wed, 02 Sep 2015 11:36:18 -0400 Received: from nm15-vm3.bullet.mail.ne1.yahoo.com ([98.138.91.145]:37859) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXA5A-0004D9-0o for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 11:36:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441210131; bh=AGgTgIesyBnY3IETSyWTfcGp7ouW0e6JUvfoylHAtSs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=a5y7V+s4TLidnp7JDB2HXsJxkJoR/4fweu0UOZnh1qq/f79Qg95PWQQIG62EEoZOOeaC7RMJsCMZsq9sj4qmsvNhshDQV8lsFctMiDvBiDqZUyx0BwO4CthA1jXMChdy1DiImgIZ5Qmz3cppZW7GlKnvQrN3lLJA8a3ww0/PSrUV/oxvcJ6pBLwn810lBFX9yK00MQ/8QAgly6KtCIkpTwUj/00eigaB4APTP9LO1Nrb9/GPkTymYAuhT1+H8ZaQ4bMJ/+IR2JpJm9xU4XMRNwhJHeWJLUIlk3XIWefMBwSzo8CT2V5cyv85K1yaaTfkU5NJ48RKhQC101aMHx1tFw== Received: from [98.138.101.130] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 16:08:51 -0000 Received: from [98.138.89.249] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 15:36:15 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 15:36:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 217962.74224.bm@omp1041.mail.ne1.yahoo.com X-YMail-OSG: REX0Us8VM1lbI2b2irQnsgeRwbvgcs1MlomhZb2xMYl3Ab47zPn4cc5vkd0hOgv jAHHRv7UcewSKkq19xVXMafNY53rO0M3skLzSpJM0RtJBMksUd8PQZD6zMI9wXUlh2wP0oJvt3_Z 7kMHHx2jSOqOzhfLzzAK4w5uL1NT5ifJGBfhJovbNflSOnCYCb5pTv6PBbhqrppMZc96rIJ36bvg KhZN2OsSPiKFBAMiR.oBGEgfji9ZNNkFxOzbt85o_E7maBV0jZW4ROTuQjW_KZVpkaNVz7vQdHxH L9HJCzZrsHwltkxXJD3wSJGQNrCcrC3ajuWUzlumgxSpYZrA73MvAvT27NiOV5rXrf3ROOZtffea 12MS.61xAhWKHJq9lPdhpBQ7TpESfDOQGkZB6KLEfgW88vQvLxcS_wHhAf1I4Nki.iCnlUJCmnRe J_eeAVFvKUuSRa.eBLWcLb7StLfihE1xUE3Wt3WlG1Sao4meR4cGo4rSNOFy7D2K1weEyZLd5Iuy DdkOgmOYfJA-- Received: by 98.138.105.245; Wed, 02 Sep 2015 15:36:14 +0000 Date: Wed, 2 Sep 2015 15:36:13 +0000 (UTC) From: Mike Gran To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= , Mark H Weaver Message-ID: <1975455902.407587.1441208174259.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <87a8t5c9bf.fsf@gnu.org> References: <87a8t5c9bf.fsf@gnu.org> Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_407586_649051924.1441208174259" Content-Length: 5050 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 20907 Cc: "20907@debbugs.gnu.org" <20907@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mike Gran List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) ------=_Part_407586_649051924.1441208174259 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > On Wednesday, September 2, 2015 5:09 AM, Ludovic Court=C3=A8s wrote: > I think the manual is correct: global C variables were *not* scanned by > the GC. As an example, see =E2=80=98scm_sys_protects=E2=80=99 in 1.8: It= =E2=80=99s a global > array that was explicitly scanned by the GC, because that=E2=80=99s basic= ally > the only mechanism to add new GC root: >=20 > j =3D SCM_NUM_PROTECTS; > while (j--) > scm_gc_mark (scm_sys_protects[j]); >=20 > The 1.8 manual reads: >=20 > Other references to 'SCM' objects, such as global variables of type > 'SCM' or other random data structures in the heap that contain fields= =20 > of > type 'SCM', can be made visible to the garbage collector by calling=20 > the > functions 'scm_gc_protect' or 'scm_permanent_object'. You=20 > normally use > these funtions for long lived objects such as a hash table that is > stored in a global variable. For temporary references in local > variables or function arguments, using these functions would be too > expensive. For what it is worth, the effect that I was seeing that made me question the documentation can be demonstrated by the attached program, where two 100MB Guile strings are stored in a C globals: one protected and one not.=20 In 1.8, a GC operation reduces memory from 200MB to 100MB, which I assume is freeing the memory from the unprotected string. In 2.0, the heap size always stays at 200MB. The output of the program for Guile 1.8.8 and Guile 2.0.9 is attached. Thanks, Mike ------=_Part_407586_649051924.1441208174259 Content-Type: text/x-csrc Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=main.c Content-ID: I2luY2x1ZGUgPGxpYmd1aWxlLmg+CgoKI2RlZmluZSBPTkVfSFVORFJFRF9NSUxMSU9OICgxMDAq MTAwMCoxMDAwKQoKU0NNIHByb3RlY3RlZF9zdHJpbmc7ClNDTSB1bnByb3RlY3RlZF9zdHJpbmc7 Cgp2b2lkIGlubmVyX21haW4gKHZvaWQgKmRhdGEsIGludCBhcmdjLCBjaGFyICoqYXJndikKewog IHByb3RlY3RlZF9zdHJpbmcgPSBzY21fY19tYWtlX3N0cmluZyhPTkVfSFVORFJFRF9NSUxMSU9O LCBTQ01fTUFLRV9DSEFSKCcxJykpOwogIHNjbV9nY19wcm90ZWN0X29iamVjdCAocHJvdGVjdGVk X3N0cmluZyk7CgogIHVucHJvdGVjdGVkX3N0cmluZyA9IHNjbV9jX21ha2Vfc3RyaW5nKE9ORV9I VU5EUkVEX01JTExJT04sIFNDTV9NQUtFX0NIQVIoJzInKSk7CgogIHNjbV9kaXNwbGF5KHNjbV9j X2V2YWxfc3RyaW5nKCIoZ2Mtc3RhdHMpIiksIHNjbV9jdXJyZW50X291dHB1dF9wb3J0KCkpOwog IHNjbV9uZXdsaW5lKHNjbV9jdXJyZW50X291dHB1dF9wb3J0KCkpOwoKICBzY21fZ2MoKTsKCiAg c2NtX2Rpc3BsYXkoc2NtX2NfZXZhbF9zdHJpbmcoIihnYy1zdGF0cykiKSwgc2NtX2N1cnJlbnRf b3V0cHV0X3BvcnQoKSk7CiAgc2NtX25ld2xpbmUoc2NtX2N1cnJlbnRfb3V0cHV0X3BvcnQoKSk7 Cn0KCmludCBtYWluIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCnsKICBzY21fYm9vdF9ndWlsZSAo YXJnYywgYXJndiwgaW5uZXJfbWFpbiwgTlVMTCk7CiAgcmV0dXJuIDA7Cn0K ------=_Part_407586_649051924.1441208174259 Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=out18.txt Content-ID: <885b8c6d-33cf-6c43-0f8a-7668d52142b8@yahoo.com> KChnYy10aW1lLXRha2VuIC4gMCkgKGNlbGxzLWFsbG9jYXRlZCAuIDYxNjExKSAodG90YWwtY2Vs bHMtYWxsb2NhdGVkIC4gNjE3MjIpIChjZWxsLWhlYXAtc2l6ZSAuIDgzMzgzKSAoYnl0ZXMtbWFs bG9jZWQgLiAyMDAwODE2MDgpIChnYy1tYWxsb2MtdGhyZXNob2xkIC4gMzY2ODE2MDg1KSAoZ2Mt dGltZXMgLiA0KSAoZ2MtbWFyay10aW1lLXRha2VuIC4gMCkgKGNlbGxzLW1hcmtlZCAuIDQxMDAx Ny4wKSAoY2VsbHMtc3dlcHQgLiA0NTg0OTAuMCkgKG1hbGxvYy15aWVsZCAuIDApIChjZWxsLXlp ZWxkIC4gMCkgKHByb3RlY3RlZC1vYmplY3RzIC4gMSkgKGNlbGwtaGVhcC1zZWdtZW50cyAoMTYy NDQ5NDA4IC4gMTYyNDg0MjI0KSAoMzA3NjUyNDAzMiAuIDMwNzY2OTQwMTYpICgzMDc2NzAwMTYw IC4gMzA3NjkwMDg2NCkgKDMwNzY5MDkwNTYgLiAzMDc3MTczMjQ4KSkpCigoZ2MtdGltZS10YWtl biAuIDApIChjZWxscy1hbGxvY2F0ZWQgLiA2MTY2MikgKHRvdGFsLWNlbGxzLWFsbG9jYXRlZCAu IDYxNzk3KSAoY2VsbC1oZWFwLXNpemUgLiA4MzM4MykgKGJ5dGVzLW1hbGxvY2VkIC4gMTAwMDgx ODc4KSAoZ2MtbWFsbG9jLXRocmVzaG9sZCAuIDM2NjgxNjA4NSkgKGdjLXRpbWVzIC4gNSkgKGdj LW1hcmstdGltZS10YWtlbiAuIDApIChjZWxscy1tYXJrZWQgLiA0OTMzNzguMCkgKGNlbGxzLXN3 ZXB0IC4gNTQxODc1LjApIChtYWxsb2MteWllbGQgLiAwKSAoY2VsbC15aWVsZCAuIDApIChwcm90 ZWN0ZWQtb2JqZWN0cyAuIDEpIChjZWxsLWhlYXAtc2VnbWVudHMgKDE2MjQ0OTQwOCAuIDE2MjQ4 NDIyNCkgKDMwNzY1MjQwMzIgLiAzMDc2Njk0MDE2KSAoMzA3NjcwMDE2MCAuIDMwNzY5MDA4NjQp ICgzMDc2OTA5MDU2IC4gMzA3NzE3MzI0OCkpKQo= ------=_Part_407586_649051924.1441208174259 Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=out20.txt Content-ID: <3e651ad0-c9a9-aae0-0c9d-742a41d0ee71@yahoo.com> KChnYy10aW1lLXRha2VuIC4gOTY3KSAoaGVhcC1zaXplIC4gMjE5MTI3ODA4KSAoaGVhcC1mcmVl LXNpemUgLiAxNjc4MTMxMikgKGhlYXAtdG90YWwtYWxsb2NhdGVkIC4gMjAyMzUyMzM2KSAoaGVh cC1hbGxvY2F0ZWQtc2luY2UtZ2MgLiAxNTYzNzYpIChwcm90ZWN0ZWQtb2JqZWN0cyAuIDQwKSAo Z2MtdGltZXMgLiA2KSkKKChnYy10aW1lLXRha2VuIC4gOTcxKSAoaGVhcC1zaXplIC4gMjE5MTI3 ODA4KSAoaGVhcC1mcmVlLXNpemUgLiAxNjgwOTk4NCkgKGhlYXAtdG90YWwtYWxsb2NhdGVkIC4g MjAyMzU0MTY4KSAoaGVhcC1hbGxvY2F0ZWQtc2luY2UtZ2MgLiAxMzg0KSAocHJvdGVjdGVkLW9i amVjdHMgLiA0MCkgKGdjLXRpbWVzIC4gNykpCg== ------=_Part_407586_649051924.1441208174259-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 12:16:53 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 16:16:53 +0000 Received: from localhost ([127.0.0.1]:46645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXAiS-0006mN-Uc for submit@debbugs.gnu.org; Wed, 02 Sep 2015 12:16:53 -0400 Received: from world.peace.net ([50.252.239.5]:45040) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXAiQ-0006mD-Q7 for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 12:16:51 -0400 Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZXAiJ-0000Cv-3U; Wed, 02 Sep 2015 12:16:43 -0400 From: Mark H Weaver To: Mike Gran Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object References: <87a8t5c9bf.fsf@gnu.org> <1975455902.407587.1441208174259.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 02 Sep 2015 12:16:03 -0400 In-Reply-To: <1975455902.407587.1441208174259.JavaMail.yahoo@mail.yahoo.com> (Mike Gran's message of "Wed, 2 Sep 2015 15:36:13 +0000 (UTC)") Message-ID: <87r3mg23wc.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20907 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 20907@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Mike Gran writes: >> On Wednesday, September 2, 2015 5:09 AM, Ludovic Court=C3=A8s wrote: > >> I think the manual is correct: global C variables were *not* scanned by >> the GC. > For what it is worth, the effect that I was seeing that made me > question the documentation can be demonstrated by the attached program, > where two 100MB Guile strings are stored in a C globals: one protected > and one not.=20 > > > In 1.8, a GC operation reduces memory from 200MB to 100MB, which I > assume is freeing the memory from the unprotected string. I'm not sure why this result would make you question the current documentation. To my mind, it clearly confirms what Ludovic wrote. If global C variables were scanned by default in 1.8, as you asserted, then why would the unprotected string have been freed? Am I missing something? Thanks, Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 12:53:42 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 16:53:42 +0000 Received: from localhost ([127.0.0.1]:46667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXBI6-0007dP-3I for submit@debbugs.gnu.org; Wed, 02 Sep 2015 12:53:42 -0400 Received: from world.peace.net ([50.252.239.5]:45164) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXBI3-0007dH-W3 for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 12:53:40 -0400 Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZXBHv-0000U1-2u; Wed, 02 Sep 2015 12:53:31 -0400 From: Mark H Weaver To: Mike Gran Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object References: <87a8t5c9bf.fsf@gnu.org> <1975455902.407587.1441208174259.JavaMail.yahoo@mail.yahoo.com> <87r3mg23wc.fsf@netris.org> Date: Wed, 02 Sep 2015 12:52:54 -0400 In-Reply-To: <87r3mg23wc.fsf@netris.org> (Mark H. Weaver's message of "Wed, 02 Sep 2015 12:16:03 -0400") Message-ID: <87mvx4226x.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20907 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 20907@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Mark H Weaver writes: > Mike Gran writes: > >>> On Wednesday, September 2, 2015 5:09 AM, Ludovic Court=C3=A8s wrote: >> >>> I think the manual is correct: global C variables were *not* scanned by >>> the GC. > >> For what it is worth, the effect that I was seeing that made me >> question the documentation can be demonstrated by the attached program, >> where two 100MB Guile strings are stored in a C globals: one protected >> and one not.=20 >> >> >> In 1.8, a GC operation reduces memory from 200MB to 100MB, which I >> assume is freeing the memory from the unprotected string. > > I'm not sure why this result would make you question the current > documentation. To my mind, it clearly confirms what Ludovic wrote. > > If global C variables were scanned by default in 1.8, as you asserted, > then why would the unprotected string have been freed? It occurs to me that this confusion might have arisen from a lack of knowledge about garbage collection and what it means to "scan" something. "Scanning" is more or less a synonym for "marking", where the reachable objects are first marked starting from the roots, and after that's done, anything that is not marked will be freed in the sweep phase. I wonder if Mike might have been thinking that something cannot be freed unless it is scanned, so if it is freed that is evidence that it was scanned. In fact, scanning (marking) is necessary to *prevent* freeing, not to enable it. Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 13:13:31 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 17:13:31 +0000 Received: from localhost ([127.0.0.1]:46672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXBbH-0008Hs-5Q for submit@debbugs.gnu.org; Wed, 02 Sep 2015 13:13:31 -0400 Received: from nm10-vm2.bullet.mail.ne1.yahoo.com ([98.138.90.158]:37915) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXBbF-0008Hg-A6 for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 13:13:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441214008; bh=M2Qk05/0zXsWB0ZFq8JWjOW+E5n2Hhv5Grk7TQsUr7w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KeTSAXrn33oB/tYEEkmJ/p2xVgf/FyuGYs5Dnpwj6+yJpg4Cqse5D7bE0Ap0L0g32GwiSCDd+JC4mr9rMBR5G6JPtTBy59TCWcvN+l7zPOmSqZ3IL3K8AKzL0lL91vyIQAs7IZNqjfUAe0vOi6RscH28NQox7EvVhfMDG6FkFuRu178fIx4DhmXFVUgsyRDmVmL93oB2lsC+DAYKKinClEVjhC1xMpwXZqmR0XWCF9VXd+9+TdbUL+n2fv8BPAQ4tSwoXy6yQPD9LtUg6hoENJcnDsUBXR/qD0NQYnosCQwcTVsA6PJGmMxRxsJaWZV+yykNc7eCxWppuxDmG5ii6Q== Received: from [98.138.101.131] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 17:13:28 -0000 Received: from [98.138.89.164] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 17:13:28 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 17:13:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 589565.28391.bm@omp1020.mail.ne1.yahoo.com X-YMail-OSG: kU9lC_YVM1nb6sDO7ZTJkprkaoAQJC94jW.0C4CxyCnHdQ.1Vzx3Emwk8m6fT2c 2bhWe9kjmh_gL6aw9Yhm4JwWa7y88jDY86wndTr_YaGiMUXhl1gJoJkrPXKGo.P0mRCUA79ZsJfI W_NRSyZEofbpGaKgPuzxV8njJJp4xQG5SlhEmm_k4OhI6ThYf0wzMFLdpN.ZN_hLbbYeykkPRfgd tnlSHWYJb_ZpIvD3KVXHqq0FLTklbR_zPZGftoTH.lxAZC2DgcPgfUD8ns.oaGdDgTC_xLL7z9rq 8PpR4EOhb_zPL70cGD_SB3x0bW0_ypUGBTdgl2KSQcAa5j5SFNpfAACdzILkkZfw07QenFOkjwHB JBURy8F4YWNigC0guUS6u9TQwF_uLdoiLMVIlNW1SIok.Mcq_N119Ru8Dg8ervPOoQ7Ik5l4zLS6 1UL9UhrOxjUe3OtecGhge1kOqb0l28pzoeAZDkjVzqdkyVw81gxvkz5fQVHGpF1E3R4ojzf0P5Fg ybA-- Received: by 98.138.101.174; Wed, 02 Sep 2015 17:13:28 +0000 Date: Wed, 2 Sep 2015 17:12:31 +0000 (UTC) From: Mike Gran To: Mark H Weaver Message-ID: <572469453.502254.1441213951447.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <87r3mg23wc.fsf@netris.org> References: <87r3mg23wc.fsf@netris.org> Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Length: 1838 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 20907 Cc: =?UTF-8?Q?Ludovic_Court=C3=A8s?= , "20907@debbugs.gnu.org" <20907@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mike Gran List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) > On Wednesday, September 2, 2015 9:16 AM, Mark H Weaver wrote: > If global C variables were scanned by default in 1.8, as you asserted, > then why would the unprotected string have been freed? > > Am I missing something? I apologize in advance for the pedantry below. Maybe I just don't understand GC nomenclature. I thought that if a global variable were not "scanned" by a garbage collector, it would be invisible to the garbage collector, and could not be freed by the garbage collector. The footnote in question says that for 1.8, globals were not "scanned", which I understood to mean that globals were invisible to to the garbage collector and could not be freed by the GC. The implication is that, for 2.0, globals were "scanned", which I understood to mean that they were visible to the GC and could be freed. My test program shows that globals are GC'd in 1.8, but, not 2.0. That is why I believe the logic of the footnote to be wrong, and that the "not" should be removed. But I guess from context that you and Ludo have a different definition for "to scan", and that scanning protects something from being GC'd? In the "Garbage Collection" of the manual in both 1.8 and 2.0, it says that in 1.8, that "global variables of type SCM ... can be made visible to the garbage collector by calling the functions scm_gc_protect". (That's a typo I guess. It should say scm_gc_protect_object, I think.) The implication is that if I do not call scm_gc_protect_object, my global is still "invisible" and thus can't be freed by the GC. But my "invisible" global in 1.8 is being freed and in 2.0 it is not freed. The only mention of the difference between 1.8 and 2.0 is in the footnote in question. Look, it is fine, though. Don't waste your time on this if I'm just confused. Thanks, Mike From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 14:06:15 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 18:06:15 +0000 Received: from localhost ([127.0.0.1]:46698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXCQJ-0001gD-1M for submit@debbugs.gnu.org; Wed, 02 Sep 2015 14:06:15 -0400 Received: from world.peace.net ([50.252.239.5]:45227) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXCQH-0001g4-Jx for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 14:06:14 -0400 Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZXCQB-0000oJ-3G; Wed, 02 Sep 2015 14:06:07 -0400 From: Mark H Weaver To: Mike Gran Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object References: <87r3mg23wc.fsf@netris.org> <572469453.502254.1441213951447.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 02 Sep 2015 14:05:30 -0400 In-Reply-To: <572469453.502254.1441213951447.JavaMail.yahoo@mail.yahoo.com> (Mike Gran's message of "Wed, 2 Sep 2015 17:12:31 +0000 (UTC)") Message-ID: <87h9nc1ytx.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20907 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 20907@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Mike Gran writes: > In the "Garbage Collection" of the manual in both 1.8 and 2.0, > it says that in 1.8, that "global variables of type SCM ... can be made > visible to the garbage collector by calling the functions scm_gc_protect". > (That's a typo I guess. It should say scm_gc_protect_object, I > think.) Indeed, good catch! Fixed in 4c5788d1ab14550afd86117e96f91164fbe04a72. > The implication is that if I do not call scm_gc_protect_object, my > global is still "invisible" and thus can't be freed by the GC. But my > "invisible" global in 1.8 is being freed and in 2.0 it is not freed. Here's the crux of the confusion: it's not the global variable that is being freed here. The variable only holds a *reference* to the heap-allocated string. That may seem pedantic, but it's a crucial distinction here. Anything in the heap that is not referenced from somewhere visible to the GC is freed. Would it help to replace all uses of the term "scan" with "mark", in connection with garbage collection? In the papers I've read on GC, "mark" is the word I usually see, and it seems much clearer to me, because anyone who knows the basics of GC knows that "marking" is needed to prevent an object from being freed, whereas "scanning" could mean anything. If you have other ideas of how to make this more clear, I'm open to suggestions. Thanks! Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 14:37:07 2015 Received: (at 20907) by debbugs.gnu.org; 2 Sep 2015 18:37:07 +0000 Received: from localhost ([127.0.0.1]:46721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXCuB-0002P8-0r for submit@debbugs.gnu.org; Wed, 02 Sep 2015 14:37:07 -0400 Received: from nm28-vm5.bullet.mail.ne1.yahoo.com ([98.138.91.250]:44661) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXCu8-0002Ov-OW for 20907@debbugs.gnu.org; Wed, 02 Sep 2015 14:37:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441219024; bh=oqai9QCumNRtbgVM/safAWJa9x8atE7XofuePuvOR4I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qpUmCGtidk3QxqqKUzvaC3cVvo8FZ8nEupUqU9Ezyncl2WcwSP0v73nmAOoqsZ25FRmKvcVoMFhNU6VMI7axwegRBwQscptFAX43DvtoTfvcCu/QOoqZpwbukm1MjvLGuJQDBHe3D++ozoaFOhlhN8y1UyblnGrVSb36cIfCj4Rku81O7QXqOxJVxyMAUFMl6IB56ulWcD+dC8Ioso3fI3yP6N+tzyS8AlE52XUfvVm25Tdhe3nIipqt/6U0GyJXc+cbYjRS6L5pgrNgBfbiCJmqpTBsy6Ykb0+dA2220eFcyabuMvXXV6GJU06FiZBOMz4EySjSx18aZDmbsyPfRw== Received: from [98.138.100.102] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 18:37:04 -0000 Received: from [98.138.89.240] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 18:37:04 -0000 Received: from [127.0.0.1] by omp1013.mail.ne1.yahoo.com with NNFMP; 02 Sep 2015 18:37:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 108596.78940.bm@omp1013.mail.ne1.yahoo.com X-YMail-OSG: Ubj5.tgVM1k4D0f5DmRMg2rzgiCie.fcX4zMYMmJNbNqwhBipy8gqPSlzP_i7OI gQNgNtCYtFdmDwiyW4uhZKecZelfAKSgVqROrRIVIeARjIeYsMnKiRUcIUAGtVd8e3GcDeVPITiT HdpnHfJBBx.Gf6w4pHTWBW8e0JAMebUjI3EPbwLqZiByjjmEhSgq1euLqqJjrN7J9geK2D2AgVgy 9IZj229BszfTyV8wYEM477Y3N3sCgpoMYTCkDAL5Q3UnQa_DM_qWZSr7rywNL.pMScRnDQ_8SAqz sTavDE8nhvZ_4ROvklpbWUPi_TUH4Xnn42pHmFMSmFTkeQCa0iO3Mlbf9SeLo4X3mgii3lr3Tq2f 2r6wIsXiwEQWCiOGGecVWwnJIRE4fKlVlLImxcm2deUULBb4Wab.xmzTSWyzwpfOsZSJbVthm45O 8oYiTgBlP3amwqNXUUV5fAleri4nptuAxKBmrZKZGB40DT9oFmGYoNfwr7mPKPbTvu7abRPG2rBg vQQ-- Received: by 98.138.105.207; Wed, 02 Sep 2015 18:37:03 +0000 Date: Wed, 2 Sep 2015 18:34:28 +0000 (UTC) From: Mike Gran To: Mark H Weaver Message-ID: <1832189928.562370.1441218868076.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <87h9nc1ytx.fsf@netris.org> References: <87h9nc1ytx.fsf@netris.org> Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Length: 595 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 20907 Cc: =?UTF-8?Q?Ludovic_Court=C3=A8s?= , "20907@debbugs.gnu.org" <20907@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mike Gran List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) On Wednesday, September 2, 2015 11:06 AM, Mark H Weaver wrote: >Would it help to replace all uses of the term "scan" with "mark", in >connection with garbage collection? In the papers I've read on GC, >"mark" is the word I usually see, and it seems much clearer to me, >because anyone who knows the basics of GC knows that "marking" is needed >to prevent an object from being freed, whereas "scanning" could mean >anything. That would help, I think. I guess I was associating "scan" with the "sweep" part of mark and sweep. Thanks very much for the clarification. Mike From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 24 02:59:08 2016 Received: (at 20907-done) by debbugs.gnu.org; 24 Jun 2016 06:59:08 +0000 Received: from localhost ([127.0.0.1]:53255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGL51-0007r3-W6 for submit@debbugs.gnu.org; Fri, 24 Jun 2016 02:59:08 -0400 Received: from pb-sasl2.pobox.com ([64.147.108.67]:63795 helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGL4x-0007qp-Ee for 20907-done@debbugs.gnu.org; Fri, 24 Jun 2016 02:59:06 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id E4C1920368; Fri, 24 Jun 2016 02:59:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=//Uo14zgmOddtBV/zuSb8tb9XJU=; b=nmmIyP 5Om6zs1Y3nRGBQhJZe6Csh15LoJr2yF+EmBqP53VJ5JzzlpmQI7AZGir8EkIAZqi UzSuVEETmmrTts78tqxIFzsybrHLK7R1lOHZoACs6B9ZR4rsWqPuRnIoL0odhfex zB25vu2qoft4BauWHXFYuK6jKJRhSukDf229o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=IyjoEgP6oiEbAUm7/Aak6kOsLEXARL2g ci6zKgrqI3d/WW9j8TOCBj2q5oCqk7rWQ7o6Jq54F8oQX397sE9Iha6Y9xUf0nmE bmDXgsTqh3ESOHsAMWT8K5JmiAaqEHioFL4pPRCR30VktGNPwUFVJEbx1Iz/urlo xG2liL3ljuc= Received: from pb-sasl2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id DC1BB20367; Fri, 24 Jun 2016 02:59:01 -0400 (EDT) Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl2.pobox.com (Postfix) with ESMTPSA id 5470620363; Fri, 24 Jun 2016 02:59:00 -0400 (EDT) From: Andy Wingo To: Mike Gran Subject: Re: bug#20907: [PATCH] Manual bug for scm_gc_protect_object References: <87h9nc1ytx.fsf@netris.org> <1832189928.562370.1441218868076.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 24 Jun 2016 08:58:53 +0200 In-Reply-To: <1832189928.562370.1441218868076.JavaMail.yahoo@mail.yahoo.com> (Mike Gran's message of "Wed, 2 Sep 2015 18:34:28 +0000 (UTC)") Message-ID: <8760szjcnm.fsf@pobox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Pobox-Relay-ID: 2109BB60-39D9-11E6-8E3F-28A6F1301B6D-02397024!pb-sasl2.pobox.com X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 20907-done Cc: Mark H Weaver , Ludovic =?utf-8?Q?Court=C3=A8s?= , 20907-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) --=-=-= Content-Type: text/plain On Wed 02 Sep 2015 20:34, Mike Gran writes: > On Wednesday, September 2, 2015 11:06 AM, Mark H Weaver wrote: > >>Would it help to replace all uses of the term "scan" with "mark", in >>connection with garbage collection? In the papers I've read on GC, >>"mark" is the word I usually see, and it seems much clearer to me, >>because anyone who knows the basics of GC knows that "marking" is needed >>to prevent an object from being freed, whereas "scanning" could mean >>anything. > > That would help, I think. I guess I was associating "scan" with > the "sweep" part of mark and sweep. > > Thanks very much for the clarification. I think "scanning" is a term that is used sometimes, like tracing or visiting. But it's true that in the case of the manual it was used without much context. I made some tweaks that hopefully clarify things, enough to close this bug anyway :) Andy --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=0001-Clarify-use-of-the-term-scanning-in-the-manual.patch >From f84006c5644997ce9854df9070ec2f1fb8acd420 Mon Sep 17 00:00:00 2001 From: Andy Wingo Date: Fri, 24 Jun 2016 08:56:21 +0200 Subject: [PATCH] Clarify use of the term "scanning" in the manual * doc/ref/api-memory.texi (Garbage Collection Functions): * doc/ref/libguile-concepts.texi (Garbage Collection): Attempt to be clear that scanning is a thing that happens in the mark phase. Fixes #20907 I think. --- doc/ref/api-memory.texi | 42 ++++++++++++++++++++---------------- doc/ref/libguile-concepts.texi | 48 ++++++++++++++++++++++++++++-------------- 2 files changed, 56 insertions(+), 34 deletions(-) diff --git a/doc/ref/api-memory.texi b/doc/ref/api-memory.texi index 142eb01..ce0187b 100644 --- a/doc/ref/api-memory.texi +++ b/doc/ref/api-memory.texi @@ -27,9 +27,10 @@ collection relates to using Guile from C. @deffn {Scheme Procedure} gc @deffnx {C Function} scm_gc () -Scans all of SCM objects and reclaims for further use those that are -no longer accessible. You normally don't need to call this function -explicitly. It is called automatically when appropriate. +Finds all of the ``live'' @code{SCM} objects and reclaims for further +use those that are no longer accessible. You normally don't need to +call this function explicitly. Its functionality is invoked +automatically as needed. @end deffn @deftypefn {C Function} SCM scm_gc_protect_object (SCM @var{obj}) @@ -43,8 +44,9 @@ than it has been protected. Returns the SCM object it was passed. Note that storing @var{obj} in a C global variable has the same effect@footnote{In Guile up to version 1.8, C global variables were not -scanned by the garbage collector; hence, @code{scm_gc_protect_object} -was the only way in C to prevent a Scheme object from being freed.}. +visited by the garbage collector in the mark phase; hence, +@code{scm_gc_protect_object} was the only way in C to prevent a Scheme +object from being freed.}. @end deftypefn @deftypefn {C Function} SCM scm_gc_unprotect_object (SCM @var{obj}) @@ -123,16 +125,18 @@ live reference to it@footnote{In Guile up to version 1.8, memory allocated with @code{scm_gc_malloc} @emph{had} to be freed with @code{scm_gc_free}.}. -Memory allocated with @code{scm_gc_malloc} is scanned for live pointers. -This means that if @code{scm_gc_malloc}-allocated memory contains a -pointer to some other part of the memory, the garbage collector notices -it and prevents it from being reclaimed@footnote{In Guile up to 1.8, -memory allocated with @code{scm_gc_malloc} was @emph{not} scanned. -Consequently, the GC had to be told explicitly about pointers to live -objects contained in the memory block, e.g., @i{via} SMOB mark functions -(@pxref{Smobs, @code{scm_set_smob_mark}})}. Conversely, memory -allocated with @code{scm_gc_malloc_pointerless} is assumed to be -``pointer-less'' and is not scanned. +When garbage collection occurs, Guile will visit the words in memory +allocated with @code{scm_gc_malloc}, looking for live pointers. This +means that if @code{scm_gc_malloc}-allocated memory contains a pointer +to some other part of the memory, the garbage collector notices it and +prevents it from being reclaimed@footnote{In Guile up to 1.8, memory +allocated with @code{scm_gc_malloc} was @emph{not} visited by the +collector in the mark phase. Consequently, the GC had to be told +explicitly about pointers to live objects contained in the memory block, +e.g., @i{via} SMOB mark functions (@pxref{Smobs, +@code{scm_set_smob_mark}})}. Conversely, memory allocated with +@code{scm_gc_malloc_pointerless} is assumed to be ``pointer-less'' and +is not scanned for pointers. For memory that is not associated with a Scheme object, you can use @code{scm_malloc} instead of @code{malloc}. Like @@ -193,9 +197,11 @@ Allocate @var{size} bytes of automatically-managed memory. The memory is automatically freed when no longer referenced from any live memory block. -Memory allocated with @code{scm_gc_malloc} or @code{scm_gc_calloc} is -scanned for pointers. Memory allocated by -@code{scm_gc_malloc_pointerless} is not scanned. +When garbage collection occurs, Guile will visit the words in memory +allocated with @code{scm_gc_malloc} or @code{scm_gc_calloc}, looking for +pointers to other memory allocations that are managed by the GC. In +contrast, memory allocated by @code{scm_gc_malloc_pointerless} is not +scanned for pointers. The @code{scm_gc_realloc} call preserves the ``pointerlessness'' of the memory area pointed to by @var{mem}. Note that you need to pass the old diff --git a/doc/ref/libguile-concepts.texi b/doc/ref/libguile-concepts.texi index 9785f4d..e93d987 100644 --- a/doc/ref/libguile-concepts.texi +++ b/doc/ref/libguile-concepts.texi @@ -203,22 +203,38 @@ set'' of garbage collection; any value on the heap that is referenced directly or indirectly by a member of the root set is preserved, and all other objects are eligible for reclamation. -The Scheme stack and heap are scanned precisely; that is to say, Guile -knows about all inter-object pointers on the Scheme stack and heap. -This is not the case, unfortunately, for pointers on the C stack and -static data segment. For this reason we have to scan the C stack and -static data segment @dfn{conservatively}; any value that looks like a -pointer to a GC-managed object is treated as such, whether it actually -is a reference or not. Thus, scanning the C stack and static data -segment is guaranteed to find all actual references, but it might also -find words that only accidentally look like references. These ``false -positives'' might keep @code{SCM} objects alive that would otherwise be -considered dead. While this might waste memory, keeping an object -around longer than it strictly needs to is harmless. This is why this -technique is called ``conservative garbage collection''. In practice, -the wasted memory seems to be no problem, as the static C root set is -almost always finite and small, given that the Scheme stack is separate -from the C stack. +In Guile, garbage collection has two logical phases: the @dfn{mark +phase}, in which the collector discovers the set of all live objects, +and the @dfn{sweep phase}, in which the collector reclaims the resources +associated with dead objects. The mark phase pauses the program and +traces all @code{SCM} object references, starting with the root set. +The sweep phase actually runs concurrently with the main program, +incrementally reclaiming memory as needed by allocation. + +In the mark phase, the garbage collector traces the Scheme stack and +heap @dfn{precisely}. Because the Scheme stack and heap are managed by +Guile, Guile can know precisely where in those data structures it might +find references to other heap objects. This is not the case, +unfortunately, for pointers on the C stack and static data segment. +Instead of requiring the user to inform Guile about all variables in C +that might point to heap objects, Guile traces the C stack and static +data segment @dfn{conservatively}. That is to say, Guile just treats +every word on the C stack and every C global variable as a potential +reference in to the Scheme heap@footnote{Note that Guile does not scan +the C heap for references, so a reference to a @code{SCM} object from a +memory segment allocated with @code{malloc} will have to use some other +means to keep the @code{SCM} object alive. @xref{Garbage Collection +Functions}.}. Any value that looks like a pointer to a GC-managed +object is treated as such, whether it actually is a reference or not. +Thus, scanning the C stack and static data segment is guaranteed to find +all actual references, but it might also find words that only +accidentally look like references. These ``false positives'' might keep +@code{SCM} objects alive that would otherwise be considered dead. While +this might waste memory, keeping an object around longer than it +strictly needs to is harmless. This is why this technique is called +``conservative garbage collection''. In practice, the wasted memory +seems to be no problem, as the static C root set is almost always finite +and small, given that the Scheme stack is separate from the C stack. The stack of every thread is scanned in this way and the registers of the CPU and all other memory locations where local variables or function -- 2.8.3 --=-=-=-- From unknown Sat Aug 16 21:12:32 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 22 Jul 2016 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator