122891 2013-10-16 05:27:03 -0700 Yarr does not compile Peacekeeper email validation regex 2013-10-21 05:16:41 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified UNCONFIRMED P2 Normal --- 0 jdemooij webkit-unassigned barraclough benjamin msaboff ossy pvarga sam oldest_to_newest 940356 0 214358 jdemooij 2013-10-16 05:27:03 -0700 Created attachment 214358 Shell testcase I'm attaching a simple shell version of Peacekeeper's stringValidateForm test. The good news is that Yarr is able to compile 4 of the 5 regular expressions. The bad news is that the other regex is interpreted and this slows us down. If I run the test in Safari it takes 1200 ms, with the email regex commented out it's 460 ms so the slow regex is where we spend most of our time on this test. The email validation part is this: input = "jaakko.alajoki@futuremark.com"; result = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(input); 940357 1 jdemooij 2013-10-16 05:29:47 -0700 Yarr JIT compilation is aborting here I think: // We can currently only compile quantity 1 subpatterns that are // not copies. We generate a copy in the case of a range quantifier, // e.g. /(?:x){3,9}/, or /(?:x)+/ (These are effectively expanded to // /(?:x){3,3}(?:x){0,6}/ and /(?:x)(?:x)*/ repectively). The problem // comes where the subpattern is capturing, in which case we would // need to restore the capture from the first subpattern upon a // failure in the second. 940439 2 barraclough 2013-10-16 10:52:09 -0700 Yarr JIT now compiles regular expressions twice, in one of two mode – 'match-only', and 'include-subpatterns'. Match-only is used for when the regexp is first run, to scan for the match, at which point we return a boolean result (in the case of 'test' matches), or returned as a lazily populated regexp matches array object. Include-subpattens is used when an subpatten match is explicitly required, for example if an entry in the matches array is accessed. The restriction referenced in the comment is that the JIT won't backtrack sub pattern matches, so we can't compile quantified captures unless we can guarantee they won't backtrack. But this restriction doesn't apply for match-only compilations, which aren't recording the matched sub patterns anyway. We can probably pretty much say, if (compileMode == MatchOnly) then we can compile any parens. We'd have to look a little more closely to check whether any of the restrictions still need to apply. 940595 3 barraclough 2013-10-16 17:13:45 -0700 Actually, no, I'm way oversimplifying here. :-( – each iteration would also need separate backtracking state internally, so this does effectively demand stack allocation. 214358 2013-10-16 05:27:03 -0700 2013-10-16 05:27:03 -0700 Shell testcase test.js application/x-javascript 664 jdemooij ZnVuY3Rpb24gcnVuKCkgewogICAgLy8gcHcgc3RyZW5ndGgKICAgIGlucHV0ID0gInBhc3N3b3Jk MSI7CiAgICByZXN1bHQgPSAvXig/PS57OCx9KSg/PS4qW0EtWl0pKD89LipbYS16XSkoPz0uKlsw LTldKSg/PS4qXFxXKS4qJC9nLnRlc3QoaW5wdXQpOwogICAgcmVzdWx0ID0gL14oPz0uezcsfSko KCg/PS4qW0EtWl0pKD89LipbYS16XSkpfCgoPz0uKltBLVpdKSg/PS4qWzAtOV0pKXwoKD89Lipb YS16XSkoPz0uKlswLTldKSkpLiokL2cudGVzdChpbnB1dCk7CiAgICByZXN1bHQgPSAvKD89Lns2 LH0pLiovZy50ZXN0KGlucHV0KTsKCiAgICAvLyBlbWFpbAogICAgaW5wdXQgPSAiamFha2tvLmFs YWpva2lAZnV0dXJlbWFyay5jb20iOwogICAgcmVzdWx0ID0gL15cdysoW1wuLV0/XHcrKSpAXHcr KFtcLi1dP1x3KykqKFwuXHd7MiwzfSkrJC8udGVzdChpbnB1dCk7CgogICAgLy8gcGhvbmUKICAg IGlucHV0ID0gIjA1MCAzNDIgMTI1MiI7CiAgICByZXN1bHQgPSAvXlwoWzEtOV1cZHsyfVwpXHM/ XGR7M31cLVxkezR9JC8udGVzdChpbnB1dCk7Cn0KZnVuY3Rpb24gdGVzdCgpIHsKICAgIHZhciB0 ID0gbmV3IERhdGU7CiAgICBmb3IgKHZhciBpID0gMDsgaSA8IDEwMDAwMDA7IGkrKykKCXJ1bigp OwogICAgcHJpbnQobmV3IERhdGUgLSB0KTsKfQp0ZXN0KCk7Cg==