[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCM_BOOL_F == 0 and BDW-GC
From: |
Neil Jerram |
Subject: |
Re: SCM_BOOL_F == 0 and BDW-GC |
Date: |
Thu, 17 Sep 2009 23:00:33 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Hello!
>
> Neil Jerram <address@hidden> writes:
>
>> Just checking this because Ludovic said recently that (SCM_BOOL_F ==
>> 0) would have nice properties for BDW-GC.
>
> Actually he wasn't quite right when he said that. :-)
>
> The issue with BDW-GC is that "disappearing links" (weak pointers in
> libgc parlance) replace pointers to objects that have been reclaimed by
> NULL, and there's no way to tell it to use some other value.
>
> That leads to insanities in the weak hash table implementation [0, 1],
> which I thought could somehow vanish if SCM_BOOL_F == 0.
They're not so bad. But I agree that it would be nicer not to have to
use SCM_WEAK_PAIR_CAR, and just use SCM_CAR instead.
> Unfortunately that's not true; it would even make things worse because
> NULL would now be a valid Scheme value.
Yes, I see.
> Instead what's really needed is a special pointer-to-reclaimed-object
> value that can be distinguished from valid Scheme values since that
> value ends up in the car or cdr of weak pairs in hash table buckets. As
> such, SCM_PACK (NULL) was a good choice until now.
Here I'm confused again. I thought we now had no choice about the
pointer-to-reclaimed-object value, because BDW-GC always uses NULL.
> SCM_UNDEFINED == 0 would work fine because SCM_UNDEFINED is not a valid
> Scheme value, but it wouldn't change the implementation.
I'm afraid I don't understand "but it wouldn't change the
implementation".
0 is also used for procedures that haven't been extended to
primitive-generic - see SCM_SUBR_GENERIC - but I think making
SCM_UNDEFINED == 0 would be fine there too.
> Thoughts?
SCM_UNDEFINED == 0 is sounding promising...
Neil
- Re: SCM_BOOL_F == 0 and BDW-GC,
Neil Jerram <=