- 10 Oct, 2018 35 commits
-
-
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:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: David Benjamin <davidben@chromium.org> Cr-Commit-Position: refs/heads/master@{#56533}
-
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:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56532}
-
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:
Ulan Degenbaev <ulan@chromium.org> Reviewed-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:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56527}
-
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:
Andreas Haas <ahaas@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}
-
Toon Verwaest authored
Divide MarkExpressionAsAssigned into MarkExpressionAsAssigned and MarkPatternAsAssigned so it's clear when we need to mark just a single variable or an entire destructuring assignment pattern. Change-Id: Ia188b3d9b15944a1859676f483df229225ce8404 Reviewed-on: https://chromium-review.googlesource.com/c/1270945 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Hai Dang authored
Bug: v8:7980 Change-Id: I640119fc9a9af66370c47f4d5b16244a1cc3f716 Reviewed-on: https://chromium-review.googlesource.com/c/1256810 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by:
-
Toon Verwaest authored
Change-Id: Icdab6d279ca42bf44f29db257484acd74666baab Reviewed-on: https://chromium-review.googlesource.com/c/1273075Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56503}
-
Benedikt Meurer authored
This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a7674ea..1a0ce50 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/9ec8468..357c5c2 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/71e3be7..db1e69e Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/c52a2a2..ccad447 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7792d28..2e889f5 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I103aff00a9a5c2218c6152a9da8d0307a2cb07c1 Reviewed-on: https://chromium-review.googlesource.com/c/1272192 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
-
Igor Sheludko authored
... and remove Heap::RootCanBeWrittenAfterInitialization() and Heap::RootCanBeTreatedAsConstant() in favour of RootsTable::IsImmortalImmovable(). Bug: v8:8238 Change-Id: I804d06136de9584b8c4940fd8ab9d18fb3ef7980 Reviewed-on: https://chromium-review.googlesource.com/c/1270837 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
- 09 Oct, 2018 5 commits
-
-
Michael Lippautz authored
Change-Id: Ib24a7f2c8c69828c5457595f891dbcb6b2a70296 Reviewed-on: https://chromium-review.googlesource.com/c/1270923Reviewed-by:
-
Michael Lippautz authored
Provide flag to set a deterministic GC schedule. The GC still uses multiple tasks but on a fixed growing strategy. Change-Id: I937cf77ae0b0d1e513d4976a23c7f23a151d77c5 Reviewed-on: https://chromium-review.googlesource.com/c/1270838 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
Pair operations needed more than 5 registers; this allows one operand to go into a slot or an immediate, which allows pair operations even if ebx if not allocatable because it holds the root register. Change-Id: Ic08b2e0ca93744a434e3d41af97da45b779756aa Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/c/1271055 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
This flag stresses different interleavings of background and foreground tasks by delaying the execution of each task by a random value between 0 and 100ms (with a quadratic distribution favoring smaller delayes). The implementation is encapsulated in the new {DelayedTasksPlatform} class, which wraps each task in a {DelayedTask} which first sleeps for the given number of microseconds, then executes the actual task. Both the old {PredictablePlatform} and the new {DelayedTasksPlatform} are moved to the new d8-platforms.cc file with an interface to create them in d8-platforms.h. R=yangguo@chromium.org, mslekova@chromium.org Bug: v8:8278 Change-Id: I5847fb2da31ffde773195da7ad3f56a0390cc05b Reviewed-on: https://chromium-review.googlesource.com/c/1270592 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Sergiy Byelozyorov authored
This is a reland of 2bac24fe Original change's description: > [tools] Report infra failure on incorrect usage or uncaptured exceptions > > TBR=machenbach@chromium.org > > No-Try: true > Bug: chromium:893464 > Change-Id: If7d9f839a715468ded293a488e7fa12fc4ef3347 > Reviewed-on: https://chromium-review.googlesource.com/c/1270995 > Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> > Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56485} TBR=machenbach@google.com Test: ran run_perf_test.py locally (it reports same errors as before this CL) No-Try: true Bug: chromium:893464 Change-Id: I1bb2fae6fe2e2b7350695e491d7c3d52ff06db14 Reviewed-on: https://chromium-review.googlesource.com/c/1270965 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#56495}
-
