Open Bug 1931492 Opened 9 months ago Updated 9 months ago

Consider using indices instead of pointers for Map/Set hash table chains

Categories

(Core :: JavaScript Engine, task, P3)

task

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.

(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.

Blocks: sm-js-perf
Severity: -- → N/A
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.