[WIP] Port Remacs Lisp_Hash_Table to use FnvHashMap. #286
Conversation
… the new LispHashTable struct.
…y for the GC to find and cleanup these new objects
…the new LispHashTable.
…eems to be working so far.
…mance by saving an iteration over the data. Adding more tests
…ill now have the ability to easily have per object type free lists.
… a pseudovector with a LispVectorlikeHeader.
…t with methods. This makes testing much easier, as we can create an instance of the GC per test. We create a helper macro to use the default static GC.
…cro, due to mod alloc being imported AFTER mod hashtable
…inline with the C's block allocator.
…ce. Updating the garbage collector to reduce the amount of hash table allocations in a block from 4096 Hash Tables to 4096 bytes worth of hash tables.
…ox<...>> to just Vec<...>. Adding some inline directives for small functions. Adding some more GC related tests.
…g the hashtable over proved to be too much for a single PR. Instead we will work with the current GC, adding a minimal amount of C code needed to support this functionality.
… to clear the table, and the ability to get it's count.
…ons for hash table entry.
…rt of integrating our new hash table type into the lisp gc.
…n hold different symbol values based on weak gc behavior
…e new LispHashTable. This function has undergone basic testing, and seems to be working.
…er to using a new Rust struct. We first update the Rust to assume that it is the definitive Hash Table struct.
…e a GC is in progress
… weak hash table sweep, which would cause undefined behavior.
…e. Reduction of memory footprint of a LispHashTable.
… entries. A C layer API can cause these two structures to become desync'd.
…uture hashlook would return the wrong value.
|
So this is making good progress, and all but one testing is passing! This ended up being slightly more difficult then I anticipated, due to the fact that most of the C-layer makes a lot of assumptions about the internals of HashTables and how they work. I need to spend some time benchmarking and optimizing this guy to make sure that we are still getting the advertised gains, but I hope to have this PR ready for wide-review by the end of the month. |
Conflicts: rust_src/Cargo.toml rust_src/alloc_unexecmacosx/src/lib.rs rust_src/remacs-sys/lib.rs rust_src/src/hashtable.rs rust_src/src/lib.rs rust_src/src/lisp.rs src/lisp.h
…ting hash key update to properly update our hashkey for both the map and the key and value array.
Conflicts: rust_src/src/lib.rs
Conflicts: rust_src/src/lisp.rs
…rnal hashmap. Adding some asserts to track down an OSX Segfault issue.
Conflicts: rust_src/src/lib.rs
…serts that are no longer needed.
…00% consistent with their previous incarnations, including the free list.
|
After a long journey, and a lot of code, I am going to advise that we do not use Rust's HashMap at this time, and that we make a straight port of existing HashTable code. Reasons:
If no one objects, I am going to close this PR, and will open on a PR that focuses on converting the existing HashTable from C to Rust piecemeal. |
|
If you think that's the best solution do it. Maybe we should avoid making things too complicated for now. |
|
Whilst this hasn't resulted in us landing code that uses FnvHashMap, it's a really useful conclusion. Thanks for exploring this so thoroughly! Could you comment on where the code assumes that it can mutate keys in hash tables? I would have thought we will eventually want to refactor that out. |
This is the WIP commit for #276.
TODO List: