This adds a fast path to skip runtime calls to GetSubstitution when
the replacer string does not contain a '$' char.
Extended background:
String.prototype.replace is (roughly) structured as follows:
* Check if {searchValue} has a @@replace Symbol, and delegate to that if
so. We currently implement efficient fast paths when {searchValue} is
a String or a fast RegExp.
* A specialized fast path for single-char {searchValue}, "long" subject
string, and String {replaceValue} that do not contain '$' chars (yes,
this fast path is very specialized).
* Check for the location of the first match using StringIndexOf, and
exit early if no match is found.
* Finally build the return value, which is 'prefix + replacement +
suffix', where replacement is either the result of calling {replaceValue}
(if it is callable), or GetSubstitution(ToString({replaceValue}))
otherwise.
There's several spots that could be improved.
StringIndexOf currently calls into C++ runtime for all but the simple
1-byte, 1-char {searchValue} case. We need to finally add support for
remaining cases.
The runtime call to GetSubstitution can be skipped if the replacer
string does not contain any '$' syntax. This CL handles that case.
BUG=
Review-Url: https://codereview.chromium.org/2813843002
Cr-Commit-Position: refs/heads/master@{#44606}
The hole NaN should also have proper Type::Hole, and not silently hide
in the Type::Number. This way we can remove all the special casing for
the hole NaN, and we also finally get the CheckNumber right.
This also allows us to remove some ducktape from the Deoptimizer, as for
escape analyzed FixedDoubleArrays we always pass the hole value now to
represent the actual holes.
Also-By: jarin@chromium.org
BUG=chromium:684208,chromium:709753,v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2814013003
Cr-Commit-Position: refs/heads/master@{#44603}
This patch implements the runtime semantics of dynamic import.
We create a new ASTNode so that we can pass the JSFunction closure() to
the runtime function from which we get the script_url.
d8 implements the embedder logic required to load and evaluate the modules.
The API is mostly implemented as specified.
BUG=8:5785
Review-Url: https://codereview.chromium.org/2703563002
Cr-Commit-Position: refs/heads/master@{#44551}
The DCHECK added by https://chromium-review.googlesource.com/461827 was not true
in case we failed to compile the function.
BUG=chromium:708598
Change-Id: I6a542c3ac6281c0549396b4ff0af34ea44450006
Reviewed-on: https://chromium-review.googlesource.com/472826
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44513}
We don't need to do any kind of translation for non-wasm frames. And we need this knowledge for lazy symbolization.
Capturing stack trace is ~7% faster.
BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2795103004
Cr-Commit-Position: refs/heads/master@{#44502}
This reverts commit 61df2d90a9.
The CL was speculatively reverted due to canary crashes, which turned
out to be caused by another CL.
Original issue's description:
> [heap] Remove size specializations in static object visitors.
>
> Apart from that this patch adds kVisitJSObjectFast for JSObjects that
> do not have any unboxed double fields and can be visited without
> run-time layout check.
>
> BUG=chromium:694255
>
> Review-Url: https://codereview.chromium.org/2763413007
> Cr-Commit-Position: refs/heads/master@{#44237}
> Committed: dbb1cbe3a8
Review-Url: https://codereview.chromium.org/2808533002
Cr-Commit-Position: refs/heads/master@{#44494}
The serializer already has code that special cases for some external
strings. We can handle all external strings in one place instead of
splitting the logic between the serializer and the object visitor.
The main benefit is that we remove two virtual functions from the
ObjectVisitor and thus simplify it for all other users.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2799943002
Cr-Commit-Position: refs/heads/master@{#44485}
This removes one virtual function from ObjectVisitor.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2798923004
Cr-Commit-Position: refs/heads/master@{#44476}
Reason for revert:
Speculative revert due to canary crashes.
BUG=chromium:708339,chromium:707790
Original issue's description:
> [heap] Remove size specializations in static object visitors.
>
> Apart from that this patch adds kVisitJSObjectFast for JSObjects that
> do not have any unboxed double fields and can be visited without
> run-time layout check.
>
> BUG=chromium:694255
>
> Review-Url: https://codereview.chromium.org/2763413007
> Cr-Commit-Position: refs/heads/master@{#44237}
> Committed: dbb1cbe3a8TBR=mlippautz@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2800923004
Cr-Commit-Position: refs/heads/master@{#44459}
This CL introduces SloppyArgumentsElements to encapsulate all the constants
for SLOW_ and FAST_SLOPPY_ARGUMENTS_KINDS. This will serve as a better
documentation and reduces the use of undocumented constants.
Change-Id: I7a5b4e79f02573161d8a83aaf6f69fc490883aa5
Reviewed-on: https://chromium-review.googlesource.com/467666
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44433}
There's no need to set it so early - it's only needed when the function has
really been parsed. This way we don't need to produce and store it for skipped
inner functions.
BUG=v8:5516
Change-Id: Ibf59a8acb886ea3de9be140431a334a03b408f5b
Reviewed-on: https://chromium-review.googlesource.com/461827
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44410}
Getting elements, querying length or copying elements
are now const functions.
Drive-by fix: Noticed a few more getters that should be const.
Add a comment to ArrayList functions that are static functions.
BUG=
Change-Id: I5de1aed97510dea4e47cb974b3259da51ae663af
Reviewed-on: https://chromium-review.googlesource.com/467249
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44372}
ArrayList is a FixedArray where kFirstIndex is > 0. The
Elements() methods returns a copy of the elements starting at
kFirstIndex, i.e., without the length that is stored in the first
slot.
Drive-by fix: Rename some variables.
BUG=
Change-Id: Ia1de73c4780a179301007f2ab9080fd08e8ea99d
Reviewed-on: https://chromium-review.googlesource.com/466186
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44365}
JSObject is slow: creating strings for keys and storing values by these keys after takes significant amount of time.
With this CL console methods (most of them collect top stack frame to calculate source location) are ~33% faster.
V8Debugger::captureStackTrace is ~50% faster.
BUG=v8:6189
R=yangguo@chromium.orgTBR=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2789073002
Cr-Commit-Position: refs/heads/master@{#44344}
The last CL https://chromium-review.googlesource.com/c/456707/ caused
some pretty heavy performance regressions. After experimenting, it
seems the easiest and most straight-forward way to copy the elements
into the new typed array is to do it in JS.
Adds a fast path for typed arrays, where the source typed array has
the same elements kind, in which case we can just copy the backing
store using memcpy.
This CL also removes regression test 319120 which is from a pwn2own
vulnerability. The old code path enforced a maximum byte_length
that was too low, which this change removes. The length property of
the typed array must be a Smi, but the byte_length, which can be up
to 8x larger than length for a Float64Array, can be a heap number.
We can also re-use some of the logic from ConstructByLength when
deciding whether to allocate the buffer on- or off-heap, so that
is factored out into InitializeBasedOnLength. We can also re-use
the DoInitialize helper instead of calling into the runtime,
meaning we can remove InitializeFromArrayLike.
BUG=v8:5977,chromium:705503,chromium:705394
Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755
Reviewed-on: https://chromium-review.googlesource.com/459621
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44301}
The dotAll flag changes behavior of the dot '.' character to match every
possible single character instead of excluding certain line terminators.
The implementation is staged behind --harmony-regexp-dotall.
Spec proposal: https://github.com/mathiasbynens/es-regexp-dotall-flag
BUG=v8:6172
Review-Url: https://codereview.chromium.org/2780173002
Cr-Commit-Position: refs/heads/master@{#44295}
- Introduce new struct AsyncGeneratorRequest, which holds
information pertinent to resuming execution of an
AsyncGenerator, such as the Promise associated with the async
generator request. It is intended to be used as a singly
linked list, and holds a pointer to the next item in te queue.
- Introduce JSAsyncGeneratorObject (subclass of
JSGeneratorObject), which includes several new internal fields
(`queue` which contains a singly linked list of
AsyncGeneratorRequest objects, and `await_input` which
contains the sent value from an Await expression (This is
necessary to prevent function.sent (used by yield*) from
having the sent value observably overwritten during
execution).
- Modify SuspendGenerator to accept a set of Flags, which
indicate whether the suspend is for a Yield or Await, and
whether it takes place on an async generator or ES6
generator.
- Introduce interpreter intrinsics and TF intrinsic lowering for
accessing the await input of an async generator
- Modify the JSGeneratorStore operator to understand whether or
not it's suspending for a normal yield, or an AsyncGenerator
Await. This ensures appropriate registers are stored.
- Add versions of ResumeGeneratorTrampoline which store the
input value in a different field depending on wether it's an
AsyncGenerator Await resume, or an ordinary resume. Also modifies
whether debug code will assert that the generator object is a
JSGeneratorObject or a JSAsyncGeneratorObject depending on the
resume type.
BUG=v8:5855
R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
littledan@chromium.org, neis@chromium.orgTBR=marja@chromium.org
Change-Id: I9d58df1d344465fc937fe7eed322424204497187
Reviewed-on: https://chromium-review.googlesource.com/446961
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44240}
Apart from that this patch adds kVisitJSObjectFast for JSObjects that
do not have any unboxed double fields and can be visited without
run-time layout check.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2763413007
Cr-Commit-Position: refs/heads/master@{#44237}
Move builtin definitions (i.e. BUILTIN_LIST and family) to a separate header
in preparation for auto-generation of TFS interface descriptors.
BUG=v8:6116
Review-Url: https://codereview.chromium.org/2784793002
Cr-Commit-Position: refs/heads/master@{#44221}
This implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is not callable.
Named captures can be referenced from replacement strings by using the
"$<name>" syntax. A couple of examples:
let re = /(?<fst>.)(?<snd>.)/u;
"abcd".replace(re, "$<snd>$<fst>") // "bacd"
"abcd".replace(re, "$2$1") // "bacd" (numbered refs work as always)
"abcd".replace(re, "$<snd") // SyntaxError (unterminated named ref)
"abcd".replace(re, "$<42$1>") // "cd" (invalid name)
"abcd".replace(re, "$<thd>") // "cd" (non-existent name)
"abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>") // "cd" (non-matched capture)
Support is currently behind the --harmony-regexp-named-captures flag.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2775303002
Cr-Original-Commit-Position: refs/heads/master@{#44171}
Committed: 17f13863b6
Review-Url: https://codereview.chromium.org/2775303002
Cr-Commit-Position: refs/heads/master@{#44182}
Reason for revert:
Invalid DCHECKs for non-matched groups.
Original issue's description:
> [regexp] Named capture support for string replacements
>
> This implements support for named captures in
> RegExp.prototype[@@replace] for when the replaceValue is not callable.
>
> Named captures can be referenced from replacement strings by using the
> "$<name>" syntax. A couple of examples:
>
> let re = /(?<fst>.)(?<snd>.)/u;
> "abcd".replace(re, "$<snd>$<fst>") // "bacd"
> "abcd".replace(re, "$2$1") // "bacd" (numbered refs work as always)
> "abcd".replace(re, "$<snd") // SyntaxError (unterminated named ref)
> "abcd".replace(re, "$<42$1>") // "cd" (invalid name)
> "abcd".replace(re, "$<thd>") // "cd" (non-existent name)
> "abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>") // "cd" (non-matched capture)
>
> Support is currently behind the --harmony-regexp-named-captures flag.
>
> BUG=v8:5437
>
> Review-Url: https://codereview.chromium.org/2775303002
> Cr-Commit-Position: refs/heads/master@{#44171}
> Committed: 17f13863b6TBR=yangguo@chromium.org,littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2776293003
Cr-Commit-Position: refs/heads/master@{#44180}
This implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is not callable.
Named captures can be referenced from replacement strings by using the
"$<name>" syntax. A couple of examples:
let re = /(?<fst>.)(?<snd>.)/u;
"abcd".replace(re, "$<snd>$<fst>") // "bacd"
"abcd".replace(re, "$2$1") // "bacd" (numbered refs work as always)
"abcd".replace(re, "$<snd") // SyntaxError (unterminated named ref)
"abcd".replace(re, "$<42$1>") // "cd" (invalid name)
"abcd".replace(re, "$<thd>") // "cd" (non-existent name)
"abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>") // "cd" (non-matched capture)
Support is currently behind the --harmony-regexp-named-captures flag.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2775303002
Cr-Commit-Position: refs/heads/master@{#44171}
This implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is callable.
In that case, the result.groups object is passed to the replacer
function as the last argument.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2764343004
Cr-Commit-Position: refs/heads/master@{#44142}
Since we no longer support the ignition-staging configuration
any longer, we can retire the three tier pipeline and the
CompileBaseline functionallity.
We still need support for JSFunction self healing due to
liveedit (which for --no-turbo might end up replacing a
forced Ignition function with a FCG function) - we can
remove this once we remove --no-turbo support.
BUG=v8:4280
Change-Id: I5482abd17785324654e022affd6bdb555b19b181
Reviewed-on: https://chromium-review.googlesource.com/452620
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44141}
Currently BodyDescriptorBase::IterateBodyImpl does a run-time check
for obj->map()->HasFastPointerLayout(), which is redundant for all
non-JSObject heap objects.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2774553003
Cr-Commit-Position: refs/heads/master@{#44111}
The former will handle stores to global variables, lets and undeclared
variables. The latter will handle named stores to explicit receiver.
BUG=chromium:576312, v8:5561
Change-Id: I335fa21db47c3d001da8cc79fa8cb6f8abcbb7e2
Reviewed-on: https://chromium-review.googlesource.com/458639
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44085}
With precise binary code coverage, the reported count is either 0 or 1.
We only report 1 the first time we collect coverage data after the
function has been executed.
Since we do not care about the accurate execution count, we can optimize
the function once it has been executed once.
Also change best effort coverage to be implicitly binary.
R=caseq@chromium.org, jgruber@chromium.org, pfeldman@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2766573003
Cr-Commit-Position: refs/heads/master@{#44074}
Default to the chromium-internal build config (instead of the more
permissive no_chromium_code config).
BUG=v8:5878
Review-Url: https://codereview.chromium.org/2758563002
Cr-Commit-Position: refs/heads/master@{#43909}
The data needed to be modified a bit to actually allow skipping over functions
based on it. In particular, we need to allow skipping over an unknown inner
scope structure (in the previous stage, we just had tests comparing the data
against some baseline truth, so it wasn't needed).
also removing the current "skip functions based on preparse data" logic,
since preparser data is not used any more. At a later stage, I'll consider
plugging the preparser-scope-analysis-data into that pipeline (so I don't want
to remove the full code yet).
Integration to the various forms of compilation is still incomplete; this CL
integrates just enough to get the minimal example to pass:
(function foo() {
function preparsed() {
var var1 = 10;
function skip_me() {
print(var1);
}
return skip_me;
}
return preparsed;
})()()();
BUG=v8:5516
Change-Id: I0d24b4c3b338f7e6b6c3bf7cf2c1ceb29608e2f2
Reviewed-on: https://chromium-review.googlesource.com/446336
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43908}
This CL renames all occurrences of "internal field" to "embedder field"
to prevent confusion. As it turns out, these fields are not internal to
V8, but are actually embedder provided fields that should not be mucked
with by the internal implementation of V8.
Note that WASM does use these fields, and it should not.
BUG=v8:6058
Review-Url: https://codereview.chromium.org/2741683004
Cr-Commit-Position: refs/heads/master@{#43900}
The WasmCompileLazy builtin creates an internal frame, thus the garbage
collector will visit all pointers in the stack frame.
However, we will call this builtin from compiled wasm code, and it
receives raw (untagged) arguments. This is because this builtin is
later exchanged by compiled wasm code, so the ABI needs to be
compatible.
This CL introduces the has_tagged_params code flag, which is true by
default and false for each WASM_FUNCTION, JS_TO_WASM_FUNCTION and
the WasmCompileLazy builtin.
The gargabe collector just ignores the parameters for each frame
whose code object has this flag set to false. For internal frames,
all pointers in the whole stack frame are ignored if the flag is set.
R=titzer@chromium.org, mstarzinger@chromium.org
BUG=v8:5991
Change-Id: I12a15157db344725bcc280e2041fd5bcad2ba700
Reviewed-on: https://chromium-review.googlesource.com/451400
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43884}
This moves most of the logic contained in RegExpExecStub to CSA. Benefits are
mostly easier readability and hackability, and removal of a large chunk of
platform-specific assembly.
Exit frame construction and the final call remain in RegExpExecStub.
BUG=v8:5339,v8:592
Review-Url: https://codereview.chromium.org/2738413002
Cr-Commit-Position: refs/heads/master@{#43844}
That way, we don't need to create a context-less constructor function.
Instead, we use the constructor_or_backpointer (or null) field, and
rename it to constructor_or_fti_or_backpointer so nobody is confused.
Note that technically, we still have JSFunctions without contexts, as
they're temporarily created in the deoptimizer.
BUG=v8:6084
R=dcheng@chromium.org,bmeurer@chromium.org,verwaest@chromium.org
Change-Id: I084f052533c317f2cbfb9c35e1acf40263c6257b
Reviewed-on: https://chromium-review.googlesource.com/454636
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43834}
Marking shared functions for tier-up was optimizing the functions
non-concurrently, to avoid the case where the same shared function is
optimized concurrently by multiple JS functions. This was particularly a
problem for small functions, which (if called in a loop) could get
marked for optimisation quite quickly.
In this CL, the shared function is instead marked as having an active
optimization job running, and these do not spawn a compilation job.
BUG=chromium:693590
BUG=chromium:700863
BUG=chromium:701665
Change-Id: I2b1c5af8e7aa8d779f86814c22c65c78bee0630f
Reviewed-on: https://chromium-review.googlesource.com/455779
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43833}
This reverts commit 822aef290f.
Reason for revert: Makes getters-on-elements flaky on many bots. E.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16848/steps/Check%20-%20isolates%20%28flakes%29/logs/getters-on-elements
Bisected locally and tested with:
tools/run-tests.py --gn --variants=asm_wasm mjsunit/getters-on-elements --isolates --random-seed-stress-count=500
Original change's description:
> [compiler] Mark shared functions which have an optimization job
>
> Marking shared functions for tier-up was optimizing the functions
> non-concurrently, to avoid the case where the same shared function is
> optimized concurrently by multiple JS functions. This was particularly a
> problem for small functions, which (if called in a loop) could get
> marked for optimisation quite quickly.
>
> In this CL, the shared function is instead marked as having an active
> optimization job running, and these do not spawn a compilation job.
>
> BUG=693590
>
> Change-Id: I3df93fbf9cec7eda8229fcf416d7c429c06bec86
> Reviewed-on: https://chromium-review.googlesource.com/446836
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43778}
TBR=mvstanton@chromium.org,leszeks@chromium.org,hablich@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=693590
Change-Id: If7dbdf3de302ec595c44e7f4795554db7674f22f
Reviewed-on: https://chromium-review.googlesource.com/454042
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43787}
