If a stack overflow occurs inside the regexp parser, propagate that
information to the parser.
Bug: v8:896,chromium:1243989
Change-Id: I5ced27ff968ad97764e156643e1980b3a722af1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3127717
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76568}
This CL implements early SyntaxErrors for regular expressions. Early
errors are thrown when a malformed pattern is parsed, rather than when
the code first runs.
We do this by having the JS parser call into the regexp parser when
a regexp pattern is found. Regexps are expected to be relatively
rare, small, and cheap to parse - that's why we currently accept that
the regexp parser does unnecessary work (e.g. creating the AST
structures).
If needed, we can optimize in the future. Ideas:
- Split up the regexp parser to avoid useless work for syntax validation.
- Preserve parser results to avoid reparsing later.
Bug: v8:896
Change-Id: I3d1ec18c980ba94439576ac3764138552418b85d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3106647
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76502}
.. and decrease the include-ball size.
Change-Id: Id35358a6882156f6684475b7f0b0193f8ca5eaf5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103313
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76386}
In follow-up work, the parser will be refactored to take the input as
raw char arrays instead of a FlatStringReader s.t. it can be reused by
the V8 parser (which has AstRawStrings instead of Strings).
Bug: v8:896
Change-Id: I0e0bda4b34bc23b8bc427ddf3f9516081c42bb8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099947
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76359}
V8 implements a fast-path for RegExp.prototype.split which diverges
from the spec: instead of creating a new sticky regexp instance
`splitter` and running it in a loop, we reuse the existing non-sticky
regexp without looping through each character.
This works fine in most cases, but we run into issues when matching at
the very end of the string. According to the spec, matches at the end
of the string are impossible in @@split, but in our fast-path
implementation they can happen.
The obvious fix would be to remove our fast-path but this comes with
high performance costs. The fix implemented in this CL adds a special
flag to `exec` s.t. matches at the end of the string can be treated as
failures. This is only relevant for @@split.
Bug: chromium:1075514
Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72644}
This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
that forces execution in linear time. These regexps are handled by the
experimental engine. If the experimental engine cannot handle the
pattern, an exception is thrown on creation of the regexp.
The commit also adds a new global V8 flag and changes an existing one:
* --enable-experimental-engine, which turns on recognition of the RegExp
'l' flag. Previously this flag also caused all supported regexps to
be executed by the experimental engine; this is not the case anymore.
* --default-to-experimental-regexp-engine takes over the previous
semantics of --enable-experimental-regexp-engine: We execute all
supported regexps with the experimental engine.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#70892}
We fall back from irregexp to the experimental engine if a backtrack
limit is exceeded and the experimental engine can handle the regexp.
The feature can be turned on with a boolean flag, and an uint-valued
flag controls the default backtrack limit. For regexps that are
constructed with an explicit backtrack limit (API,
%NewRegExpWithBacktrackLimit), we choose the lower of the explicit and
default backtrack limits.
The default backtrack limit does not apply to regexps that can't be
handled by the experimental engine, and for such regexps an explicitly
specified backtrack limit is handled as before by returning null if we
exceed it.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70500}
This commit adds support for capture groups (as in e.g. /x(123|abc)y/)
in the experimental regexp engine. Now every InterpreterThread owns a
register array containing (sub)match boundaries. There is a new
instruction to record the current input index in some register.
Submatches in quantifier bodies should be reported only if they occur
during the last repetition. Thus we reset those registers before
attempting to match the body of a quantifier. This is implemented with
another new instruction.
Because of concerns for the growing sizeof the NfaInterpreter object
(which is allocated on the stack), this commit replaces the
`SmallVector` members of the NfaInterpreter with zone-allocated arrays.
Register arrays, which for a fixed regexp are all the same size, are
allocated with a RecyclingZoneAllocator for cheap memory reclamation via
a linked list of equally-sized free blocks.
Possible optimizations for management of register array memory:
1. If there are few register per thread, then it is likely faster to
store them inline in the InterpreterThread struct.
2. re2 implements copy-on-write: InterpreterThreads can share the same
register array. If a thread attempts to write to shared register
array, the register array is cloned first.
3. The register at index 1 contains the end of the match; this is only
written to right before an ACCEPT statement. We could make ACCEPT
equivalent to what's currently CAPTURE 1 followed by ACCEPT. We
could then save the memory for register 1 for threads that haven't
finished yet. This is particularly interesting if now optimization 1
kicks in.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I2c0503206ce331e13ac9912945bb66736d740197
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390770
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69929}
RegExpMacroAssembler::GetCode returns a Handle<Object>. However, that
Handle is almost immediately dereferenced, and is stored as a bare
Object in both RegExpCompiler::CompilationResult and RegExpCompileData.
This makes SpiderMonkey's rooting hazard analysis somewhat
antsy. While RegExpCompileData is alive on the stack, the hazard
analysis will not allow any calls that might GC, because it isn't
smart enough to prove that the code field can't be clobbered by a GC.
As far as I can tell, there is no real hazard here, but storing a
Handle in RegExpCompileData instead of a bare Object will simplify SM
and prevent a future patch from accidentally breaking something.
Bug: v8:10406
Change-Id: I9642dd05c591bfd23b340a89df2f2bf5c9fcac2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161578
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67441}
This is a reland of e80ca24c80
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66798}
This reverts commit e80ca24c80.
Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
> analysis, the stack overflow message can vary ("Stack overflow" or
> "Maximum call stack size exceeded"). I kept that behaviour in this
> patch, under the assumption that stack overflow messages are
> (sadly) the sorts of things that real world code ends up depending
> on.
>
> 2. Depending on the point in code where the error was identified,
> invalid unicode escapes could be reported as "Invalid Unicode
> escape", "Invalid unicode escape", or "Invalid Unicode escape
> sequence". I fervently hope that nobody depends on the specific
> wording of a syntax error, so I standardized on the first one. (It
> was both the most common, and the most consistent with other
> "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
> error_pos field to RegExpParser and RegExpCompileData, which stores
> the position at which an error occurred. This is used by
> SpiderMonkey to provide more helpful messages about where a syntax
> error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
> infrastructure. I considered trying to integrate it more closely
> with MessageTemplate, but since one of our stated goals for this
> project was to make it easier to use irregexp outside of V8, I
> decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}
TBR=jgruber@chromium.org,iireland@mozilla.com
Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10303
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66786}
This patch modifies irregexp's error handling. Instead of representing
errors as C strings, they are represented as an enumeration value
(RegExpError), and only converted to strings when throwing the error
object in regexp.cc. This makes it significantly easier to integrate
into SpiderMonkey. A few notes:
1. Depending on whether the stack overflows during parsing or
analysis, the stack overflow message can vary ("Stack overflow" or
"Maximum call stack size exceeded"). I kept that behaviour in this
patch, under the assumption that stack overflow messages are
(sadly) the sorts of things that real world code ends up depending
on.
2. Depending on the point in code where the error was identified,
invalid unicode escapes could be reported as "Invalid Unicode
escape", "Invalid unicode escape", or "Invalid Unicode escape
sequence". I fervently hope that nobody depends on the specific
wording of a syntax error, so I standardized on the first one. (It
was both the most common, and the most consistent with other
"Invalid X escape" messages.)
3. In addition to changing the representation, this patch also adds an
error_pos field to RegExpParser and RegExpCompileData, which stores
the position at which an error occurred. This is used by
SpiderMonkey to provide more helpful messages about where a syntax
error occurred in large regular expressions.
4. This model is closer to V8's existing MessageTemplate
infrastructure. I considered trying to integrate it more closely
with MessageTemplate, but since one of our stated goals for this
project was to make it easier to use irregexp outside of V8, I
decided to hold off.
R=jgruber@chromium.org
Bug: v8:10303
Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66784}
.. similar to how it is applied in the interpreter. We reserve a stack
slot for the backtrack count, increment it on each backtrack, and fail
if the limit is hit.
Bug: v8:9695
Change-Id: I835888c612d6c8bfa2f34e73ab8c8241dcabc6ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864938
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64426}
V8 uses a backtracking regexp engine, which has the caveat that some
regexp patterns can have exponential runtime behavior when excessive
backtracking is involved.
Especially when regexp patterns are user-controlled, it would be useful
to be able to set an upper limit for a single regexp execution. This CL
takes an initial step in that direction by adding a backtracking limit
(intended to approximate execution time):
- The limit is stored in the JSRegExp's data array.
- A limit can currently only be set through the %NewRegExpWithLimit
runtime function.
- The limit is applied during interpreter execution. When exceeded, the
interpreter stops execution and returns FAILURE (even if continued
execution would at some later point have resulted in SUCCESS).
In follow-up CLs, this mechanism will be extended to work in jitted
regexp code, and exposed through the V8 API.
Bug: v8:9695
Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64417}
This CL implements the tier-up strategy where the interpreter can be used for
an arbitrary number of executions for every regex, before tiering-up to the
compiler. The only exception is for functional global replaces, where we
eagerly tier-up to native code right away.
To use the tier-up logic --regexp-tier-up=value needs to be set. It is
currently set to 0 by default.
Change-Id: I770857e5eae710a952fe47661cb42957c53848b4
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789299
Commit-Queue: Ana Pesko <anapesko@google.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63623}
The code fields in a JSRegExp object now either contain irregexp
compiled code or a trampoline to the interpreter. This way the code
can be executed without explicitly checking if the regexp shall be
interpreted or executed natively.
In case of interpreted regexp the generated bytecode is now stored in
its own fields instead of the code fields for Latin1 and UC16
respectively.
The signatures of the jitted irregexp match and the regexp interpreter
have been equalized.
Bug: v8:9516
Change-Id: I30e3d86f4702a902d3387bccc1ee91dea501fe4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762513
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63457}
This CL implements a naive tiering-up strategy where the interpreter
is used for the first execution for every regex, and the compiler is
used for every execution after that. The only exception is if a
global replace is being executed on a regex, we eagerly tier-up to
native code right away.
To use the tier-up logic --regexp-tier-up needs to be set. It is
currently disabled by default.
Bug v8:9566
Change-Id: Ib64ed77cbfcde10411161c0541dfa2501a0a93bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710661
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63150}
This is a reland of c2ee4a7999
Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73cb
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}
Bug: v8:8954
Change-Id: Ice77c05240f1fabd36bf97b8e789dd4c25a9718f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715451
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62904}
This reverts commit c2ee4a7999.
Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
See https://bugs.chromium.org/p/chromium/issues/detail?id=985624
Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73cb
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}
TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8954, chromium:985624
Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62824}
This is a reland of d4d28b73cb
Original change's description:
> [regexp] Call the regexp interpreter without CEntry overhead
>
> Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
>
> This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
>
> Bug: v8:8954
> Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62753}
Bug: v8:8954
Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#62794}
This reverts commit d4d28b73cb.
Reason for revert: breaks TSAN bot:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/9526
Original change's description:
> [regexp] Call the regexp interpreter without CEntry overhead
>
> Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
>
> This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
>
> Bug: v8:8954
> Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62753}
TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
Change-Id: I3257220c4359a3b801dd80e0eff6c4534d8badee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706050
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62757}
Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
Bug: v8:8954
Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62753}
This CL renames jsregexp.{h,cc} to regexp.{h,cc}, hides all non-public
functions of RegExpImpl in the .cc file, and renames the public parts
of RegExpImpl to just RegExp. Include directives from outside the
src/regexp directory are limited to regexp.h, regexp-stack.h, and
regexp-utils.h. We also expose all result codes that can be returned
by irregexp code (including RETRY) on the public header since they
are needed elsewhere, e.g. in builtins.
Bug: v8:9359
Change-Id: Iae1a01ac9f6e1e4dc168f3fbe8fe8679cb6b1259
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662297
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62240}
