[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hash tables and GC
- To: email@example.com, jeff <@NSS.Cs.Ucl.AC.UK:firstname.lastname@example.org>
- Subject: Re: hash tables and GC
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Fri, 22 Jul 88 18:23:53 BST
- Cc: email@example.com
> From: firstname.lastname@example.org
> Subject: hash tables and GC
> Date: Thu, 21 Jul 88 09:33:27 PDT
> > 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.
> 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.
Yes, that's what I had in mind, except for one thing:
Even if you do a MAPHASH, there is no way for you to tell K should be
in the table (or even that it exists) unless you have independent
access to it. So, the possibility of MAPHASH would still allow K
and V to be removed. Of course, you could gather various statistics
with MAPHASH that would change if K were removed (e.g., the number of
keys would decrease), but I think that's OK.
Indeed, T had something called "populations" (now called "weak sets")
that did not prevent GC of their elements and that supported an
operation call walk-population. They are somewhat less useful that
what I have in mind, though, because all you can ask is whether
something's in the population or not (i.e., whether it's a K --
there's no associated V).