- 10 Oct, 2018 40 commits
-
-
Ben Smith authored
Use naming similar to the spec: "table" instead of "function table", "element segment" instead of "function table init". Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff Reviewed-on: https://chromium-review.googlesource.com/c/1273612 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56545}
-
andrew-cc-chen authored
and load Change-Id: I710e82b2c2e0f4802d0efb11875a37b186828350 Reviewed-on: https://chromium-review.googlesource.com/c/1263828Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56544}
-
Junliang Yan authored
R=titzer@chromium.org Change-Id: Ia39d4ec981e6a539cc7466c7b20ff5bd85a49090 Reviewed-on: https://chromium-review.googlesource.com/c/1274266Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56543}
-
Michael Lippautz authored
This reverts commit fa65063a. Reason for revert: This changes API contract with Blink as some state is destroyed before actually tearing down the Isolate. Flushing the second round tasks then tries to access various state that is already gone on the Blink side. See bugs. Bug: chromium:893944, chromium:893549, chromium:890631 Original change's description: > [heap] Run phantom handle callbacks on tear down > > Pending phantom handle callbacks are not reliably executed if the heap > shuts down. This can cause to memory leaks or other unwanted behaviour, > like in wasm where the NativeModules (held in Managed objects > implemented via phantom handles) unregister from the WasmEngine in the > second-pass callback. This must be executed before tearing down the > WasmEngine. > > This CL fixes this by running pending callback synchronously on heap > tear down. > > R=ulan@chromium.org, mlippautz@chromium.org > > Bug: v8:8208 > Change-Id: I27b630c4d8f1fb12309040ea2179b64eed38710a > Reviewed-on: https://chromium-review.googlesource.com/1249101 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56286} TBR=ulan@chromium.org,mlippautz@chromium.org,clemensh@chromium.org Bug: v8:8208 Change-Id: I4b403fd84473edb8895c3725ff3348574c54247b Reviewed-on: https://chromium-review.googlesource.com/c/1274085 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#56542}
-
Junliang Yan authored
Port a2b34806 Original Commit Message: This CL refactors the implementation of WASM->JS import wrappers in order to make the wrapper code shareable. Instead of specializing to the import index, we use a tuple as the object ref in the both the import and indirect tables. The tuple allows the wrapper code to load both the calling instance and the target callable, rather than relying on code specialization. This requires some tricky codegen machinery, because WASM call descriptors expect an instance argument in a given register, yet the wrappers receive a tuple, the code generator must generate a prologue that loads the instance (and the callable), since it is not possible to express this at the graph level. R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I34302b8ff737296fc98c032f1e9848b4bb9fae13 Reviewed-on: https://chromium-review.googlesource.com/c/1273866Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56541}
-
Michael Lippautz authored
Pass on information about the embedder state using the fact that tasks are run from top level Bug: chromium:893944 Change-Id: I01441778770c5acc784540e496eec5c3fdb87796 Reviewed-on: https://chromium-review.googlesource.com/c/1273048 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#56540}
-
Benedikt Meurer authored
The NumberMultiply typing rule gave up in the presence of NaN inputs, but we can still infer useful ranges here and just union the result of that with the NaN propagation (similar for MinusZero propagation). This way we can still makes sense of these ranges at the uses. Bug: v8:8015 Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92 Reviewed-on: https://chromium-review.googlesource.com/c/1261143 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56539}
-
Nico Weber authored
Bug: chromium:101600, v8:8257 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie6c4f80cdec855355c0b8985e4f8a88da2ddfef9 Reviewed-on: https://chromium-review.googlesource.com/c/1273322Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56538}
-
Jaroslav Sevcik authored
Bug: chromium:866847 Change-Id: Icfda750c64c31ab48a882822883f6cef51c5bf92 Reviewed-on: https://chromium-review.googlesource.com/c/1270918Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56537}
-
Junliang Yan authored
Port 4cbec82c Original Commit Message: Pure refactoring CL. Introduce a symbolic name for the register used to hold the function index when calling the lazy compile stub. This makes it easier to see this contract when looking at the macro assembler. R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I320373dfe4734b27b85217a829bf574bc7b90a2d Reviewed-on: https://chromium-review.googlesource.com/c/1273825Reviewed-by:
-
Michael Achenbach authored
Also skip the slowest test. TBR=sergiyb@chromium.org NOTRY=true Change-Id: I9646dc750fafe47a0680e57ed029ab24a521d1a3 Reviewed-on: https://chromium-review.googlesource.com/c/1273885Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56535}
-
Mike Stanton authored
a) The current size of the backing store for the array under splice wasn't considered. Additionally, allocate the array with the normal growing strategy. b) Use primitives memcpy and memmove when appropriate. These calls are wrapped in new CSA functions MoveElements and CopyElements, which use the C functions when a write barrier isn't needed (otherwise they just copy elements in a loop). Bug: chromium:880780 Change-Id: I39a917c71036f52250c68f2cced77a1c24f97b67 Reviewed-on: https://chromium-review.googlesource.com/c/1243104 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56534}
-
David Benjamin authored
libc++'s _LIBCPP_DEBUG gets upset when comparators take non-const references. Bug: chromium:893810 Change-Id: I838ff08bfd53893984f0ce41a9d78d6f1d80a324 Reviewed-on: https://chromium-review.googlesource.com/c/1272184Reviewed-by:
-
Sigurd Schneider authored
Disable a new test that triggers a known issue with the arguments adaptor trampoline. TBR=jgruber@chromium.org Change-Id: Id89b71e49e5dbef06d75758d98ed162c07fc34f4 Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/c/1273052Reviewed-by:
-
Jakob Gruber authored
Block coverage is based on a system of ranges that can either have both a start and end position, or only a start position (so-called singleton ranges). When formatting coverage information, singletons are expanded until the end of the immediate full parent range. E.g. in: {0, 10} // Full range. {5, -1} // Singleton range. the singleton range is expanded to {5, 10}. Singletons are produced mostly for continuation counters that track whether we execute past a specific language construct. Unfortunately, continuation counters can turn up in spots that confuse our post-processing. For example: if (true) { ... block1 ... } else { ... block2 ... } If block1 produces a continuation counter, it could end up with the same start position as the else-branch counter. Since we merge identical blocks, the else-branch could incorrectly end up with an execution count of one. We need to avoid merging such cases. A full range should always take precedence over a singleton range; a singleton range should never expand to completely fill a full range. An additional post-processing pass ensures this. Bug: v8:8237 Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf Reviewed-on: https://chromium-review.googlesource.com/c/1273095Reviewed-by:Georg Neis <neis@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56531}
-
Hai Dang authored
The MapIterator protector protects the original iteration behaviors of Map.prototype.keys(), Map.prototype.values(), and Set.prototype.entries(). It does not protect the original iteration behavior of Map.prototype[Symbol.iterator](). The protector is invalidated when: * The 'next' property is set on an object where the property holder is the %MapIteratorPrototype% (e.g. because the object is that very prototype). * The 'Symbol.iterator' property is set on an object where the property holder is the %IteratorPrototype%. Note that this also invalidates the SetIterator protector (see below). The SetIterator protector protects the original iteration behavior of Set.prototype.keys(), Set.prototype.values(), Set.prototype.entries(), and Set.prototype[Symbol.iterator](). The protector is invalidated when: * The 'next' property is set on an object where the property holder is the %SetIteratorPrototype% (e.g. because the object is that very prototype). * The 'Symbol.iterator' property is set on an object where the property holder is the %SetPrototype% OR %IteratorPrototype%. This means that setting Symbol.iterator on a MapIterator object can also invalidate the SetIterator protector, and vice versa, setting Symbol.iterator on a SetIterator object can also invalidate the MapIterator. This is an over- approximation for the sake of simplicity. Bug: v8:7980 Change-Id: I54ad6e4c7f19ccc27d7001f6c4b6c8d6ea4ee871 Reviewed-on: https://chromium-review.googlesource.com/c/1273102Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#56530}
-
Marja Hölttä authored
1) As found by the GC fuzzer: missing HandleScopes. 2) The RecordSlot barrier was missing for NativeContext::AddDirtyJSWeakFactory. 3) Need Context::Scope to surround the cleanup function (if it results in an error, we try to get native_context() from Isolate). BUG=v8:8179,v8:8286 Change-Id: I2d995a76770658848e3c9629333bedbc2ef43b82 Reviewed-on: https://chromium-review.googlesource.com/c/1273051Reviewed-by:
-
Michael Lippautz authored
The API will be used to post GC tasks that benefit from being executed at top level. Bug: chromium:843903 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I062855e810ca9a8d8af8ae8b66e02c85e108798b Reviewed-on: https://chromium-review.googlesource.com/c/1273045Reviewed-by:
-
Michael Achenbach authored
TBR=marja@chromium.org Bug: v8:8286 Change-Id: I862d557c22e373c81171f0bb33b23d37157fbccd Reviewed-on: https://chromium-review.googlesource.com/c/1273120Reviewed-by:
-
Ben L. Titzer authored
Now that import wrappers are no longer specialized to an index, they can be cached in the native module, keyed by (WasmImportCallKind, FunctionSig). This saves instantiation time and also fixes a (slow) memory leak. R=mstarzinger@chromium.org Change-Id: I5197bbfae79d6e811a01289b990db445373eea6c Reviewed-on: https://chromium-review.googlesource.com/c/1270943 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#56526}
-
Toon Verwaest authored
Change-Id: I15a22e7057d5e0fa154466a0ea3d7eba3bd5721c Reviewed-on: https://chromium-review.googlesource.com/c/1273241Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56525}
-
Michael Achenbach authored
NOTRY=true Bug: chromium:893991 Change-Id: I490c02266a367d93495a2de7516486aca2c8e26c Reviewed-on: https://chromium-review.googlesource.com/c/1273118Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56524}
-
Tobias Tebbi authored
An asan bug on Windows breaks the chrome asan bot. This disables asan for the Torque build step as a workaround. Bug: chromium:893437 Change-Id: I4ccc25e7667abb3ea167c3e8af1210685ff06b9e Reviewed-on: https://chromium-review.googlesource.com/c/1273105Reviewed-by:
-
Ross McIlroy authored
Change-Id: I405172d79e0cbb043ce369ded625940178344dde Reviewed-on: https://chromium-review.googlesource.com/c/1273104Reviewed-by:
-
Matheus Marchini authored
R=bmeurer@google.com, yangguo@google.com Change-Id: Ica3f6308d92079d6602e16da31fa01488f9cc6bd Reviewed-on: https://chromium-review.googlesource.com/c/1261162 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Ben L. Titzer authored
This CL refactors the implementation of WASM->JS import wrappers in order to make the wrapper code shareable. Instead of specializing to the import index, we use a tuple as the object ref in the both the import and indirect tables. The tuple allows the wrapper code to load both the calling instance and the target callable, rather than relying on code specialization. This requires some tricky codegen machinery, because WASM call descriptors expect an instance argument in a given register, yet the wrappers receive a tuple, the code generator must generate a prologue that loads the instance (and the callable), since it is not possible to express this at the graph level. R=mstarzinger@chromium.org CC=clemensh@chromium.org Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6 Reviewed-on: https://chromium-review.googlesource.com/c/1268237 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
-
Dan Elphick authored
This is a reland of 22b56f47 Nothing has changed. This is a reland of a speculative revert. Original change's description: > [snapshot] Factor out root serialization code > > Factors out a new method Serializer::SerializeRoot which attempts to > serialize a given object as a Root if it is one and the Serializer's > policy allows that root to be serialized (implemented as a new virtual > method RootCanBeSerialized).. > > This is in preparation for adding a ReadOnlySerializer which change the > way read-only roots are serialized. > > Bug: v8:8191 > Change-Id: I7fbb4e9520fba8b836a0b6bf95ca39abc3ded79e > Reviewed-on: https://chromium-review.googlesource.com/c/1264698 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56494} TBR=jgruber Bug: v8:8191 Change-Id: I30a606b9c99f5651fae323d12f8f74b13bb085fa Reviewed-on: https://chromium-review.googlesource.com/c/1273103Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#56519}
-
Toon Verwaest authored
Change-Id: I44262469469565592c7c3f3cf29638ce65686e6f Reviewed-on: https://chromium-review.googlesource.com/c/1273078Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:6666 Change-Id: I702ca633de56a5e1228f281de89e8bf7c12002a4 Reviewed-on: https://chromium-review.googlesource.com/c/1273077Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56517}
-
Ben L. Titzer authored
Pure refactoring CL. Introduce a symbolic name for the register used to hold the function index when calling the lazy compile stub. This makes it easier to see this contract when looking at the macro assembler. R=ahaas@chromium.org CC=clemensh@chromium.org Change-Id: I714f978883ced001a1435338dcefd96744bfb2ae Reviewed-on: https://chromium-review.googlesource.com/c/1273099 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56516}
-
Sigurd Schneider authored
Change-Id: I2499c3ada16bdf51f7830847753b856aa8aaff46 Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/c/1270836 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Before adding another test for removing breakpoint, this CL modernizes the existing test for setting breakpoints. R=kozy@chromium.org CC=ahaas@chromium.org Bug: chromium:837572 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I642f9673f327f4ec569a4f67a61b5e264cf25b8f Reviewed-on: https://chromium-review.googlesource.com/c/1264636Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This reverts commit 471fef04. Reason for revert: A more general fix incoming at https://crrev.com/c/1273095. Original change's description: > [coverage] change block range to avoid ambiguity. > > By moving the block range end to left of closing bracket, > we can avoid ambiguity where an open-ended singleton range > could be both interpreted as inside the parent range, or > next to it. > > R=verwaest@chromium.org > > Bug: v8:8237 > Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a > Reviewed-on: https://chromium-review.googlesource.com/1254127 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56347} TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8237 Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834 Reviewed-on: https://chromium-review.googlesource.com/c/1273096Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
Change-Id: Ie6606869acbeadea747c4e664c78cfbffe942321 Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/c/1273135 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1a0ce50..a5cd715 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/db1e69e..83bd7f4 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Iab28e206e9aa2b0376185abb1edb0d9fc4948a3f Reviewed-on: https://chromium-review.googlesource.com/c/1273255 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#56511}
-
Sigurd Schneider authored
R=machenbach@chromium.org, sigurds@chromium.org Bug: v8:6666 Change-Id: I9ac0fc393a9f9a66bebb72abd54a429e95aa078a Reviewed-on: https://chromium-review.googlesource.com/c/1270840 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
-
Maya Lekova authored
This reverts commit 22b56f47. Reason for revert: Speculatively reverting because it increases Android binary size unexpectedly, see https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-binary-size/72572 Original change's description: > [snapshot] Factor out root serialization code > > Factors out a new method Serializer::SerializeRoot which attempts to > serialize a given object as a Root if it is one and the Serializer's > policy allows that root to be serialized (implemented as a new virtual > method RootCanBeSerialized).. > > This is in preparation for adding a ReadOnlySerializer which change the > way read-only roots are serialized. > > Bug: v8:8191 > Change-Id: I7fbb4e9520fba8b836a0b6bf95ca39abc3ded79e > Reviewed-on: https://chromium-review.googlesource.com/c/1264698 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56494} TBR=jgruber@chromium.org,delphick@chromium.org,ygg@google.com Change-Id: I7012abec0f33f655efc64dc44f7fa461d7e4b7e9 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8191 Reviewed-on: https://chromium-review.googlesource.com/c/1273098Reviewed-by:
-
Michael Achenbach authored
TBR=sergiyb@chromium.org NOTRY=true Bug: v8:8278 Change-Id: I000c31366f2b3d894208665ddb6cef49216099a6 Reviewed-on: https://chromium-review.googlesource.com/c/1273097Reviewed-by:
-
Maya Lekova authored
Bug: v8:8110 Change-Id: I5d180782aed530b059978d4d594df91aa472656a Reviewed-on: https://chromium-review.googlesource.com/c/1273015Reviewed-by:
-
Benedikt Meurer authored
This implements the editorial change in https://github.com/tc39/ecma262/pull/1146 which removes the need to allocate the throwaway promise in await (the throwaway promise was not exposed to user JavaScript anyways, but this spec change allows us to rely on this behavior). Now we still need the throwaway promise for proper before and after events with both DevTools (which might change) and PromiseHooks. So if either DevTools or PromiseHooks is on, we call into %AwaitPromisesInit, which then allocates the throwaway promise and does all the other debugger/hooks related setup. This gives around 7% improvement on the doxbee-async-es2017-native and around 1-2% on the parallel-async-es2017-native benchmarks. Bug: v8:7253, v8:8285 Ref: tc39/ecma262#1146 Tbr: ulan@chromium.org Change-Id: I972ba0538ec8c00808e95b183603025c7e55a6d3 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Reviewed-on: https://chromium-review.googlesource.com/c/1270798 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#56506}
-
