unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Mike Gran <spk121@yahoo.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, 20907@debbugs.gnu.org
Subject: bug#20907: [PATCH] Manual bug for scm_gc_protect_object
Date: Wed, 02 Sep 2015 12:52:54 -0400	[thread overview]
Message-ID: <87mvx4226x.fsf@netris.org> (raw)
In-Reply-To: <87r3mg23wc.fsf@netris.org> (Mark H. Weaver's message of "Wed, 02 Sep 2015 12:16:03 -0400")

Mark H Weaver <mhw@netris.org> writes:

> Mike Gran <spk121@yahoo.com> writes:
>
>>> On Wednesday, September 2, 2015 5:09 AM, Ludovic Courtès <ludo@gnu.org> 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. 
>>
>>
>> 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





  reply	other threads:[~2015-09-02 16:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26 23:00 bug#20907: [PATCH] Manual bug for scm_gc_protect_object Mike Gran
2015-09-02  1:59 ` Mark H Weaver
2015-09-02 12:08   ` Ludovic Courtès
2015-09-02 15:36     ` Mike Gran
2015-09-02 16:16       ` Mark H Weaver
2015-09-02 16:52         ` Mark H Weaver [this message]
2015-09-02 17:12         ` Mike Gran
2015-09-02 18:05           ` Mark H Weaver
2015-09-02 18:34             ` Mike Gran
2016-06-24  6:58               ` Andy Wingo

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=87mvx4226x.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=20907@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=spk121@yahoo.com \
    /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).