The V8 API provides interceptors. They are not part of the
EcmaScript specification. But their behavior should be consistent.
For example, when an EnumeratorInterceptor is defined, Object.keys(),
Object.entries(), and Object.values() should all have the
same number of entries.
This CL creates consistent behavior among these
functions. If a QueryCallback is present, it is used to
filter the result from the EnumeratorCallback for
enumerable properties.
Bug: v8:6627
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I4f4271ddeb99a5e85918148c5033923c149b9468
Reviewed-on: https://chromium-review.googlesource.com/649786
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47831}
Change-Id: I891ff57b7a3a47e3371269b123705cdf6391499b
Reviewed-on: https://chromium-review.googlesource.com/648513
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47830}
And add the helpfully suggested flag to the GDB re-run of mksnapshot.
NOTRY=true
Change-Id: I52011aa580c8d3e557f869b8306b9b978c73b946
Reviewed-on: https://chromium-review.googlesource.com/647693
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47829}
Add a flag which traces which interrupts are being handled by the
StackGuard's HandleInterrupts function.
Change-Id: I18fcf58b03cf6c255d7457d8a55b0a0dadb00931
Reviewed-on: https://chromium-review.googlesource.com/649530
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47828}
The renames capture what the item being unwrapped is - it's always
a js-to-wasm wrapper, which is more closely captured by "export" rather
than "import".
Bug:
Change-Id: Iffc3d8cb9037afc2d32885301fd13fc12b8277ce
Reviewed-on: https://chromium-review.googlesource.com/648005
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47827}
Always return to the InterpreterEntryTrampoline rather than calling the
InterpreterExitTrampoline from the Return bytecode handler. This fixes a
regression which occured if we upset the call/return stack by skipping the
return to the InterpreterEntryTrampoline from the return bytecode handler.
BUG=chromium:759390,chromium:753705
Change-Id: Ib625654a4a5072ac6c8d8e9611d1b9c0bbced4ca
Reviewed-on: https://chromium-review.googlesource.com/649517
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47826}
Using the Builtins::Name type doesn't give use any range safety benefits
over simply using int id's, and it complicates use sites by always
forcing a static_cast<Builtins::Name>(id).
Bug: v8:6624
Change-Id: Id5fcf6800c781c637145ab1d00d821f9ad473321
Reviewed-on: https://chromium-review.googlesource.com/650247
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47823}
The repo url changed recently in Chromium, which breaks the V8 DEPS roller.
This uses the same url like Chromium again.
TBR=yangguo@chromium.org
Change-Id: Iffb9daa8380d111e77ebcef1da58082e346c1e4a
Reviewed-on: https://chromium-review.googlesource.com/650348
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47821}
Now that FCG is gone, we don't need to have a code-size multiplier to
distinguish Ignition and FCG code sizes.
Bug: v8:6409
Change-Id: I05e5fa2483bfc17e91de22736b66ad27a5aab49b
Reviewed-on: https://chromium-review.googlesource.com/649149
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47819}
This adds support for lazy deserialization of JS-linkage (TFJ) builtins,
still gated behind the --lazy-deserialization flag. If enabled, we
proceed as follows:
During isolate initialization, only eager builtins are deserialized. All
references to lazy builtins are replaced by the DeserializeLazy builtin.
In particular, this happens in the builtin table (Builtins::builtins_)
and in SharedFunctionInfo objects.
When calling into a not-yet deserialized function (i.e. the JSFunction's
code object is the DeserializeLazy builtin), the DeserializeLazy builtin
takes over. It checks the builtin table to see if the target builtin
(determined by looking at the builtin id stored on the
SharedFunctionInfo) has already been deserialized. If so, it simply
copies the builtin code object to the JSFunction and SharedFunctionInfo.
Otherwise, we enter Runtime::kDeserializeLazy to deserialize the
builtin.
With --lazy-deserialization, isolate deserialization is 11% faster
(1.5ms vs. 1.7ms), and code_space->Size() is 33% lower (984K vs.
1475K).
Moving relocation infos & handler tables out of the partial snapshot
cache would additionally let us save up to 30K per isolate. Adding code
stubs to that list increases further potential savings to 262K.
Bug: v8:6624
Change-Id: I0ac7d05d165d2466998269bd431ac076a311cbeb
Reviewed-on: https://chromium-review.googlesource.com/649166
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47818}
This cl: https://chromium-review.googlesource.com/c/538614/ changes the
number of ticks required for tiering up based on the size of function. An
earlier cl: https://chromium-review.googlesource.com/c/529165/ also resets
ticks when type feedback changes. So, it is reasonable to assume that a
function which has necessary number of ticks has the required type feedback
for optimizing. Hence, removing the check for type feedback from the tierinup
decision.
Bug:
Change-Id: Ia350ad4dfba5f93f1a17bdc0c309bf6b41b0c1c9
Reviewed-on: https://chromium-review.googlesource.com/647851
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47816}
I could not find any usage of this struct and it is in the internal
namespace so I though it might be safe to remove it.
Bug:
Change-Id: I85d605712ab1ab3218eb03ed4d3b5fc0e541e21a
Reviewed-on: https://chromium-review.googlesource.com/641270
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47813}
For such a simple predicate, calling a(n inline) function that checks against
the values is faster (*) than maintaining the cache.
(*) When scanning a file that contains only comments, we're basically calling
IsLineTerminator in a loop. Parsing such files is now 7-18% faster in local
experiments.
BUG=v8:6092
Change-Id: I6a8f2aba9669a76152292f4e6c7853638d15aae3
Reviewed-on: https://chromium-review.googlesource.com/645633
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47810}
This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
TBR: mstarzinger@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/647596
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47808}
Removed one function that was needed for code patching during
deoptimization, and one function needed for full code gen.
Bug: v8:6563
Change-Id: Iea0c8a3d374cf315ac4903f4e84a7a2f11563b70
Reviewed-on: https://chromium-review.googlesource.com/649747
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47807}
The perf tests results are used by tools/perf-to-html.py to generate
html pages. Since the results are used as divisors to compute
percentages, when the one of them happens to be zero, the script
crashes. This CL prevent the crash and uses the text "NaN" instead of
the percentage.
R=machenbach@chromium.org
CC=ahaas@chromium.org,clemensh@chromium.org
Bug: chromium:761816
Change-Id: I482a85150c8323a7a837e6d589feee88279831cd
Reviewed-on: https://chromium-review.googlesource.com/649626
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47806}
Since ignition bakes the interrupt budget into the snapshot (the
bytecode handlers reset the current function's interrupt budget to a
constant value), we should remove the interrupt budget flag, which won't
actually change anything if used.
Change-Id: I9672b73fea7abb6c9b575d3963f107e2397f8e49
Reviewed-on: https://chromium-review.googlesource.com/649148
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47805}
Evalling multiple long strings makes compilation cache the bottleneck: See
https://bugs.chromium.org/p/v8/issues/detail?id=6779 for more information.
BUG=v8:6779
Change-Id: I0014b1aca1258a643cbeb441a82707b163f8166d
Reviewed-on: https://chromium-review.googlesource.com/649146
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47801}
This adds support for the backing store of mapped arguments objects to
escape analysis. It also unifies two simplified operators representing
allocations of these backing stores into a single {NewArgumentsElements}
operator and threads through the "mapped count" to the deoptimizer.
R=tebbi@chromium.org
Change-Id: I1864e29a5703348597b7b2e41deaf5fab73e2c93
Reviewed-on: https://chromium-review.googlesource.com/643208
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47800}
When setting a typed array from an array like object, the
length of the source can only be converted to a unit32 if
it is not too large.
Bug: v8:6704, chromium:761654
Change-Id: I8f89aa348093d8bd4d54aa16d6b5f255d3cb7adc
Reviewed-on: https://chromium-review.googlesource.com/648976
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47798}
In kArchSaveCallerRegisters, PushCallerSaved alone alters stack pointer
without informing `frame_access_state`. This commit compensate the
inconsistency by manually increasing the delta after pushing registers.
This affects systems (currently only ARM64) using stack pointer for
accessing variables stored on stack.
Bug: chromium:749486
Change-Id: Ic6da3826323d4fb1c545ade3d4d2cd4d1fed1843
Reviewed-on: https://chromium-review.googlesource.com/633606
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47797}
This is a reland of 6daf3c77f1
Original change's description:
> [presubmit] Include test/common and test/fuzzer in cpplint
>
> These directories probably just did not exist when the cpplint paths
> were defined.
>
> R=machenbach@chromium.org
> CC=mstarzinger@chromium.org
>
> Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642
> Reviewed-on: https://chromium-review.googlesource.com/647807
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47786}
Change-Id: I15cd1b508cd3c6f5cd58cd5c5129174d8ced40d0
Reviewed-on: https://chromium-review.googlesource.com/649006
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47796}
We encode the reachability/liveness in the placement. After we prepare
use counts, the kUnknown placement means that the noe is unreachable.
Bug: v8:5267
Change-Id: Iad27159508f0aefb812b6394a257055f789fbe13
Reviewed-on: https://chromium-review.googlesource.com/646247
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47795}
Rename Managed::New to Managed::From (since it takes ownership of an
existing object), and re-introduce Managed::Allocate, which allocates
a new object and stores it in a Managed.
R=titzer@chromium.org
Change-Id: I20b0750697fbe7d56d3816b19919c31e389278b3
Reviewed-on: https://chromium-review.googlesource.com/645806
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47794}
This reverts commit 84c2dfce43.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
Original change's description:
> Remove weak-list of optimized JS functions.
>
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
>
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
>
> We needed to change/remove the cctests that used to check
> something on this list.
>
> Working in x64, ia32, arm64, arm, mips64 and mips.
>
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}
TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}
This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}
Our current deserializers (startup & partial) use a system of static memory
reservations: required memory is determined at serialization time, which we
then request before deserialization and dole out as-needed during
deserialization.
Lazy builtin deserialization needs a bit more flexibility. On the one hand, the
amount of required memory varies since --lazy-deserialization can be switched
on and off at runtime.
On the other, builtin deserialization has been made order-independent, and we
can encounter references to builtins before they have been deserialized.
Both problems are solved by dynamically allocating required memory and
initializing the builtins table with the (yet uninitialized) builtin Code
objects.
Bug: v8:6624
Change-Id: Iee90992e91adb4ab45dae1acc81f64a108d12584
Reviewed-on: https://chromium-review.googlesource.com/647748
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47789}
These will tight-loop scanning primitives.
BUG=v8:6092
Change-Id: I9bf0f1952755bbede3c545c45fe2c4a210548171
Reviewed-on: https://chromium-review.googlesource.com/647526
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47788}
This reverts commit 6daf3c77f1.
Reason for revert: Need to fix violations in test/fuzzer first.
Original change's description:
> [presubmit] Include test/common and test/fuzzer in cpplint
>
> These directories probably just did not exist when the cpplint paths
> were defined.
>
> R=machenbach@chromium.org
> CC=mstarzinger@chromium.org
>
> Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642
> Reviewed-on: https://chromium-review.googlesource.com/647807
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47786}
TBR=machenbach@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: Ie20f0e9ef521c8da0c928bee241427fad694a440
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/647593
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47787}
These directories probably just did not exist when the cpplint paths
were defined.
R=machenbach@chromium.orgCC=mstarzinger@chromium.org
Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642
Reviewed-on: https://chromium-review.googlesource.com/647807
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47786}
For readability. Also make them constexpr, which allows to use them in
other constexpr contexts.
R=mstarzinger@chromium.org
Change-Id: Ia9ea9b4fb044bd1a011da887409bfbcbf6298fec
Reviewed-on: https://chromium-review.googlesource.com/647627
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47785}
This allows to reuse this logic in the wasm baseline compiler to
determine the location of our parameters.
R=mstarzinger@chromium.orgCC=titzer@chromium.org
Bug: v8:6600
Change-Id: I86e4d425d1c8aa35f0f722d311a2bd830b951d0a
Reviewed-on: https://chromium-review.googlesource.com/647628
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47784}
DeserializeLazy must be deserialized eagerly since it implements the
lazy deserialization mechanism.
Wasm currently requires their builtins to be immovable; and since we can
only efficiently allocate immovable code objects at deserialization
time, wasm builtins must be eager-loaded for now.
Bug: v8:6624
Change-Id: I9aae60385d4b08a34a52e12711ee1a492476f7cf
Reviewed-on: https://chromium-review.googlesource.com/647707
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47783}
