[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
- Need for scm_remember_upto_here_* in guile-2.0, Chris Vine, 2015/09/12
- Re: Need for scm_remember_upto_here_* in guile-2.0, Ludovic Courtès, 2015/09/22
- Re: Need for scm_remember_upto_here_* in guile-2.0, David Kastrup, 2015/09/22
- Re: Need for scm_remember_upto_here_* in guile-2.0, Mark H Weaver, 2015/09/22
- Re: Need for scm_remember_upto_here_* in guile-2.0,
David Kastrup <=
- Re: Need for scm_remember_upto_here_* in guile-2.0, Ludovic Courtès, 2015/09/22
- Re: Need for scm_remember_upto_here_* in guile-2.0, Chris Vine, 2015/09/22
- Re: Need for scm_remember_upto_here_* in guile-2.0, Chris Vine, 2015/09/22
- Re: Need for scm_remember_upto_here_* in guile-2.0, David Kastrup, 2015/09/23
- Re: Need for scm_remember_upto_here_* in guile-2.0, Chris Vine, 2015/09/23
- Re: Need for scm_remember_upto_here_* in guile-2.0, David Kastrup, 2015/09/23
- Re: Need for scm_remember_upto_here_* in guile-2.0, Chris Vine, 2015/09/23
- Re: Need for scm_remember_upto_here_* in guile-2.0, David Kastrup, 2015/09/23
- Re: Need for scm_remember_upto_here_* in guile-2.0, Chris Vine, 2015/09/23