JSRuntime::staticStrings is a mapping from small integers to the atom for that integer. This is a fast path for int->atom->id conversion during getElement. This table is currently 36KiB, stored inline in the JSRuntime. For B2G and workers, we should be able to easily save a bunch of memory by reducing the size of this table at the cost of extra overhead for a larger number of indexed accesses using small numbers.

JSRuntime::staticStrings is identical for every JSRuntime, right? Is there some way to share it among runtimes?

(In reply to Nicholas Nethercote [:njn] from comment #1) > JSRuntime::staticStrings is identical for every JSRuntime, right? Is there > some way to share it among runtimes? I don't know much about it, but I felt that it was lazily filled by the parser.

The runtime's static strings and common names are not identical for every runtime, since the atoms in them are specialized on that particular runtime. If we were able to share atoms between runtimes (bug 964059) then the tables would be identical and we could use a single set for all runtimes.

How are static strings not identical between runtimes? I can't see how they would differ. ("Common names" might differ; I don't know what those are.) Having a global static strings table instead of one per runtime is definitely a good idea. I'm much more wary about shrinking the number of elements in the static strings table -- we currently don't use static strings as much as we could. I've seen about:memory results where we have MBs worth of single-char ASCII strings, which really should be handled via static strings, and I'm planning to try to get them used more, because it will save memory and reduce pressure on the GC.

The contents of the strings are the same, but the physical pointers are different. If we shared a table between runtimes right now then one runtime could have pointers to another runtime and potentially run into trouble (races, crashes, ...) when e.g. that other runtime is doing an incremental GC. Some more in bug 964059. Now, this case is likely simpler than that bug since the static strings can't actually be collected, but since 964059 subsumes this and makes additional improvements to memory usage it seems better to me to do that one and then get this for free rather than doing this one separately.

Great! Sharing the table between runtimes would be great. Making the table smaller (as comment 0 suggested) would not be great, IMO. I've changed the bug title accordingly.