Daniel Bratell reports:
> v8 had a couple of files that were very slow to compile before jumbo
> and if those now end up in the same translation unit, then I can see
> how that translation unit can take an extreme time to get through
> the compiler.
>
> From one of my test builds (times in seconds):
> 49.7 v8_base/objects.o
> 44.0 v8_base/code-stub-assembler.o
> 32.9 v8_base/api.o
> 30.5 v8_base/elements.o
> 25.9 v8_builtins_generators/builtins-regexp-gen.o
> 22.8 v8_base/parser.o
> 21.2 v8_base/heap.o
>
> All of these are in the slowest 0.1% ninja jobs so they are extreme
> in some way. I think I would just exclude them all (or at least the
> 30s+ ones) completely from jumbo.
BUG=chromium:746958
Change-Id: I01741109def4f9ac7c946319374076eb7b9d03b6
Reviewed-on: https://chromium-review.googlesource.com/637971
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47703}
This CL introduces two tests to verify that the correct memory is
accessed when a wasm module invokes an wasm function imported from a
second module that accesses its (i.e., second module's) memory.
The first test verifies that the second module's memory is accessed in
case the first module does not have memory. In the second test, both the
modules have memory.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I75c3a5335583a91af0e7e4179c482142165b1c01
Reviewed-on: https://chromium-review.googlesource.com/637837
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47702}
To enable executing code in a context of a particular time or date (e.g. when
codepath depends on whether it's say evening or New Year) there is a need for
a way to provide it bypassing actual system time.
Bug: chromium:751993
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iee35d97b74345f63fff814a65a6f134d7c970341
Reviewed-on: https://chromium-review.googlesource.com/598666
Commit-Queue: Sergei Datsenko <dats@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47700}
Introduce a proper empty_descriptor_array, which has the proper layout
(length is 2 and the two fields are set properly). Also add a special
EnumCache class and a matching empty_enum_cache. The contract now is
that we only need to check the EnumLength on the map to know whether we
are allowed to use the enum cache. This greatly simplifies the handling
of the enum cache (and also the descriptor arrays), especially for the
future work on optimizing keyed access via the enum cache indices.
Bug: v8:6702
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83
Reviewed-on: https://chromium-review.googlesource.com/641030
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47697}
Also rename options key from "no_network" to "network" to avoid
too many levels of double-negatives.
Change-Id: I6d29edce8abde64199b27ef0f3453ab370a9937b
Reviewed-on: https://chromium-review.googlesource.com/642516
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47695}
Port 51a1514016
Original Commit Message:
This change adapts the Call bytecode handlers such that they don't require
a stack frame. It does this by modifying the call bytecode handler to
tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
callee function will return to the InterpreterEntryTrampoline when it returns
(since this is the return address on the interpreter frame), which is
adapted to dispatch to the next bytecode handler. The return bytecode
handler is modified to tail-call a new InterpreterExitTramoline instead
of returning to the InterpreterEntryTrampoline.
Overall this significanlty reduces the amount of stack space required for
interpreter frames, increasing the maximum depth of recursive calls from
around 6000 to around 12,500 on x64.
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:753705
LOG=N
Change-Id: Ieac490d82098c13741080061eda762d54baf8c04
Reviewed-on: https://chromium-review.googlesource.com/639315
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47694}
There was only one case where this wasn't the case, having to do with
variable declarations, and for that case the information need not
actually be stored on the block, but should rather be propagated
to the VariableProxy.
Bug: v8:6092
Change-Id: I0d0025ec73d3dd4f9402606105d3e883a9417283
Reviewed-on: https://chromium-review.googlesource.com/639911
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47692}
The vast majority of callers pass null |labels| and kNoSourcePosition,
so make those the default arguments.
Bug: v8:6092
Change-Id: Ifac3f0d49f56b680ec75b1a7afde5e5e788d9cfd
Reviewed-on: https://chromium-review.googlesource.com/639761
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47691}
Also remove last internal callers of the to-be-deprecated APIs.
Bug: v8:2487
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id72cf363eac86e4b4dbf7df83bdb848071260b90
Reviewed-on: https://chromium-review.googlesource.com/639326
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47690}
The vast majority of blocks we create in the parser have no associated
labels, so it seems silly to waste a pointer on labels_ for all such
blocks.
This is accomplished by delegating responsibility for labels storage to
each subclass of BreakableStatement, and then further-specializing Block
by creating a new subclass, LabeledBlock.
Bug: v8:6092
Change-Id: I88c824639254e5890b25a86cc156bfc4310bf2b1
Reviewed-on: https://chromium-review.googlesource.com/639063
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47689}
Also a few bits of related dead code in Parser.
Bug: v8:6092
Change-Id: Ie30aa1bd769b78fec2563fc6ba82ef0bcd7668bb
Reviewed-on: https://chromium-review.googlesource.com/639311
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47688}
This reimplements functionality that was present before the decoder
refactoring. It's implemented a bit differently though by generating
the code for re-throwing an uncaught exception earlier (when generating
code for the catch).
R=titzer@chromium.org, kschimpf@chromium.org
Bug: v8:6600
Change-Id: Ie2f11837851c0602ab31506fa63475fc2d0b5047
Reviewed-on: https://chromium-review.googlesource.com/641550
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47687}
The score is computed based on how often the benchmark's function can
be run within one second. Simply importing a Module repeatedly doesn't
do any work, so to make the test score meaningful, we must wrap the
payload into a function that can be called explicitly for every run.
NOTRY=true
Bug: v8:1569
Change-Id: Iadaed6df1f1652d8860271e327c505f0b8f20c2d
Reviewed-on: https://chromium-review.googlesource.com/639396
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47686}
This simplfies the code for lowering of {JSCreateArguments} nodes under
the assumption that deoptimization support is always enabled, and that
arguments objects are only materialized for JavaScript frames and not
for internal stub frames.
R=tebbi@chromium.org
Change-Id: I5f86ae0f0442a03b516904d737c5a0eac293b5b9
Reviewed-on: https://chromium-review.googlesource.com/640381
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47685}
Crashes are still happening despite tentative fixes, but unfortunately
without a local repro. This adds a couple of additional checks to help
flush out the root cause.
TBR=yangguo@chromium.org
Bug: chromium:754422
Change-Id: Ib3c8a2e0271fc724a4351ce6aec8298cf520a20a
Reviewed-on: https://chromium-review.googlesource.com/640691
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47684}
The current processing of a transition array is not safe because the
targets in the array have conditional weakness, which can change
concurrently.
Bug: chromium:694255
Change-Id: I86bf7151af39307dc4101a0b0ca02ef7c704df53
Reviewed-on: https://chromium-review.googlesource.com/641410
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47682}
Originally the call to RelocatableMemoryReferences() in
WasmCompiledModule::Reset() was guarded behind a condition.This
condition, however, is redundant, because it is checked later
again when the code is patched. This CL removes the check in
WasmCompiledModule::Reset().
R=clemensh@chromium.org
Change-Id: I10d277072f2223c2e067789a1efc3bd259f0ce5e
Reviewed-on: https://chromium-review.googlesource.com/640709
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47679}
This is a reland of 6b4dc039a6
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org
Bug: v8:6600
Change-Id: Idd867c5a1917437de5b6e3de5917cc1c9f194489
Reviewed-on: https://chromium-review.googlesource.com/640591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47678}
It's disabled in gn and on several platforms, so also disable it for
linux systems in general.
R=machenbach@chromium.org
Change-Id: Id5d0e5d30cc27c449d05352df6dd0aade5d9e6fd
Reviewed-on: https://chromium-review.googlesource.com/640708
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47677}
This adds support to specify the maximum memory size when building a
WebAssembly module. Default is not maximum, one can be explicitly set.
It is mainly used by the WebAssembly fuzzers to prevent OOMs.
R=ahaas@chromium.org
BUG=chromium:759973
Change-Id: Ibf5fa63a7e36e5f3b65ced528c73a65355d5632f
Reviewed-on: https://chromium-review.googlesource.com/640386
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47676}
This CL introduces 4 test that verify that the effects of a grow_memory
instruction executed in a function invoked inside a loop are visible
also when the loop is over. This is needed because the
AnalyzeLoopAssignment method in function-body-decoder.cc is creating Phi
nodes only for variables assigned inside the loop. The test cases
introduced by this CL verify that the mem_size and mem_start variables
are always correct.
The tests verify the output of the current_memory instruction and the
result of loading a variable stored in the grown memory inside the
loop in the following cases:
* the memory is grown in a directly called function inside a loop;
* the memory is grown in an indirectly called function inside a loop.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I2992bf4086b5eac9580c87e2e0ca06364b99714c
Reviewed-on: https://chromium-review.googlesource.com/637911
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47674}
We reset profiler ticks when the feedback changes so that we could tier
up functions with more stable feedback. We missed resetting these ticks
for call / construct bytecodes. This cl fixes it.
Bug:
Change-Id: Ia912dfee0495c776d9fc517a887a2fdd999773ab
Reviewed-on: https://chromium-review.googlesource.com/635846
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47673}
This reverts commit 6b4dc039a6.
Reason for revert: Mips build failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/11749
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I76a50e355f0390cc53a2da4ceedd8830ca20a9c6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600
Reviewed-on: https://chromium-review.googlesource.com/640870
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47672}
This refactoring separates graph building from wasm decoding. The
WasmGraphBuilder is just a consumer of the decoded information.
Decoding without any consumer (i.e. just validation) gets 16% faster by
this refactoring, because no TFNode* have to be stored in the value
stack, and all dynamic tests to determine whether the graph should be
build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
92.2 +- 3.1 ms).
This new design will allow us to also attach other consumers, e.g. a
new baseline compiler.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
Reviewed-on: https://chromium-review.googlesource.com/571010
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47671}
This removes overflow check in addition when we have Smi or
Int32 feedback for the addition, and the result is truncated
to word32. Here is an example, assuming that we passed only
integers to this function so far.
function f(a) { return a + 1 | 0; }
If the result of the addition is word32-truncated, there is no need
for an overflow check.
Until now, we would only eliminate the overflow check
if we knew that the static types of the inputs guaranteed that
the result is in safe integer range. With this CL, we use the
checked type from the feedback, too (but we do not propagate the
truncation!).
Bug: v8:5267,v8:6764
Change-Id: Ia2f929600758f58e6e7db52fef638a0e56c936a9
Reviewed-on: https://chromium-review.googlesource.com/635083
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47668}
Make sure there is a matching Leave for each Enter. Otherwise it ends up
with a dead stack-allocated object in the timer chain.
The patch incorporates the following fixes:
- RuntimeCallTimerScope::RuntimeCallTimerScope(HeapObject* ...) did create a
local object instead of calling an overloaded constructor.
- InterpreterCompilationJob::ExecuteJobImpl made an implicit call to a default
copy constructor of TimerScope which led to a single Enter was made per two
Leaves.
- InterpreterCompilationJob::FinalizeJobImpl was calling RuntimeCallTimerScope
from a background thread, which caused timer scopes become unbalanced.
- RuntimeCallTimerScope constructors were put into counters-inl.h which is not
included into most usages of RCS. That led to a suboptimal performance.
- Added thread check into Enter and Leave
BUG=chromium:669329
Change-Id: Ib5cff0e02e0b6c8b56a03ca3a5ebc37d93fcde55
Reviewed-on: https://chromium-review.googlesource.com/637307
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47666}
When we use a WasmCompiledModule for a second instance (i.e. the first
instance has been collected already by the GC), we reset all instance
specialization data the WasmCompiledModule contains, and then patch in
the new instance specialization data. However, we guarded the reset of
memory references, and in the referenced issue the memory references
were not reset and therefore later patched incorrectly during
instantiation. With this CL we change the condition and reset now every
time the current version of a WasmCompiledModule contains non-default
values.
R=mtrofin@chromium.org
CC=mstarzinger@chromium.org
TEST=mjsunit/regress/regress-crbug-759327
Bug: chromium:759327
Change-Id: I9a147afd6ad4000b782850dae0b90685759c9dc7
Reviewed-on: https://chromium-review.googlesource.com/638571
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47665}
This won't affect the real release but will give more clusterfuzz + test
coverage on V8 side.
BUG=v8:5516
Change-Id: I6ed29b1a1b23b5bf1ce9a9a9dfe741c53312ee54
Reviewed-on: https://chromium-review.googlesource.com/640373
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47664}
The validator was trying to finalize virtual register assignments in
phi cases, however, since phis may create aliases, we ended up with
an unnecessarily complex design that was the source of pretty much all
validator bugs since its introduction.
This change embraces the fact that phis may create aliases: pending
assessments (==phis) carry a bag of aliased virtual registers.
Bug: chromium:758778
Change-Id: Ib7ded350a726fbc77e9d0ff3eeda7f00acc4de13
Reviewed-on: https://chromium-review.googlesource.com/639530
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47657}
As part of J2V8 development (https://github.com/eclipsesource/J2V8),
we realized that we had a subtle bug in how Isolate scope was created
and it's lifetime managed, see:
https://github.com/eclipsesource/J2V8/issues/313.
Mentioned above bug was fixed, however, what we also noticed is that
V8 API has been constantly and slowly moving to such an API, in which
one has to pass Isolate explicitly to methods and/or constructors. We
found two more places that might have been overlooked. This contribution
adds passing of Isolate pointer explicitly to constructors of
String::Utf8Value and String::Value classes.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I61984285f152aba5ca922100cf3df913a9cb2cea
Reviewed-on: https://chromium-review.googlesource.com/593309
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47656}
