[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MAKUNBOUND
- To: (BUG LISP) at MIT-MC
- Subject: MAKUNBOUND
- From: JONL at MIT-MC (Jon L White)
- Date: Tue, 18 Jul 78 03:09:00 GMT
- Cc: JPG at MIT-MC
- Original-date: 17 JUL 1978 2309-EDT
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.