Hash tables #1661
Merged
Hash tables #1661
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Move the important code into gctools where it belongs, add support for "weak pointers" of immediate objects (because whether something is immediate is an implementation detail we shouldn't expose).
with many caveats.
this looking for a key simultaneously thing is unused and unclean.
but not gethash, yet, because it gets complicated
it's way too ad hoc - it takes a string stream and a filename and writes to standard output, and calls itself with the print argument flipped anyway? If we run into hash table problems again we can come up with something cleaner or impermanent.
the sxhashKey deferring to static functions in HashTable_O thing has been bugging me for years. begone. Also moves hash stuff out of HashTable_O which is nice for organization. Another bonus: equalp hash on a string no longer conses. I hadn't realized it consed.
Returning a pointer to the inside of a Lisp object is something to avoid, and moreso if it's a bespoke structure. This change breaks Cando, but I've looked at Cando's code and it should work with this fine once I update it.
% is nice
seriously unnecessary. I assume the intent was to avoid consing up a double float object for defaulting, but we do have singles.
again trying to present a coherent API. Also delete an unused function that uses KeyValuePair directly.
i'm reasonably sure this should never be tripped: no_key is not usually available as a value, so nobody's storing it in hash tables from Lisp. In C++ we only put it in the value as the default when we're resizing a table, and in that case we make the key no_key as well. So the only way you'd have a key that's not no_key and a value that is no_key is I think if your hash table is thread unsafe and you store a new key/value in it while another thread looks for that key, and if that's what you're doing you're in crazytown to begin with so the test is not going to help.
The idea is to let external code (e.g. Cando) use these createEq whatevers instead of requiring a HashTableEq type they don't need. This will eventually let me remove the test types or at least make them an internal implementation detail.
this was an optimization of uncertain utility that locks in the type hierardhy, so away it goes
don't need this skulduggery.
The old implementation is still around for now because there's a lot to delete and I'm not sure these new tables will be scanned correctly for snapshots.
the table has to be searched, since afaik there's no way to make boehm decrement a counter when it disappears a pointer. I kept the _Count field so that we don't have to do that iteration when checking for rehash (i.e. every time we setf gethash).
It's still weak, just not a WeakKeyHashTable, which is of course the old code that will be removed.
apparently we don't have a test for this. FIXME
Probably need to make the scanner a little more sophisticated for ephemerons and stuff. weak_scan is busted down to nothing here.
I don't think it really does us any good. Each kind of weak object pretty much needs to be scanned (or not) in its own special way so grouping them doesn't accomplish anything. If we ever have separate pools for them like we did with MPS, they can just have normal general headers.
Not useful yet but it took me a while to figure it out
This should allow us to smoothly support objects with Lisp pointers more than 62 words in. Also, I don't think the Lisp object is even actually that big right now - presumably it used to be - so this might save us a microsecond of scanning time as we use the bitmap.
Kind of inelegant but seems to work. The separate weak pointer scanning could be used for implementing a garbage collector. Also clears out some of the debugging stuff - we can do the field check when we set up the field info, not every single time we scan
and make them traversable through ROOM There may be an issue with the previous commit alone - it may not allocate enough field infos/layouts in gc_boot. The fact the memory walker uses T_O** fields is kind of dicey since not all fields are actually pointers to pointers. We have the hidden pointers in ephemerons, but also atomics in conses etc.
Saves us a dumb lookup (in find) and will be nice for keeping the value alive when doing weak tables.
Since the analyzer knows about WeakPointer now, there's no point in making it generic
They don't and I think can't work with boehm gc, but the code's there for later.
most importantly, test that they actually are weak. I don't think they were before my rewrite.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rewrites and fixes weak hash tables and weak pointers.