- 06 Mar, 2020 18 commits
-
-
Zhao Jiazhong authored
Port fd735e84 https://crrev.com/c/2067631 Change-Id: I720c4e218ea7a6088c61c2411c7c74e636f0772a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089228Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66619}
-
Ng Zhi An authored
Bug: v8:10233 Change-Id: I8bb564e595d5c2b093adea0b9dde9c1c86dcee70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084318Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66618}
-
Nate Chapin authored
This state can be set on the NativeContext by the embedder. When a PromiseReaction/PromiseReactionJobTask is constructed, store this contextual state if present, and restore it while the reaction job is running. Change-Id: I141cdbd9e36ea83ce4a6bf08440ae7eaa54523df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005849Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/master@{#66617}
-
Ng Zhi An authored
Implement f64x2, i64x2, i8x16 splats on arm and arm64. Bug: v8:9909 Change-Id: I41f635ae5c6f025ece7f6445a58fbad1ad678fbd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087694Reviewed-by:
-
Zhao Jiazhong authored
Port 820faa6e https://crrev.com/c/2056468 Original Commit Message: The arm/arm64 simulators debugger has a command "mem" that prints the content of the memory. It also prints a short summary for JS objects (SMI, Array, JSFunction, ...). That is very handy, but when trying to print incomplete initialized memory, it could raise an exception. It is useful to have a command that prints the content of the memory for non-initialized or bogus values without the risk of raising an exception. This CL adds the command "dump". Change-Id: If8c96d7bac4a484c2a4fee9d192a29ea2696580a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089224Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66615}
-
Milad Farazmand authored
Port fd735e84 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I8a46492241be9686da2220cb99162c9610962b5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091212Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66614}
-
Andreas Haas authored
Prefixed opcodes do not get written correctly in code comments in Liftoff. The reason is that only one byte is interpreted as the opcode, but prefixed opcodes take two bytes. This CL loads the second byte if necessary. The change could be done in function-body-decoder-impl.h, but that could lead to performance regressions: it is a hot code path, and the change here is just for debugging. R=clemensb@chromium.org Bug: v8:10155 Change-Id: I2282c068c81b5b1e2e2ed9757f4e77687d1d4ede Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091467Reviewed-by:
-
Pierre Langlois authored
Comments on this reservation indicate it may hold either only code pages or code and data pages if pointer compression is enabled. But in fact it only holds the reservation for code pages. Change-Id: Ic007fcadf881153b69dce51db561777cc52685bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091465Reviewed-by:
-
Clemens Backes authored
The test started failing (sometimes flaking) on an unrelated CL. R=gsathya@chromium.org Bug: v8:10307 Change-Id: If198c2cf518f7a36e54614307462272774d9e48e No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091466Reviewed-by:
-
Andreas Haas authored
This CL fixes a special case where a WasmExportedFunction is passed to the WebAssembly.Function constructor. This is a case that was not yet implemented in V8, and which is also not specified in the proposal yet. With this CL we do a signature check of the provided function. If it matches, the function itself is returned. Otherwise a TypeError is thrown. I filed an issue: https://github.com/WebAssembly/js-types/issues/13 R=jkummerow@chromium.org Bug: chromium:1057534 Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66610}
-
Zhao Jiazhong authored
Port 7ad6b04e https://crrev.com/c/2080362 Change-Id: Iac305bf76c5a602bd238310fed0828e5ea95cd0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084323Reviewed-by:
-
Vitaly Buka authored
Bug: chromium:1055312, chromium:977230 Change-Id: I2ee8776b5118b07e414a1e88e43cc42ab82ecc64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090982Reviewed-by:
-
Andreas Haas authored
All other simple C functions take a pointer to a stack slot which contains the actual parameters, whereas the memory_copy_wrapper takes three parameters. This makes the code generation from Liftoff more difficult. This CL changes the signature of memory_copy_wrapper to match the signature of other simple C functions. As MemoryCopy and MemoryInit are already implemented with C calls, this change should not make a big difference in terms of performance. Simpler and smaller Liftoff code may have more effect on performance. If this assumption turns out wrong, we can change it in the future. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I39e0ea00fcb22b4e84e612fe58eb4642856b72c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078576 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
This adds two new histograms: - V8.MeasureMemoryDelayMilliseconds measures how long it takes to serve a memory measurement request - V8.GCFinalizeMCMeasureMemory is a variant of the existing GC pause histogram that used when GC runs in memory measurement mode. Additionally this CL lowers the maximum measurement delay to 10 seconds. Bug: chromium:1049093 Change-Id: I97cbf443da514a69d6cf8c1d74d2757098e60acd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089937Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66606}
-
Milad Farazmand authored
Change-Id: Id5d6d1b2b6c06a2c4d1712bfa281bce18fb1320a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090533Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/fa4450f..e393474 Rolling v8/third_party/aemu-linux-x64: hvClQbzFhJApEEpHpfc8UqpDdzLK0eabIbmpPlfODp8C..7YlCgase5GlIanqHn-nZClSlZ5kQETJyVUYRF7Jjy6UC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f6edc90..b3bfbaa Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fe6f752..ee8be8a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d548cda..101bca1 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5ab721e9e72c0f7bae5790dbde73478c6ba78d61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089726Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66604}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I8dc5d0143d90ecad6766c686af2d3f0f8ea89c16 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2067631Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10180 Change-Id: If8dd729739854ee0bc08bf71100f48de6a0437b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084321Reviewed-by:
-
- 05 Mar, 2020 13 commits
-
-
Zhao Jiazhong authored
Port 34f9bcdb https://crrev.com/c/2067845 Original Commit Message: Implements i8x16.abs, i16x8.abs, and i32x4.abs. Change-Id: I95800caa298860326e3deadea2fce71640ae0227 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2086532Reviewed-by:
-
Andrey Kosyakov authored
This retrieves script name directly from StackFrameBase, bypassing building of StackFrameInfo if one hasn't already been initialized, thus avoiding computation of expensive properties that are not required. Bug: chromium:1057211 Change-Id: I91eaecdbaee6f5834a02d70e2df872e82998ab83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080663 Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#66600}
-
Vitaly Buka authored
Change-Id: Ie7ccf955ea629eec612a80e264ac71050cbc4cff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090531 Commit-Queue: Vitaly Buka <vitalybuka@chromium.org> Auto-Submit: Vitaly Buka <vitalybuka@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#66599}
-
Clemens Backes authored
This is a reland of 79398ab0 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934Reviewed-by:
-
Clemens Backes authored
This reverts commit 79398ab0. Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org Change-Id: Id80aa82cfce8942879031032b322ee66855b5600 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10254 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933Reviewed-by:
-
Clemens Backes authored
Also, save dynamic allocations (plus their memory overhead). This is realized by storing the relocation information, source position table, and protected instruction information together in one "metadata" byte array. For each of the three components, we just store their size, such that the accessors can return the respecitive {Vector} views as before. This makes each WasmCode object 24 bytes smaller on 64-bit architectures. It also saves a few more bytes per code object because less padding is needed for the individual allocations, and each dynamic allocation comes with some constant memory overhead. Since the protected instructions will just be stored in a byte array now, some APIs are refactored to just return that byte array directly (instead of an array of {ProtectedInstructionData}). This also simplifies serialization and deserialization, and will allow for switching to a more compact representation in the future. Drive-by: Add some more checks to {Vector::cast} to protect against undefined behaviour. R=ahaas@chromium.org Bug: v8:10254 Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545Reviewed-by:Andreas Haas <ahaas@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66596}
-
Victor Gomes authored
- Create a PushArray to simplify code. - Adapt all the sites in builtins-x64. Bug: v8:10201 Change-Id: I828f4d2e43373a4fe6380346c5628a345720fe38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083028Reviewed-by:
-
Zhao Jiazhong authored
Port 9245e3b4 https://crrev.com/c/2049247 Change-Id: Ic2df706a4d5f7df8a2cdb4f53c4679cf96f0b8b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2086535Reviewed-by:
-
Victor Gomes authored
Bug: v8:10201 Change-Id: I2271602b2da6fd06038ddfab16090d7faac592ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074218 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This fixes a non-determinism issue caused by the cache being full. Depending on the non-deterministic value of the handles in HeapConstant nodes, different cache entries would be overwritten in this case. The old implementation of NodeCache had a fixed limit, overwriting entries when the cache is full. This behavior didn't really make sense, but the hand-written hash map implementation couldn't handle arbitrary numbers of hash collisions, so removing the limit wasn't an option either. Thus this CL just replaces the custom hash map with a normal std::unordered_map, that is, a ZoneUnorderedMap. Bug: chromium:1046815 Change-Id: I95269f2b1068eb9dfe3ee2ab5cca1cb460bc8fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087405Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
-
Dan Elphick authored
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by taking advantage of SparseInputMask data structure to more quickly handle empty inputs and insert all the OptimizedOut entries in one go. The number of empty inputs is now determined using CountTrailingZeros rather than iterating over them one at a time. Gives a 9% improvement to SelectInstructions runtime call stat for Octane in turboprop. Bug: v8:10051 Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Georg Neis authored
Change-Id: I6094bc17e8a482f166bdb53e5d2dabe9a1299c9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087409 Commit-Queue: Dan Elphick <delphick@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#66590}
-
Vitaly Buka authored
It's probably possible to limit this to a few variables. However, at the moment I am able to create a patch with tens of V8_STACK_UNINITIALIZED. It seems tiny changes in functions sizes causes significant changes in optimizer behavior. For now I'd like just to restore the perf. Bug: chromium:1055312, chromium:977230 Change-Id: I48efc3c872a4039b253011b70baf40763e181a20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087452 Commit-Queue: Vitaly Buka <vitalybuka@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66589}
-
- 04 Mar, 2020 9 commits
-
-
Ng Zhi An authored
Bug: v8:9561 Change-Id: I5fbf69aaacccfe588f95edf1208176e3a7de62bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071397Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9561 Change-Id: I4a2c6217dea540b81256dcc833412da573f54795 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069403Reviewed-by:
-
Timothy Gu authored
This is a reland of 93253978 Original change's description: > Use context of then function for PromiseResolveThenableJob > > When a microtask is executed, we need to use an appropriate, > non-detached Context for its execution. Currently with > PromiseResolveThenableJobs [1], the Context used is always drawn from > the realm of the Promise constructor being used. This may cause > non-intuitive behavior, such as in the following case: > > const DeadPromise = iframe.contentWindow.Promise; > const p = DeadPromise.resolve({ > then() { > return { success: true }; > } > }); > p.then(result => { console.log(result); }); > > // Some time later, but synchronously... > iframe.src = "http://example.com"; // navigate away. > // DeadPromise's Context is detached state now. > // p never gets resolved, and its reaction handler never gets called. > > To fix this behavior, when PromiseResolveThenableJob is being queued up, > the `then` method of the thenable should be used to determine the > context of the resultant microtask. Doing so aligns with Firefox, and > also with the latest HTML spec [2][3]. > > This change is analogous to CL 1465902, which uses the realm of the > reaction handlers to determine the Context PromiseReactionJobs run in. > > [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob > [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments) > [3]: https://github.com/whatwg/html/pull/5212 > > Bug: v8:10200 > Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624 > Commit-Queue: Timothy Gu <timothygu@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66507} Bug: v8:10200 Change-Id: I5af003a06c60b0c8cd19de47f847a947d40d046c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082109Reviewed-by:
-
Igor Sheludko authored
This CL simplifies IC code since we no longer need to keep feedback slot indices in both Smi and IntPtr form and as a result it should improve overall performance of --no-opt mode on Octane by ~1%. Bug: v8:10047 Change-Id: Ib717697cdb805c9f93286e9c62ee8a63361d3560 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965586 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66585}
-
Milad Farazmand authored
Change-Id: I84d53282278d12c2e47b8e9a07b69ecf89dba237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087692 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Sami Kyostila authored
This patch rolls v8 to the latest Perfetto revision. Since Perfetto has changed the way the GN protobuf integration works, we need to make some corresponding changes in V8. Bug: chromium:639003 Change-Id: I263c591560503c9779bbab3ec266cfb2708fc51f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2085175Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Camillo Bruni authored
Drive-by-fix: Add V8_WARN_UNUSED_RESULT to MaybeHandle::ToHandle Bug: chromium:1057653 Change-Id: I2834806ca498a2fa43a64f5391606cdbfb4af4fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084814Reviewed-by:
-
Ulan Degenbaev authored
This reverts part of f3babafb that removed the scope in the test function Bug: v8:10298 Change-Id: I3c515307b9ea4d03e0d7427422d46302e78d8b38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087395Reviewed-by:
-
Leszek Swirski authored
Add off-thread support for class boilerplate allocation, removing a previously "unreachable" overload. Notably, this requires support for off-thread allocation of Dictionaries and DescriptorArrays. Due to template fun, the off-thread allocation of Dictionaries in particular requires some amount of boilerplate (no pun intended). Bug: chromium:1011762 Change-Id: I37139d924858e31e45d369742329826784a8f614 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080370 Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
