[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
hash arrays & gc
- To: hartley at BBNB
- Subject: hash arrays & gc
- From: DEUTSCH
- Date: Tue, 29 Apr 1975 14:14:25 -7000
- Date: 29 APR 1975 1414-PDT
- Cc: teitelman, bobrow, lewis at BBNB
Well, I'm glad to learn I'm not alone in being bitten by this bug.
The logical problem is fairly subtle. I'm not willing to give up
MAPHASH (and I see it as being different than MAPATOMS in that it
requires an explicit act to create and delete hash associations whereas
atoms are created "at need" and therefore may more reasonable be
reclaimed "when no longer needed"). What is really going in is that
some hash arrays are sort of like property list associations,
which persist indefinitely even if the user has forgotten all about
the atom that possesses them, whereas others are more like associations
by direct pointers (like list-records), which disappear when the key
is no longer accessible. Litatoms can possess both types of
associations: an example of the former is the EXPR property, whereas
a "memo function" like a numeric hash from the name might be an example
of the latter property.
I confess I don't see a good solution to this problem. The one that
comes to mind is a bit in the hash array that tells the g.c. whether
it is allowed to delete entries, but somehow this is unsatisfying.
However, if (as it appears) the difference between the two situations
is really the user's "intent", then there is no way the system can
always do the right thing, and some kind of explicit user-settable bit
is really required.