[pypy-commit] stmgc hashtable: update comments
arigo
noreply at buildbot.pypy.org
Mon Jan 19 18:35:43 CET 2015
Author: Armin Rigo <arigo at tunes.org>
Branch: hashtable
Changeset: r1550:073ff03f2316
Date: 2015-01-19 18:35 +0100
http://bitbucket.org/pypy/stmgc/changeset/073ff03f2316/
Log: update comments
diff --git a/c7/stm/hashtable.c b/c7/stm/hashtable.c
--- a/c7/stm/hashtable.c
+++ b/c7/stm/hashtable.c
@@ -6,8 +6,14 @@
length 2**64. Initially it is full of NULLs. It's obviously
implemented as a dictionary in which NULL objects are not needed.
-The only operations on a hashtable are reading or writing an object at
-a given index.
+A real dictionary can be implemented on top of it, by using the index
+`hash(key)` in the hashtable, and storing a list of `(key, value)`
+pairs at that index (usually only one, unless there is a hash
+collision).
+
+The main operations on a hashtable are reading or writing an object at a
+given index. It might support in the future enumerating the indexes of
+non-NULL objects.
There are two markers for every index (a read and a write marker).
This is unlike regular arrays, which have only two markers in total.
@@ -18,8 +24,8 @@
First idea: have the hashtable in raw memory, pointing to "entry"
objects. The entry objects themselves point to the user-specified
-objects, and they have the read/write markers. Every entry object
-itself, once created, stays around. It is only removed by the next
+objects. The entry objects have the read/write markers. Every entry
+object, once created, stays around. It is only removed by the next
major GC if it points to NULL and its read/write markers are not set
in any currently-running transaction.
More information about the pypy-commit
mailing list