When decoding a br_table instruction, check each br target only once,
even if it appears several times in the break table.
Also, only mark the merge points as reached after calling the interface
method. This is consistent with the behaviour for br and br_if, and is
needed for implementing Liftoff correctly.
Drive-by: Remove {BreakTo} method which hides trivial functionality
behind a non-trivial method name.
Drive-by^2: Remove redundant reachability tests.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I3f2678c0a6b801b94065dc3e0d452bc2ff82dd50
Reviewed-on: https://chromium-review.googlesource.com/921581
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51321}
Tbr: jarin@chromium.org
Change-Id: I17477e2c82398b228a366a3d1fd8eb521dd51eae
Reviewed-on: https://chromium-review.googlesource.com/922270
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51317}
The call to isolate_->AdjustAmountOfExternalAllocatedMemory in
WasmCodeManager::FreeNativeModuleMemories can cause a GC, which can
indirectly call WasmCodeManager::FreeNativeModuleMemories again. It
seems that this recursive call can cause memory to be deallocated
twice. With this CL we clear the list of owned_memory after all entries
were deallocated so that we cannot deallocate them again.
I think this CL fixes a crash we saw on ChromeCrash. I don't know how
to reproduce the issue though, or how to write a test for it.
R=mstarzinger@chromium.org
Bug: chromium:812532
Change-Id: I3b66274f9b72919952a4211e984192c0867a6c22
Reviewed-on: https://chromium-review.googlesource.com/921226
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51312}
This is a reland of af677f29b1, fixing
an issue with negative indices.
Original change's description:
> [ic] EmitElementStore: don't miss when hitting new space limit.
>
> 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}
Bug: v8:7447, chromium:812451
Change-Id: I345b5e5b2437c4f50e42bbd87947630f24cd95eb
Reviewed-on: https://chromium-review.googlesource.com/921201
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51311}
instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
In some workloads the Unmapper could reach kMaxUnmapperTasks at which
point it wouldn't start any new tasks and not free any more memory
until the next major GC. It could lead to a large buildup of memory in
the Unmapper.
Bug: v8:7440
Change-Id: I23fda67b2e27824c04ac886d7e111bb01188be74
Reviewed-on: https://chromium-review.googlesource.com/913490
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51308}
This reverts commit af677f29b1.
Reason for revert: Clusterfuzz found an issue.
Original change's description:
> [ic] EmitElementStore: don't miss when hitting new space limit.
>
> 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}
TBR=neis@chromium.org,bmeurer@chromium.org
Change-Id: I34eef5919cbdef1b35512aa98ac2de0ae5fcc7cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7447
Reviewed-on: https://chromium-review.googlesource.com/921121
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51306}
The WasmModuleObjectBuilder was the first interface for streaming
compilation of WebAssembly. Over time we realized that the interface
is insufficient, and we introduced the WasmModuleObjectBuilderStreaming
class, which is used now for streaming compilation. Since the
WasmModuleObjectBuilder was never fully functional, I think it is okay
to remove it without a deprecation period.
R=clemensh@chromium.org, adamk@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia3ac5f150fdad7bc1ad04ba89aee53538d43ce01
Reviewed-on: https://chromium-review.googlesource.com/913614
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51305}
Apparently it can happen that the variable to which we're restoring to has a
two-byte name corresponding to the one-byte name we expect. Modify the debug-mode
name check to allow this.
BUG=v8:7428
Change-Id: I94c56a4b2de3c58b50246fecaead332b0f9679b4
Reviewed-on: https://chromium-review.googlesource.com/911801
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51304}
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}
