On 01/02/2014 06:46 AM, Jan de Mooij wrote:
(3) Write something ourselves, probably based on V8's irregexp.
[…]
Personally, I like (3): it's not a small task, but it'd finally give us a
regexp engine that integrates well with the rest of the engine. This also
means we can dump JSC's macro-assembler (JM used it as well, but is also
gone) and use the one we wrote for the baseline/Ion JITs. It'd also
integrate much better than Yarr in terms of code style and data structures.
If we base it on irregexp, we should be able to avoid most pitfalls or
design problems.
What do people think?
I do not know much about YARR, but I saw a few sec-critical patches related
to it before. At the moment, on octane, we still have to go from JITed code
-> C++ -> YARR's code.
I think we can do better by implementing a regexp compiler which *targets*
JavaScript instead of assembly. By generating asm.js-like code for regexp,
we can have good generated code and we can easily apply all the rules we
already have for calling / *inlining* them in Ion code.
This approach has obvious disadvantages:
- we serialize the code in JavaScript.
On the other hand:
- we reduce the surface of attacks.
- we can test it on other JS engines.
- we do not have to add extra logic for inlining regex.
In addition, one might even suggest that we self-host the regex compiler. If
this is not a performance issue, I think this would be a good idea as the
first persons who are willing to get features in the JavaScript Regex engine
are JavaScript users.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
