1872226 - Use separate permanent atom table for well-known atoms with JS::WellKnownAtomId as entry

Status: ASSIGNED

(Core :: JavaScript Engine, task, P3)

Description

[Tooru Fujisawa [:arai]]

Once the well-known atom table gets automatically generated and we have 1:1 mapping from JS::WellKnownAtomId to all permanent atoms, except for self-hosted atoms,
we can use JS::WellKnownAtomId as the permanent atoms table entry, instead of JSAtom* pointer.

This can:

• remove unnecessary tracing on permanentAtoms
• reduce the size of permanentAtoms table (8 bytes pointer -> 4 bytes index)

https://searchfox.org/mozilla-central/rev/fc00627e34639ef1014e87d9fa24091905e9dc5d/js/src/vm/Runtime.h#789

js::WriteOnceData<js::FrozenAtomSet*> permanentAtoms_;

https://searchfox.org/mozilla-central/rev/fc00627e34639ef1014e87d9fa24091905e9dc5d/js/src/vm/AtomsTable.h#39-40

class AtomSet : public JS::GCHashSet<WeakHeapPtr<JSAtom*>, AtomHasher,
                                     SystemAllocPolicy> {

Comment 1

[Tooru Fujisawa [:arai]]

This is necessary for extended-known atoms (bug 1848278).
We'll have ~10000 extended-known atoms for DOM bindings, and permanentAtoms table becomes 192kB (from 32kB) with the current structure,
which hits awsy regression.
reducing the size of the table entry should help here.

Comment 2

[Tooru Fujisawa [:arai]]

We could also look into moving the hash data from the table to referred entry.
WellKnownAtomInfo already contains the hash data (it's different than the hashtable's hash, because of preparehash, but it's simple operation),
and there's almost no need to put the hash also into the table.

The current hash table entry is 12 bytes (4 bytes hash + 8 bytes pointer).
once we switch to JS::WellKnownAtomId, it becomes 8 bytes (4 bytes hash + 4 bytes id),
and if we move the hash out of the table, it can be 4 bytes (only id).

This can also be applied to other tables, such as other atoms.

Comment 3

[Tooru Fujisawa [:arai]]

Given the all items are known at compile-time and hash is also known, we could use the perfect hash here,
so that the atom table can be put into static data, which can be shared across processes, and also we don't have to worry about the prepareHash operation and the free/removed/conflict flags.
This also helps reducing the table size, by omitting the "free" space, which comes from the HashSet table size being 2**n.

Comment 4

[Tooru Fujisawa [:arai]]

The planned optimization for well-known parser atom table lookup (bug 1849498, bug 1849490, bug 1802568) needs to be rewritten after this