Ultimately I'm sort of pessimistic about table-less interning, because it proposes to speed up parsing at the expense of layout. I think that's a tradeoff we wouldn't want to make unless the cost/benefit ratio is really favorable.
Storing small strings immediate and using a table for the rest seems promising, though. I also liked the idea of using Gecko to gather information about interned strings. keegan ----- Original Message ----- From: "Keegan McAllister" <kmcallis...@mozilla.com> To: "Patrick Walton" <pcwal...@mozilla.com> Cc: danielmi...@gmail.com, dev-servo@lists.mozilla.org, "edy burt" <edy.b...@gmail.com> Sent: Thursday, April 24, 2014 2:07:38 PM Subject: Re: [dev-servo] Table-less string interning > A collision in a widely used cryptographic hash would be a major, > publishable security advance. That's true for SHA-256 itself. But I ran the numbers, and it turns out brute force search for a collision on a 128-bit hash (even with no algorithmic weakness) is feasible. I wrote more on the GitHub ticket. I think the per-session random secret would fix this issue, but I will think about it more. And it will slow things down at least some. (cc:ing some people I discussed this with on IRC) > As an added note, looks like Skylake is going to have SHA instructions Yeah, that's one reason to pursue this approach. If we can access crypto accelerators on mobile, it might be an even bigger win there. We could even support SHA interning alongside table-based interning, and select one based on the availability of crypto acceleration. keegan _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
