Consider using indices instead of pointers for Map/Set hash table chains
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: jandem, Unassigned)
References
(Blocks 1 open bug)
Details
We currently store a pointer to the array entry for the hash table chains, but we could replace this with the index of the entry. This has a few advantages:
- When we move the buffer in memory during GC (see bug 1928666 part 4) we don't have to fix up these pointers.
- It lets us shrink the hash table array on 64-bit (4 bytes per entry instead of 8 bytes).
- I think the data entries will have 4 unused padding bytes. We could either split this in two arrays (a bit annoying), or use those 4 bytes for something else, maybe to cache the hash number.
The downside is that this makes the lookup a bit more complicated, especially in JIT code.
Reporter | ||
Comment 1•9 months ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #0)
The downside is that this makes the lookup a bit more complicated, especially in JIT code.
This could be mitigated a bit by storing the chain index relative to the current entry's address, so instead of entry = data[entry.chain]
we'd do entry = entry + entry.chain
. This way we don't have to reload the data
array (or keep it in a register).
I think it's also the case that an entry's chain always points to a previous entry in the array so maybe it could be entry = entry - entry.chain
.
Updated•9 months ago
|
Description
•