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

MAKUNBOUND



At one time, GLS and I worked out the logic that has put us in the 
current bind (no pun!): the information as to whether or not a 
value-cell is needed by compiled code can only be kept in the symbol
block of the symbol;  thus if a value-cell is disconnected from its
symbol, then it must be reclaimed, for there is no provision to sweep
the value-cell space.  Of course, if a symbol itself is being swept
up due to nothing at all pointing to it, or due to it being a TWA
(herein defined to be a symbol with no properties on its PLIST, one
which is not BOUNDP, and is on at most the current obarray) then
the value-cell pointed to that symbol may be explicitly reclaimed
(again excluding SUNBOUND). The sad part about the latter reclamation
scheme is that it prevents two symbols from sharing a value cell
(for what if one is swept and the other is not?).  At any rate, there
would seem to be little loss if we removed the explicit-reclamation
code from MAKUNBOUND, since most value-cells to be reclaimed could
be ggrabbed by the explicit symbol-sweeper.
  The currently-rejected alternative is to have two bit-blocks for
each value-cell segment, one which would be a standard mark-bit
bit-block for the GC marker to use, and the other to be a sort of
CCN-bit bit-block for FASLOAD and GCPROTECT to use.  Currently
LAP makes a distinction when it calls GCPROTECT by giving a second
arg VALUE in one case, and T in all others; but GCPROTECT merges all
non-NIL (and non-?) second args into the T case.