kNextChunk handling in deserializer.cc relies on the reservation
mechanism, which is not used by builtin deserialization. To avoid
complications, we work around this for now by skipping over these
bytecodes.
This will soon become unnecessary once allocations & reservations have
been refactored.
Bug: v8:6624
Change-Id: I9e861268ee2b3f49fe7f3ed6c1e3501b4b47dc37
Reviewed-on: https://chromium-review.googlesource.com/655158
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47879}
With lazy deserialization, the target code object may have been replaced
by DeserializeLazy. In that case, we can get the target builtin id from
the shared function info, and we need to skip RelocInfo iteration (it
doesn't exist yet).
Bug: v8:6624
Change-Id: I765b74de313e65bfdf0122f13535029994fc0de1
Reviewed-on: https://chromium-review.googlesource.com/655159
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47878}
What happened:
- When rewriting in DoParseFunction, the relevant function scope is no longer in
the scope stack.
- The correct scope is given to the PatternRewriter.
- PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
- BuildIteratorCloseForCompletion would just call NewTemporary (which creates
a new temporary in Parser's current scope) instead of using the scope passed to
it and calling NewTemporary on it.
- Normally this went unnoticed, since it doesn't matter that much where the
temporary is.
- But in the lazy arrow func case, the Parser's scope at that point was the
already-resolved outer scope, and a DCHECK detected this problem.
Kudos & thanks to verwaest@ for a debugging session :)
BUG=chromium:761831
Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
Reviewed-on: https://chromium-review.googlesource.com/650297
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47877}
There are two main reasons to move DeserializeLazy to ASM:
1. We avoid complications around the distinction between Call/Construct
cases by making sure relevant registers (e.g. new_target) remain
unclobbered.
2. We can avoid the tail-call through CodeFactory::Call/Construct by
jumping directly to the deserialized code object.
Bug: v8:6624
Change-Id: Idef8fa73d804e16d510f62766c735d1891729b81
Reviewed-on: https://chromium-review.googlesource.com/652472
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47876}
Given that we no longer need to iterate over lists of optimized JS functions
(c.f. https://chromium-review.googlesource.com/c/v8/v8/+/647596), we can
remove this field. Thus saving the size of one pointer per function.
Bug: v8:6637
Change-Id: If77951f2eddba33ba350fa9ddf03a4edb3f7c7d8
Reviewed-on: https://chromium-review.googlesource.com/652373
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#47875}
The wasm-async fuzzer uses the bytes provided by the fuzzer engine
directly as wasm module bytes, compiles them with async compilation, and
then tries to execute the "main" function of the module. This "main"
can have an infinite loop which causes a timeout in the fuzzer. With
this CL the "main" function is first executed with the interpreter. If
the execution in the interpreter finishes within 16k steps, which means
that there is no infinite loop, also the compiled code is executed.
I added the raw fuzzer input as a test case because in this case I
really want to test the fuzzer and not V8.
R=clemensh@chromium.org
Bug: chromium:761784
Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
Reviewed-on: https://chromium-review.googlesource.com/651046
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47874}
The help output prints the first line of the doc string.
Change-Id: I76817d5138b7bb7ba8034c6a5d803b5aaf1201f7
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/654603
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47871}
JS runtime calls are always created with undefined recievers, so make the
bytecode behave similarly to CallUndefinedReciever such that we don't need
to push an explicit undefined register for the receiver for such calls.
Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls
to pass the generator in the first argument rather than the reciever since
these runtime calls were desugered in the bytecode generator and explicitly
passed the generator in the receiver.
Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269
Reviewed-on: https://chromium-review.googlesource.com/654257
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47870}
Introduce NodeProperties::NoObservableSideEffectBetween to check if
there's any observable side effect between two nodes in the effect
chain. Use this to guard the insertion of potentially redundant map
checks in the lowering of Object.prototype.hasOwnProperty and keyed
accesses within a for..in loop. This gives another boost on the for..in
performance front.
Bug: v8:6702
Change-Id: I68133f14ad388a1a7422714319c9b323d5cf8bc4
Reviewed-on: https://chromium-review.googlesource.com/654640
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47869}
The lazy deserialization builtin id is usually set when the shared
function info is created in Factory::NewSharedFunctionInfo, which looks
at the given code object to grab the builtin id.
However, this doesn't work when the shared function info is created
after deserialization, as is the case for harmony features that can be
toggled with runtime flags. At this point, lazy builtins have already
been replaced by DeserializeLazy in the builtins table.
To ensure that the lazy deserialization id is correct in this case,
explicitly set it in bootstrapper functions.
Bug: v8:6624, v8:6788
Change-Id: Ia6ac3a4842d2659d5de6d92f378ea221b5508040
Reviewed-on: https://chromium-review.googlesource.com/652477
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47867}
Followup after https://chromium-review.googlesource.com/c/v8/v8/+/652427
which triggered FORWARD_DECLARE macro redefinition warnings/errors. Let's
make sure to undef this macro at the end of source files that create it.
Bug: chromium:746958
Change-Id: Ie70743c836db45eb51f412a0d6359f0f667319d3
Reviewed-on: https://chromium-review.googlesource.com/654657
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47866}
This extends the list by two cases that we currently cannot handle:
FunctionPrototypeHasInstance is called directly without going through
Call (https://crbug.com/v8/6786).
The Proxy constructor uses a custom construct stub
(https://crbug.com/v8/6787).
Bug: v8:6624,v8:6786,v8:6787
Change-Id: I21b883bf94bfa170d1da7aa812d09f813d881133
Reviewed-on: https://chromium-review.googlesource.com/651424
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47865}
This came up in the context of a Twitter discussion, see this particular
tweet https://twitter.com/hashseed/status/905684048382754817 and the
relevant thread.
Change-Id: If2447169df999b64ce701a44321d48ba1bff2a06
Reviewed-on: https://chromium-review.googlesource.com/654598
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47864}
This reduces the arm32 binary by around 20kB.
R=jkummerow@chromium.org, mstarzinger@chromium.org
Bug: v8:6055
Change-Id: If9098e49793b29dceb8292aff6f668ca28a07728
Reviewed-on: https://chromium-review.googlesource.com/652427
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47863}
As Blink needs a way to define a property without running a script,
make Object::DefineOwnProperty use ENTER_V8_NO_SCRIPT if the
receiver object is not a JSProxy. Quite similar to
https://crrev.com/c/v8/v8/+/608348
Bug: chromium:728583, chromedriver:1978, chromium:762385
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: If358bf0d156139c456de369ac04da2be6e626143
Reviewed-on: https://chromium-review.googlesource.com/651949
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47862}
This reduces the number of times this string is copied from two to one.
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I8680cfc1ef1d6c2cfd3bc4970fe698bb904ce328
Reviewed-on: https://chromium-review.googlesource.com/652591
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47861}
This macro is defined all over the place, and often causes macro
redefinition errors in jumbo builds. Let's make sure all such
instances created in source files are #undef'ed.
Candidate files found with:
grep -wL '#undef TRACE' $(git grep -wl '#define TRACE' -- '*.cc')
While we're at it, let's undef all macros defined in these files.
Bug: chromium:746958
Change-Id: I639ca2b141f908457d1b2601cd6d5827dee0ead0
Reviewed-on: https://chromium-review.googlesource.com/652476
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47859}
Port 30f08f39f9
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.
R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5
Reviewed-on: https://chromium-review.googlesource.com/653618
Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47858}
This is the second attempt at removing this.
Earlier (https://chromium-review.googlesource.com/579194) there were
regressions on some of the functions related to maps and sets. Now that
all of them are ported to CSA, we can remove the remaining uses of
SetForceInlineFlag.
Bug: v8:6682
Change-Id: Iebf296038aa24b65181b0d10531b0569d313e7fc
Reviewed-on: https://chromium-review.googlesource.com/647452
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47856}
Bug: v8:6333
Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
Reviewed-on: https://chromium-review.googlesource.com/651413
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47854}
JSTests.json had some poor/wrong settings.
Bug:
Change-Id: Id30589ba2392d2561037fd55d9e77a31ca6c7ad9
Reviewed-on: https://chromium-review.googlesource.com/649534
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47850}
The stack value is unused and does not need to be pushed or popped on
return from JSEntryTrampoline
Bug:
Change-Id: I0e1920fc48b63cb0eea66454e5b74d9b3c2d5956
Reviewed-on: https://chromium-review.googlesource.com/650810
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47849}
Up to now, each architecture defined all Register types as structs,
with lots of redundancy. An often found comment noted that they cannot
be classes due to initialization order problems. As these problems are
gone with C++11 constexpr constants, I now tried making Registers
classes again.
All register types now inherit from RegisterBase, which provides a
default set of methods and named constructors (like ::from_code,
code(), bit(), is_valid(), ...).
This design allows to guarantee an interesting property: Each register
is either valid, or it's the no_reg register. There are no other
invalid registers. This is guaranteed statically by the constexpr
constructor, and dynamically by ::from_code.
I decided to disallow the default constructor completely, so instead of
"Register reg;" you now need "Register reg = no_reg;". This makes
explicit how the Register is initialized.
I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
Overall, code got much more compact and more safe. In theory, it should
also increase performance (since the is_valid() check is simpler), but
this is probably not measurable.
R=mstarzinger@chromium.org
Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
Reviewed-on: https://chromium-review.googlesource.com/650927
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47847}
Do conditional jump based on the second instruction rather than
generate similar assembly code twice.
Bug:
Change-Id: I8c10f3415f213f88d8222a92671e7104c65befdc
Reviewed-on: https://chromium-review.googlesource.com/634631
Commit-Queue: Jing Bao <jing.bao@intel.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47844}
args.Call() sets a return value on args. Do not reuse the
same args object, otherwise the return value might be from the previous Call().
Bug: v8:6627
Change-Id: I05fb2d8036f94908a492d46cc5d746bc145e419e
Reviewed-on: https://chromium-review.googlesource.com/651407
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47843}
We weren't deleting them correctly - the intention was to delete
them when an instance is finalized; the code was deleting them
only for the last instance in a chain of instances.
Bug:
Change-Id: I177a64ac9f10a4993927d9654c032cb3f22eca51
Reviewed-on: https://chromium-review.googlesource.com/651238
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47841}
Port f0acede9bb
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.
R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I8007a837d43b6a339789cfd727e81ad7f4ac3ae1
Reviewed-on: https://chromium-review.googlesource.com/651891
Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47840}
This is a reland of 56772de7f9
Original change's description:
> [api] Add test for EnumeratorCallback and for...in.
>
> If a QueryCallback is present, it is used to
> filter the result from the EnumeratorCallback for
> enumerable properties. This tests assures that
> for...in loops work correctly with these interceptors.
>
> Bug: v8:6627
> Change-Id: I1e568beac1e138a330034492b87bd49c22e0c804
> Reviewed-on: https://chromium-review.googlesource.com/609982
> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47445}
TBR=adamk@chromium.org
Bug: v8:6627
Change-Id: I509016a879d175b01f7cc7918758354fe0df8ebf
Reviewed-on: https://chromium-review.googlesource.com/650906
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47838}
Only the error cases of overwriting readonly properties need the
language_mode to decide whether to throw or be silent. Reading it
from the feedback vector's metadata (just like the C++ code in
ic.cc does) removes the need to duplicate each stub for each
language_mode ("StoreIC" + "StoreICStrict" etc.).
Change-Id: Ic0c67f9d40ca36c65e41b4f162b2ab70d155e549
Reviewed-on: https://chromium-review.googlesource.com/647373
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47836}
AFAICT this doesn't currently change observable behavior, but should
be fixed nonetheless.
Change-Id: I1dce90ae5bcad39d7d54dddd2559bd7f7ccbb095
Reviewed-on: https://chromium-review.googlesource.com/648354
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47835}
The current usage pattern is always to allocate a {ModuleCompiler}, then
call {CompileToModuleObject}, then deallocate the {ModuleCompiler}.
Hence, the method can be made static and allocate the {ModuleCompiler}
internally.
This also gives back a reason for the existence of
{CompileToModuleObjectInternal}.
R=ahaas@chromium.org
Change-Id: Iac1ba28421ade6728046c0b9a6e9fc249a349491
Reviewed-on: https://chromium-review.googlesource.com/650386
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47834}
Also further tighten-up that calling DCHECK in BytecodeGraphBuilder,
and narrow the other caller to IsValidReferenceExpression.
Bug: v8:6092
Change-Id: I432a3d6f5991f2d1adf4f4f86e80d6ed8be5a0e8
Reviewed-on: https://chromium-review.googlesource.com/648196
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47833}
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}
