I should have remembered this (I missed Julian's talk at JSConf.eu,
alas). CC'ing.
/be
Nicolas B. Pierron <mailto:[email protected]>
January 2, 2014 12:47 PM
I should have wrote that with a past tense …
https://github.com/jviereck/regexp.js
Just by looking at the slides he made for the JSConf.eu, I can see an
image which seem to correspond to IonGraph output (a way to
graphically spew the SSA representation of the generated assembly)
I have not yet tested the performances on octane, but knowing that the
state of the JIT is not complete, I guess this is unlikely to compete
out of the box.
Nicolas B. Pierron <mailto:[email protected]>
January 2, 2014 10:31 AM
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.
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
