guile-user
[Top][All Lists]
Advanced

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

Re: Need for scm_remember_upto_here_* in guile-2.0


From: David Kastrup
Subject: Re: Need for scm_remember_upto_here_* in guile-2.0
Date: Tue, 22 Sep 2015 19:08:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> In practice scm_remember_upto_here_* is useless with libgc, since libgc
>>> also tracks pointers in registers.
>>
>> Sounds like a big non-sequitur.  scm_remember_upto_here_* is for keeping
>> SCM values active (including in registers).  Any conversion of an SCM
>> value to some other data depending on it will not protect the SCM value
>> as such and may lead to collection/finalization of the SCM cell (calling
>> guardians, removing from weak hashtables and so on).
>
> I think David is right.  Consider the following case: a SMOB contains a
> pointer to a block allocated by 'malloc' and freed by the SMOB freeing
> procedure.  Some C code starts with a SCM value for that SMOB, uses it
> to obtain a pointer to the malloc'd block, and then discards the SCM
> value and proceeds to do a long-running job on the malloc'd block.  If
> there are no other references to the SCM value, Boehm GC can free the
> SMOB and call its finalizer, which frees the malloc'd block.  The
> long-running job in C continues to access the freed block.
>
> Am I missing something?

Well, the underlying idea was probably not to free any memory in the
finalizer and have the malloc'd block be independently protected/freed
by libgc.  If you do things like that, you don't have any structural
integrity associated with an SCM value.  Its various components will be
independently protected from low-level collection by libgc and the SCM
value might be gone/finalized considerably before processing on parts of
it ends.

At any rate, the statement at issue was

>>> In practice scm_remember_upto_here_* is useless with libgc, since
>>> libgc also tracks pointers in registers.

and registers containing SCM values were already tracked in version 1.8
(since registers are saved in the stack frame when functions possibly
invoking a garbage collection are called, tracking SCM values in
registers is not a challenge separate from marking the whole stack).
scm_remember_upto_here_* is not about SCM values being in registers but
rather about the compiler not bothering to keep them around at all.

-- 
David Kastrup



reply via email to

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