[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20907: [PATCH] Manual bug for scm_gc_protect_object

From: Mark H Weaver
Subject: bug#20907: [PATCH] Manual bug for scm_gc_protect_object
Date: Wed, 02 Sep 2015 12:52:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> Mike Gran <address@hidden> writes:
>>> On Wednesday, September 2, 2015 5:09 AM, Ludovic Courtès <address@hidden> 
>>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]