[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
hash tables and GC
- To: firstname.lastname@example.org
- Subject: hash tables and GC
- From: email@example.com
- Date: Thu, 21 Jul 88 09:33:27 PDT
- Cc: firstname.lastname@example.org
- Posted-date: Thu, 21 Jul 88 09:33:27 PDT
- Sender: email@example.com
Apropos of hash tables, one feature of Pop(Log) that I sometimes want
to have is "temporary properties". They are essentially hash tables
such that being in them does not prevent being garbage collected. An
object might have a property (in this table) and nonetheless be
collectable. Is there some problem with such tables that makes them
not a good idea? They certainly seem to be something users can't
write for themselves.
I'm not sure just what you mean by "being in" a hash table. I have
commonly seen the following case -- is it what you have in mind?
I have an EQ hash table H. My program will never apply the MAPHASH accessor
to H. Therefore, the fact that H is accessible to my program does NOT
imply that any of the keys or values are accessible. If the pair [K V]
is in the table, then if K is independently accessible, V is also
accessible. But if K is not independently accessible, it is garbage, and
so is V unless V is independently accessible.
Do any implementations have "non-mappable" hash tables and a Garbage
Collector that takes this into account? [The condition that the hash
table equivalence be EQ was only stated to make the explanation simple to
follow intuitively. If we think of the key K as an exemplar of
some equivalence class, and regard the phrase "K is independently
accessible" as meaning "some element of the equivalence class
containing K is independently accessible", then the rationale holds
regardless of the table's equivalence predicate, and can, in fact, be
conservatively followed for EQL and EQUAL hash tables.