We already cleanup these scripts on frontend side. It is crucial to
cleanup them on backend side as well, since some web applications use
following logic: get some data from network, add this data to buffer,
try to parse buffer using JSON.parse. On each unsuccessfull JSON.parse
we get another scriptFailedToParse event.
Frontend logic of discarding scripts: https://goo.gl/FDtaWK
Some idea of smarter logic here: track what script ids are reported
using protocol and cleanup only script ids which reported not only as
part of scriptFailedToParse event.
R=alph@chromium.org
Bug: chromium:810812
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifd67764c232e4abc7dc6e8e69a651bf9ac0e381b
Reviewed-on: https://chromium-review.googlesource.com/919834
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51337}
This will enable some fuzzers to alter the thread-pool size.
Bug: v8:7455
Change-Id: Ic9c9600cdb3dc50e860dbda8432a23bb20f1dd44
Reviewed-on: https://chromium-review.googlesource.com/924273
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51335}
The ES2017 specification contains a so-called "throwaway" promise that
is used to specify the behavior of await in terms of PerformPromiseThen,
but it's actually not necessary and never exposed to user code. In
addition to that, hooking up the promise in await required a context (to
refer to the generator object) and two closures for the reject/fulfill
handling, which would resume the generator corresponding to the async
function. That meant, we had to allocate 4 additional objects for every
await.
Instead of using a JSPromise plus the callbacks, this CL adds logic to
allow PromiseReaction and PromiseReactionJobTask to carry arbitrary
payloads and Code handlers. We use this for await to avoid the
additional 4 objects mentioned above, and instead just have simple Code
handlers that resume the generator (for the async function), either by
throwing (in case of a rejection) or by resuming normally (in case of
fulfillment).
For this to work properly the JSGeneratorObject has to have a link to
the outer promise returned by the async function, so that the catch
prediction can still figure out what to do in case of promise rejection.
This is done by adding a new generator_outer_promise_symbol when the
debugger is active, which refers from the generator to the outer
promise.
With this change the doxbee-async-es2017-native test goes from around
100.54ms to around 82.45ms, which corresponds to a ~18% reduction in
execution time.
Bug: v8:7253
Change-Id: Iae25b3300bac351c3417be5ae687eff469b0e61f
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924069
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51334}
Add TurboFan inlining support for the following V8 Extras:
- v8.createPromise
- v8.rejectPromise
- v8.resolvePromise
These are used by the streams implementation in Chrome currently, and
were previously not inlined into TurboFan, although TurboFan already
had all the necessary functionality (namely the JSCreatePromise,
JSRejectPromise and JSResolvePromise operators). We might eventually
want to use these functions in Node core as well (at least short-term
for Node 10), to replace the C++ internal API functions with the same
name that are currently being used by parts of Node core.
For this to work, the rejectPromise and resolvePromise builtins had
to be moved back to CSA, as for JavaScript builtins we still have the
policy that the optimizing compiler must not inline them. But that's
straight-forward since the CSA has all the necessary functionality
available anyways.
Bug: v8:7253
Change-Id: I39ab015c379956cd58ace866e17f8ec23b2257b2
Reviewed-on: https://chromium-review.googlesource.com/924146
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51332}
This flag is the WebAssembly native heap equivalent to
FLAG_write_protect_code_memory.
R=mstarzinger@chromium.org
Bug: v8:7454
Change-Id: Id4f671af2e8676d08599c8c30ce03b00e9d33780
Reviewed-on: https://chromium-review.googlesource.com/924071
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51330}
Will be needed in a follow-up (the constants cache builder needs to
grow arrays in old space).
Bug: v8:6666
Change-Id: Ibd911ffd30e2b0f43881e649b5601111d23e4509
Reviewed-on: https://chromium-review.googlesource.com/924068
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51326}
This flag will be used to toggle things for isolate-independent
builtins during development.
Bug: v8:6666
Change-Id: I8a97f08b3d677a01a2a55a4c6445e71e74471f51
Reviewed-on: https://chromium-review.googlesource.com/924067
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51325}
This doesn't enable the warning yet, but adds V8_FALLTHROUGH annotations
in enough places so that v8 can build with the warning on on my linux box.
Found one real bug
(in effect-control-linearizer.cc,
https://chromium-review.googlesource.com/c/v8/v8/+/850392/3/src/compiler/effect-control-linearizer.cc#825
).
Bug: chromium:812686
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3542550b9c24b545641d0f0fc43f28f2780b0ab3
Reviewed-on: https://chromium-review.googlesource.com/911731
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51322}
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}
