CSA::EmitElementStore used to bail out (IC miss) via
CSA::CheckForCapacityGrow when the capacity hits the new space
limit, causing the store IC to go megamorphic in my example (see
referenced bug). With this CL, we do what TF'ed code does already:
call into Runtime::kGrowArrayElements (in this situation), thus
staying monomorphic.
Here's a contrived test case:
////////////////////////
let x = [];
function bar() {
for (let i = 0; i < 50000; ++i) x[i] = i;
}
function foo() {
for (let i = x.length; i < 100e6; ++i) x[i] = i;
}
bar();
foo();
////////////////////////
This took about 4s on my machine, now it takes 3s.
Bug: v8:7447
Change-Id: I7f268fc55835f363d250613ce0357444a663051c
Reviewed-on: https://chromium-review.googlesource.com/918723
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51297}
It does the same as .toString, which is "permissible but not encouraged"
per the spec and matches our behavior for Number.prototype.toString.
Bug: v8:6791
Change-Id: I25a565391abe0d055b8ef814214ecdad254f75e2
Reviewed-on: https://chromium-review.googlesource.com/917025
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51296}
This CL introduces the FailureMessage and StackTraceFailureMessage objects.
They are force to be stack allocated and their first and last member contain
marker values. With the help of these markers we can easily extract the stored
information in external tools such as grokdump and crash.
Change-Id: Iec4f5195eec5a2bf08e1f674c9ced13d2345f030
Reviewed-on: https://chromium-review.googlesource.com/915067
Reviewed-by: Adam Klein <adamk@chromium.org>
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@{#51295}
set constant_pool_ to proper value before trying to print it
Change-Id: Iee0da126dd3641f40c1d1847e7f1ef5d6e3e58fd
Reviewed-on: https://chromium-review.googlesource.com/916890
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51292}
This makes compilation mode predicates delegate to the underlying code
kind that is already stored in each {CompilationInfo}, thereby removing
potential ambiguity between these two values.
R=mvstanton@chromium.org
Change-Id: I9f4d1bb723074488cc47bdc275984b1abc960069
Reviewed-on: https://chromium-review.googlesource.com/916195
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51291}
I fixed some spec tests since the last update, so we can turn them on
again. The problem was in the spec test itself and not in V8.
R=titzer@chromium.org
Change-Id: Id2755138293d22d49e0393b884df797a1134b6f9
Reviewed-on: https://chromium-review.googlesource.com/919041
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51290}
- Remove JS implementation of TA.p.filter
- Reimplement TA.p.filter as CSA
- This CL makes TA.p.filter 3x faster in microbenchmark
- Fix a spec bug: throw if buffer is detached while executing callback
Bug: v8:5929
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I2e14b6001d354ca6659cf65fff4ead2942ddc9ff
Reviewed-on: https://chromium-review.googlesource.com/912989
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51288}
The description will be used to annotate roots in the heap snapshot.
Bug: chromium:811842
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic5c9a89d1921cabddb06783f08ba63740e72820d
Reviewed-on: https://chromium-review.googlesource.com/916564
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51286}
This reverts commit 20e346bd08.
Reason for revert: tanks bluebird-doxbee
Original change's description:
> [parser] Remove pretenuring of closures assigned to properties
>
> This pretenuring was added in https://codereview.chromium.org/5220007,
> back when it was necessary in order to allow use of the closure
> as a "constant function" property. This should no longer be the case,
> and the pretenuring causes some unfortunate downstream effects.
>
> This patch removes the parser's setting of this bit. If it doesn't
> cause regressions on the perf bots, followup CLs will remove the
> rest of the support for this feature.
>
> Bug: v8:7442
> Change-Id: I27c43dd4293ce5de921be6c78571e712778d138a
> Reviewed-on: https://chromium-review.googlesource.com/914610
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51254}
Change-Id: I3e133046a4df64792a6652227d419239c628dbfb
Tbr: gsathya@chromium.org
Bug: v8:7442
Reviewed-on: https://chromium-review.googlesource.com/917701
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51280}
This is a reland of cee362afdb.
Original change's description:
> PPC/s390: [turbofan] Masking/poisoning in codegen (optimized code, x64)
>
> Port 8f489e73b2
>
> Original Commit Message:
>
> This introduces masking of loads with speculation bit during code generation.
> At the moment, this is done only for x64 optimized code, under the
> --branch-load-poisoning flag.
>
> Overview of changes:
> - new register configuration configuration with one register reserved for
> the speculation poison/mask (kSpeculationPoisonRegister).
> - in codegen, we introduce an update to the poison register at the starts
> of all successors of branches (and deopts) that are marked as safety
> branches (deopts).
> - in memory optimizer, we lower all field and element loads to PoisonedLoads.
> - poisoned loads are then masked in codegen with the poison register.
> * only integer loads are masked at the moment.
>
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
>
> Change-Id: I7decc16bbadf87a8c8b178278eb79a9b783f79e1
> Reviewed-on: https://chromium-review.googlesource.com/916744
> Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
> Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#51275}
Change-Id: Id22416487b05bef06c4cfdae35811a22f21cd0a0
Reviewed-on: https://chromium-review.googlesource.com/916865
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51278}
This reverts commit cee362afdb.
Reason for revert: forget to upload latest version
Original change's description:
> PPC/s390: [turbofan] Masking/poisoning in codegen (optimized code, x64)
>
> Port 8f489e73b2
>
> Original Commit Message:
>
> This introduces masking of loads with speculation bit during code generation.
> At the moment, this is done only for x64 optimized code, under the
> --branch-load-poisoning flag.
>
> Overview of changes:
> - new register configuration configuration with one register reserved for
> the speculation poison/mask (kSpeculationPoisonRegister).
> - in codegen, we introduce an update to the poison register at the starts
> of all successors of branches (and deopts) that are marked as safety
> branches (deopts).
> - in memory optimizer, we lower all field and element loads to PoisonedLoads.
> - poisoned loads are then masked in codegen with the poison register.
> * only integer loads are masked at the moment.
>
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
>
> Change-Id: I7decc16bbadf87a8c8b178278eb79a9b783f79e1
> Reviewed-on: https://chromium-review.googlesource.com/916744
> Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
> Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#51275}
TBR=mvstanton@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com
Change-Id: I7e56cdcd99b3c6004803b4502ec1054e89c1e212
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/916864
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51276}
Port 8f489e73b2
Original Commit Message:
This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only for x64 optimized code, under the
--branch-load-poisoning flag.
Overview of changes:
- new register configuration configuration with one register reserved for
the speculation poison/mask (kSpeculationPoisonRegister).
- in codegen, we introduce an update to the poison register at the starts
of all successors of branches (and deopts) that are marked as safety
branches (deopts).
- in memory optimizer, we lower all field and element loads to PoisonedLoads.
- poisoned loads are then masked in codegen with the poison register.
* only integer loads are masked at the moment.
R=mvstanton@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I7decc16bbadf87a8c8b178278eb79a9b783f79e1
Reviewed-on: https://chromium-review.googlesource.com/916744
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51275}
At the moment the flag is set too late, it is possible that the GC still
tries to post tasks in Isolate::Deinit when the isolate is already
disconnected from the platform, see the referenced bug.
R=ulan@chromium.org
Bug: chromium:810739
Change-Id: Ibcd226cb44cc903f2a46e7cccf682b3938c9d408
Reviewed-on: https://chromium-review.googlesource.com/915942
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51274}
Port a021b6c42d
Original Commit Message:
Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.
Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.
The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:798964
LOG=N
Change-Id: I4b9a1b0865b6164171cf83f0e45c36c69ac08a18
Reviewed-on: https://chromium-review.googlesource.com/914848
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51273}
This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only for x64 optimized code, under the
--branch-load-poisoning flag.
Overview of changes:
- new register configuration configuration with one register reserved for
the speculation poison/mask (kSpeculationPoisonRegister).
- in codegen, we introduce an update to the poison register at the starts
of all successors of branches (and deopts) that are marked as safety
branches (deopts).
- in memory optimizer, we lower all field and element loads to PoisonedLoads.
- poisoned loads are then masked in codegen with the poison register.
* only integer loads are masked at the moment.
Bug: chromium:798964
Change-Id: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef
Reviewed-on: https://chromium-review.googlesource.com/901625
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51272}
This decouples the checking of the {kJavaScriptCallCodeStartRegister}
from the deoptimization checks. We now rely more heavily on the above
register and should check its validity more broadly. Note that there
also is a bug fix for the ARM port contained in this change.
R=mvstanton@chromium.org
Change-Id: I27d8b72cb2b36a85dae4bbbf35e4dbcf150eac01
Reviewed-on: https://chromium-review.googlesource.com/916242
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51270}
Now that instruction cache flushing is process-wide and no longer bound
to a specific {Isolate}, we can also make setters on the {RelocInfo}
structure equally independent of the {Isolate} and remove the respective
parameter everywhere.
R=ahaas@chromium.org
Change-Id: I7b21f6f79d0d6cf73424019b9e808c3ec76de08e
Reviewed-on: https://chromium-review.googlesource.com/915922
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51269}
Change prototypes of conditional jump and set instructions,
change their implementation accordingly and port these instructions
to MIPS.
Bug: v8:6600
Change-Id: I8e2c9c874f2fde9a1c1b5a34eaa9e72475e69bc5
Reviewed-on: https://chromium-review.googlesource.com/913252
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Sreten Kovacevic <sreten.kovacevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#51268}
We don't need to pay the cost of going to JS to simply stamp out a
new object.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8942771ff9c19dff1908243fd6d3bd701d3fb5a3
Reviewed-on: https://chromium-review.googlesource.com/897803
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51267}
This is a reland of 6d5b54df82e27a82811a836dcdbbfe26829f0e6d
Original change's description:
> [cleanup] Harden the SubString CSA/Runtime implementations.
>
> Remove the self-healing for invalid parameters in the
> CodeStubAssembler::SubString helper and the %SubString runtime function,
> which is used as a fallback for the CodeStubAssembler implementation.
> All call sites must do appropriate parameter validation anyways now that
> the self-hosted JavaScript builtins using these helpers are gone, and we
> have proper contracts with the uses.
>
> Also remove the context parameter from the CodeStubAssembler::SubString
> method, which is unnecessary, since this can no longer throw an
> exception.
>
> Bug: v8:5269, v8:6936, v8:7109, v8:7137
> Change-Id: I19d93bad5f41faa0561c4561a48f78fcba99a549
> Reviewed-on: https://chromium-review.googlesource.com/795720
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49702}
Bug: v8:5269, v8:6936, v8:7109, v8:7137
Change-Id: I5e84998a2dd3990d7981505b401ffc770e0b7ac5
Reviewed-on: https://chromium-review.googlesource.com/913130
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51265}
Change-Id: I835e6c7b5520b5ab5ad796e25a197e5b43cb9e58
Reviewed-on: https://chromium-review.googlesource.com/913569
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51264}
This CL adds support for f64.const, f64.add, f64.sub and f64.mul.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I7374ede800db83303c8fa647a183fdda53a151cd
Reviewed-on: https://chromium-review.googlesource.com/913613
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51263}
The idea here is that in case the `thenable` is a JSPromise and `then`
is the initial `Promise.prototype.then` method, and the @@species lookup
chain is intact, we can skip creating the temporary promise and the
closures (with the shared context), and instead directly call into our
PerformPromiseThen. This is sound since - given above mentioned
conditions - our short-cut
PerformPromiseThen(thenable, undefined, undefined, promise_to_resolve)
is not observably different from the actual
resolve, reject = CreateResolvingFunctions(promise_to_resolve)
result_capability = NewPromiseCapability(%Promise%)
PerformPromiseThen(thenable, resolve, reject, result_capability)
except through PromiseHooks (and potentially via the async stack
traces). So we disable the fast-path if either promise hooks are enabled
or the debugger is active for now.
This improves the performance on the wikipedia benchmark by 20-25% and
the bluebird-doxbee benchmark by around 20%.
Bug: v8:7253
Change-Id: I23c92ad365c2b71d65057573f2d8febe2afe00b0
Reviewed-on: https://chromium-review.googlesource.com/911800
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51261}
This introduces dedicated builtins
- FulfillPromise,
- RejectPromise, and
- ResolvePromise,
which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.
The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.
On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.
In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.
Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.
Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
This information is useful to know whom to assign bugs to when these tests are
crashing on our infrastructure.
R=petermarshall@chromium.org
No-Try: true
Change-Id: Ia165e0236602cae73e144011537d642e3535fa6b
Reviewed-on: https://chromium-review.googlesource.com/908563
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51259}
The next Fuchsia SDK roll changes the signature and types associated
with the zx_thread_read_state() API, so we temporarily need backward-
compatibility shims while we roll the SDK/Chromium/V8.
Bug: chromium:707030
Change-Id: I419a65bbb631a1ef0d7d5044b07d4cbbac08970f
Reviewed-on: https://chromium-review.googlesource.com/914695
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51256}
This pretenuring was added in https://codereview.chromium.org/5220007,
back when it was necessary in order to allow use of the closure
as a "constant function" property. This should no longer be the case,
and the pretenuring causes some unfortunate downstream effects.
This patch removes the parser's setting of this bit. If it doesn't
cause regressions on the perf bots, followup CLs will remove the
rest of the support for this feature.
Bug: v8:7442
Change-Id: I27c43dd4293ce5de921be6c78571e712778d138a
Reviewed-on: https://chromium-review.googlesource.com/914610
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51254}
