On Fri, Feb 7, 2014 at 1:40 PM, Kannan Vijayan <[email protected]> wrote: >> >> 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.
Atomization != interning. I believe only a small fraction of strings that are atomized are interned, though I haven't measured. I don't think DoS is possible; the only bad behaviour you could get by ignoring some of the chars in a string when atomizing is an increase in the collision rate in the atoms table. And as I said before, choosing to not atomize based on length is a bad idea: if 99% of the strings you deal with in a particular place are atomized, but 1% are not, then you can't use pointer equality. > 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. Correct. > 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? I believe bhackett has this in his sights. It'll help with the space issue. Nick _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
