On 2/7/2014, 4:11 PM, Nicholas Nethercote wrote:
On Fri, Feb 7, 2014 at 8:31 AM, Kannan Vijayan <[email protected]> wrote:
Atomizing string literals is definitely a good idea, although it might make
sense to put a length limit - say 32 or 64 chars (do we already do this,
maybe?).
We don't. If there were some places where we might atomize and might
not, then we couldn't use pointer-equality for string-equality, thus
losing a major advantage of atoms. (Thanks to Jan for reminding me of
this advantage.)
The reason I've been thinking about this is that the atoms table can
get large. In my current browser session the atoms table for the main
JSRuntime is 8 MiB. That's not a big deal on desktop, but it is a big
deal on B2G. But this seems hard to change.
However, it's not the only cost -- there's also the hashing (time)
cost. For very long strings this cost is high. I wonder if we should
change AtomHasher to look at only the first N and last N chars in the
string when computing the hash, where N might be, say, 100.
Nick
Not hashing the entire string sounds like a collision attack vector.
Any app or page coded in such a way as to enable an attacker to create
interned strings would open the browser to a DoS attack.
Can we just skip big strings? What's the point in interning them?
Identity operations are rare on big strings - we typically only care
about their content.
That said, I'm not sure if removing big strings will bring the table
size down all that much. I'd anticipate most of the atoms table is
small strings.
To what degree can we share the atoms table between different runtimes?
Would it be possible to have a single shared runtime, with a single
compartment, which holds the atoms for all other compartments in all
other runtimes?
Kannan
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
