mit-scheme-devel
[Top][All Lists]
Advanced

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

[MIT-Scheme-devel] make-eq-hash-table


From: Taylor R Campbell
Subject: [MIT-Scheme-devel] make-eq-hash-table
Date: Sun, 20 Dec 2009 00:50:31 -0500
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/7.7.90.+

After I changed the microcode to hold only weak references to interned
symbols without global bindings, I noticed a number of problems with
weak hash tables keyed by symbols.  The procedure MAKE-EQ-HASH-TABLE,
counterintuitively to me, yields hash tables with only weak references
to their keys.  Many uses of MAKE-EQ-HASH-TABLE in MIT Scheme actually
need key-strong hash tables, not key-weak hash tables, and after going
through all the uses, I see that the problem is worse than I expected.
Attached to this message is a summary of all sixty-two uses; here are
two noteworthy statistics:

- Only eleven, i.e. 17%, of the uses are obviously legitimate uses for
  key-weak tables.

- Thirteen of the uses are obviously incorrect and require key-strong
  hash tables.  That is, more than 20% of the uses are bugs.

At the very least, we should make sure that every use of hash tables
correctly uses key-strong or key-weak hash tables.  However, I'd like
to go a step further and change the semantics of MAKE-EQ-HASH-TABLE to
yield strong hash tables, and add a separate MAKE-WEAK-EQ-HASH-TABLE
which would behave as MAKE-EQ-HASH-TABLE does currently.

I realize that MAKE-EQ-HASH-TABLE has yielded weak hash tables since
1993, and that its predecessor MAKE-OBJECT-HASH-TABLE has done so for
even longer than that, but since even in MIT Scheme itself there are
more incorrect uses of MAKE-EQ-HASH-TABLE than correct uses (and many
more ambiguous uses where the intent is not clear), I think that it is
dangerous to use the name MAKE-EQ-HASH-TABLE, or any name without the
word `weak' in it, for a constructor of weak hash tables.

If we made this change, existing code using MAKE-EQ-HASH-TABLE
legitimately would exhibit space leaks only on new versions of Scheme.
On the other hand, if we don't make this change, I think that more and
more code will be written that accidentally uses weak hash tables
where strong ones are at best intended or at worst needed, with subtle
heisenbugs that show up depending on when garbage collection happens.

Comments?

Attachment: weakht.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]