In snapshots with several contexts, some contexts may not reference
function or object templates, and therefore would not require external
references for deserialization. However, function and object templates
are deserialized with the isolate as part of the partial snapshot cache,
so we would need these external references even if we only use contexts
that don't need them.
With this patch, we use a fallback in case no external references are
provided. This way, we only run into issues when we actually call native
callbacks.
R=jgruber@chromium.org, peria@chromium.org
Change-Id: I6af8a77f26c92bd73fdab6112474c62da270597f
Reviewed-on: https://chromium-review.googlesource.com/784831
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49615}
This is a reland of 4d3bc552b5
Original change's description:
> [coverage] add coverage for binary expressions
>
> Adds block-level coverage tracking for binary && and ||
> expressions. Introduces a BinaryOperation source-range
> for tracking the operations themselves and an Expression
> source-range, used for tracking NaryLogical expressions.
>
> This builds on work by jgruber@chromium.org in
> the issue.
>
> TBR=marja@chromium.org
> R=jgruber@chromium.org, rmcilroy@chromium.org
>
> Bug: v8:6660
> Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
> Reviewed-on: https://chromium-review.googlesource.com/754564
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49304}
Bug: v8:6660
Change-Id: I1c8571660d6c501d526886867bd841c49d5c44fd
Reviewed-on: https://chromium-review.googlesource.com/778288
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49613}
A bytecode array can be serialized while concurrent marking is running
and aging the bytecode array, which results in a data race.
This patch ensures that the age byte of a bytecode array is not
accessed during serialization.
Bug: v8:7085
Change-Id: I83e4b67fbef0754bf75015b4d1b9b660a0cd402f
Reviewed-on: https://chromium-review.googlesource.com/785677
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49612}
- Fast path for same type source typed array
- Move previous CPP implementation into a runtime function "TypedArraySet"
- Remove parts covered by the TFJ
- Basic receiver, offset, source checks
- Handling of same type source typed array
Bug: v8:3590
Change-Id: I0f19d961424c30cc8bbcb8648b623e7e6dfa33f4
Reviewed-on: https://chromium-review.googlesource.com/786414
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49608}
The existing access to the signatures is plain wrong. This CL fixes
this.
Note that cross-instance indirect calls are only enabled since a few
days (https://crrev.com/c/778159), which is why this bug was not
detected before.
R=titzer@chromium.org
Bug: chromium:787910
Change-Id: Iaac4d1d85840c921eb8554c5094933ec8d987802
Reviewed-on: https://chromium-review.googlesource.com/787312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49607}
The typer's ToNumber (and thus ToInteger etc.) returns type None when
the input type is BigInt, but we weren't quite ready for that in a few
places.
R=jarin@chromium.org
Bug: v8:7121
Change-Id: Ib12c726338f1ec3dfb9ba5cf54b00cc8d1351a89
Reviewed-on: https://chromium-review.googlesource.com/785130
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49604}
Adds some additional RCS counters to correctly account background
compilation to the background thread.
Also adds a ParseBackgroundProgram as a top-level event for background
parsing since otherwise only pre-parsing was being tracked.
Perf Sheriffs: Note this is likely to increase the Parse-Background
bucket in v8.runtime_stats benchmarks as it now accounts all background
parsing correclty.
BUG=v8:5203
Change-Id: I6ff614b725d85b0bc1901a7bf0e2bac8de1f7cff
Reviewed-on: https://chromium-review.googlesource.com/786237
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49603}
Previously the ScriptCompiler event for compiling streaming sources
was not attaching the runtime trace events to the trace event, which
meant the runtime call stats for these were being lost.
Perf Sheriffs: This is likely to cause perf regressions in v8.runtime_stats
benchmarks because it will start attributing additional events we were
losing before.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0ef9a10951dc976fb0415ae7b5a91c16e1968ae5
Reviewed-on: https://chromium-review.googlesource.com/786551
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49600}
If async stack is longer then max depth, we add externalParent as id,
client can fetch next max depth async stacks by Debugger.getStackTrace.
R=dgozman@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I89d461e672251f03fb239f4f16ae3b0374fce766
Reviewed-on: https://chromium-review.googlesource.com/776242
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49595}
If protocol client needs to make step-into async call:
- pause before async call using any Debugger agent capabilities,
- call Debugger.stepInto with breakOnAsyncCall flag,
- wait for Debugger.paused event, this event will contain
asyncCallStackTrace if async call is scheduled,
- call Debugger.pauseOnAsyncCall on each known target,
- resume execution in current debugger by Debugger.resume.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I40c56278e7b1ceafc3bf81608b8ca6716c2b3168
Reviewed-on: https://chromium-review.googlesource.com/773573
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49594}
- Removes TODO implying that moving a 32 bit immediate to a stack slot
doesn't require the use of kScratchRegister. While movl can be used
to store a 32 bit immediate to memory, it doesn't zero extend leaving
part of the slot uninitialized.
Bug:
Change-Id: I0ebc873b752d508753b624e0b5e262193a568c2b
Reviewed-on: https://chromium-review.googlesource.com/784193
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49592}
Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).
This CL includes following addition to our protocol and v8-inspector.h:
- added Runtime.StackTraceId, this id represents stack trace captured
on debugger with given id,
- protocol client can fetch Runtime.StackTrace by
Runtime.StacKTraceId using Debugger.getStackTrace method,
- externalParent field is added to Debugger.paused event, it may
contain external parent stack trace,
- V8Inspector::storeCurrentStackTrace captures current stack trace
and returns V8StackTraceId for embedder this id can be used as
argument for V8Inspector::externalAsyncTaskStarted and
V8Inspector::externalAsyncTaskFinished method. Any async stack
trace captured between these calls will get passed external stack
trace as external parent. These methods are designed to be called
on different debuggers. If async task is scheduled and started on
one debugger user should continue to use asyncTask* API,
- Debugger.enable methods returns unique debuggerId.
TBR=dgozman@chromium.org,jgruber@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4
Reviewed-on: https://chromium-review.googlesource.com/786274
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49591}
Port a087abb062
Original Commit Message:
There's not really a point in passing the resume_mode as parameter to
the ResumeGenerator builtin. Instead we could as well just store the
mode to the generator object directly.
immediately so we don't need to move it there later.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jbarboza@ca.ibm.com
BUG=
LOG=N
Change-Id: I85d064dad444443fa7ba9d6801e32e4048676ceb
Reviewed-on: https://chromium-review.googlesource.com/783792
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#49588}
- Change VirtualMemory to match OS memory concepts. Rename Release
Free, ReleasePartial to Release.
- Adds comments to make the semantics clear. Right now V8 munmaps
on POSIX, making address space available, while on Windows it is
only possible to decommit.
Bug: chromium:756050
Change-Id: I6ba04d857ab9e1ca1f273e9e766e0825e67210cc
Reviewed-on: https://chromium-review.googlesource.com/783513
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49586}
The main reason why we currently don't see this fail is that block-scopes always appear to have an extension: the scope info object is stored there.
Bug:
Change-Id: I38f0c15387e235eeea9a57c95af0d9eb185dad2a
Reviewed-on: https://chromium-review.googlesource.com/785951
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49585}
This reverts commit 3a41b697cd.
Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250
Original change's description:
> [inspector] introduced stackTraceId and externalAsyncTask API
>
> Sometimes we need to capture stack trace on one debugger and use it
> later as a parent stack on another debugger (e.g. worker.postMessage).
>
> This CL includes following addition to our protocol and v8-inspector.h:
> - added Runtime.StackTraceId, this id represents stack trace captured
> on debugger with given id,
> - protocol client can fetch Runtime.StackTrace by
> Runtime.StacKTraceId using Debugger.getStackTrace method,
> - externalParent field is added to Debugger.paused event, it may
> contain external parent stack trace,
> - V8Inspector::storeCurrentStackTrace captures current stack trace
> and returns V8StackTraceId for embedder this id can be used as
> argument for V8Inspector::externalAsyncTaskStarted and
> V8Inspector::externalAsyncTaskFinished method. Any async stack
> trace captured between these calls will get passed external stack
> trace as external parent. These methods are designed to be called
> on different debuggers. If async task is scheduled and started on
> one debugger user should continue to use asyncTask* API,
> - Debugger.enable methods returns unique debuggerId.
>
> Bug: chromium:778796
> Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
> Reviewed-on: https://chromium-review.googlesource.com/754183
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49582}
TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/786152
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49584}
Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).
This CL includes following addition to our protocol and v8-inspector.h:
- added Runtime.StackTraceId, this id represents stack trace captured
on debugger with given id,
- protocol client can fetch Runtime.StackTrace by
Runtime.StacKTraceId using Debugger.getStackTrace method,
- externalParent field is added to Debugger.paused event, it may
contain external parent stack trace,
- V8Inspector::storeCurrentStackTrace captures current stack trace
and returns V8StackTraceId for embedder this id can be used as
argument for V8Inspector::externalAsyncTaskStarted and
V8Inspector::externalAsyncTaskFinished method. Any async stack
trace captured between these calls will get passed external stack
trace as external parent. These methods are designed to be called
on different debuggers. If async task is scheduled and started on
one debugger user should continue to use asyncTask* API,
- Debugger.enable methods returns unique debuggerId.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
Reviewed-on: https://chromium-review.googlesource.com/754183
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49582}
Arm64 is the only platform where Labels cannot be moved, because the
assembler keeps track of pointers to Labels. On all other platforms,
there is no need to heap-allocate the Labels.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4e98203890a8c426afa8a1db21e31f30bab892fa
Reviewed-on: https://chromium-review.googlesource.com/783210
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49572}
The Label class currently allows to be copied on all platforms except
for arm64, where it can not be copied or moved.
This allows too much though:
Copying a label even on another platform than arm64 might fail if the
label was linked already, because only one of the copies will be bound
later, and the other will fire a DCHECK error in its destructor.
This CL changes the restriction to never allow to copy construct or
assign a Label, but allow move construction and move assignment on all
platforms except arm64.
This will allow to place Labels in containers, as will be done in
Liftoff (except for arm64, where it still needs to be allocated on the
heap).
R=mstarzinger@chromium.org
Bug: v8:6600
Change-Id: Ic1234c2d233317eed6a3d537c13faed2c701fe13
Reviewed-on: https://chromium-review.googlesource.com/783190
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49570}
This reverts commit 9cbb2ed4c3.
Reason for revert: Causes flakiness, see http://shortn/_FEVutYBGP7
Original change's description:
> [heap] Removed keep-one-unused-page concept in sweeper.
>
> This works because we pool regular non-executable pages on a lower level. Executable pages are currently not supported by the pooling mechanism. If this regresses we should fix it.
>
> Change-Id: Ief3484d59f1f1f4bc63f8e718482e4174bedc012
> Reviewed-on: https://chromium-review.googlesource.com/778939
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49536}
TBR=hpayer@chromium.org,mlippautz@chromium.org
Change-Id: If46fe713f1b1440246803e110838a3958f21dcdf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/785090
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49565}
Instead of repeating the condition for using trap handlers everywhere
in the compiler, just use the existing function
{trap_handler::UseTrapHandler()}.
Note that the trap-handler.h was already included transitively, I just
add it to comply to IWYU.
R=eholk@chromium.org
Change-Id: Id61910c7ac5b134b07cb266664e87a2f39a896d4
Reviewed-on: https://chromium-review.googlesource.com/782562
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49558}
Factor out slot count calculation, and expose it so it may later be
consumed when JIT-ing to the WasmCodeManager.
Bug:
Change-Id: I21d673b2e3d7fa4a66ae0ab6303d29cf666d743c
Reviewed-on: https://chromium-review.googlesource.com/782701
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49556}
Without this flag, the load() function is very chatty when
an exception is thrown out of it, independent if the
surrounding code catches it or not.
Bug: v8:6972
Change-Id: I4ca82689c42c729716b83e420d9c7f7e2b5213d1
Reviewed-on: https://chromium-review.googlesource.com/781688
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49555}
This CL introduces those codegen changes necessary for JIT-ing using
the WasmCodeManager.
Bug: v8:6876
Change-Id: I6b463b3e278f5e53f8dfa488f76eeaeb5231dbea
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/782261
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49554}
Old instrumentation was designed to collect promise creation stack and
promise scheduled stack together. In DevTools for last 6 months we
show only creation stack for promises. We got strong support from users
for new model. Now we can drop support for scheduled stacks and
simplify implementation.
New promise instrumentation is straightforward:
- we send kDebugPromiseThen when promise is created by .then call,
- we send kDebugPromiseCatch when promise is created by .catch call,
- we send kDebugWillHandle before chained callback and kDebugDidHandle
after chained callback,
- and we send separate kDebugAsyncFunctionPromiseCreated for internal
promise inside async await function.
Advantages:
- we reduce amount of captured stacks (we do not capture stack for
promise that constructed not by .then or .catch),
- we can consider async task related to .then and .catch as one shot
since chained callback is executed once,
- on V8 side we can implement required instrumentation using only
promise hooks,
Disadvantage:
- see await-promise test, sometimes scheduled stack was useful since we
add catch handler in native code,
Implementation details:
- on kInit promise hook we need to figure out why promise was created.
We analyze builtin functions until first user defined function on
current stack. If there is kAsyncFunctionPromiseCreate function then
we send kDebugAsyncFunctionPromiseCreated event. If there is
kPromiseThen or kPromiseCatch then only if this function is bottom
builtin function we send corresponded event to inspector. We need it
because Promise.all internally calls .then and in this case we have
Promise.all and Promise.then on stack at the same time and we do not
need to report this internally created promise to inspector.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47
Reviewed-on: https://chromium-review.googlesource.com/765208
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49553}
- Eliminates CommitRegion and UncommitRegion methods, replacing them with
calls to SetPermissions.
- Makes a similar change to the API of VirtualMemory.
- This changes system calls from mmap to mprotect on most POSIX platforms.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ib10f8293c9398c6c1e729cd7d686b7c97e6a5d75
Reviewed-on: https://chromium-review.googlesource.com/769679
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49552}
These functions should only be called in case of a parse error, so speed
of calling them should not be a concern.
In local testing, this saves ~16k of binary size on a release mode build.
Bug: v8:7090
Change-Id: I433df81c2a5811ed922885dbab3ce003427f3d1c
Reviewed-on: https://chromium-review.googlesource.com/780693
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49551}
Reduce the deopt table size by reusing the entry address available in a temp
register to compute the entry id. Saves ~200kB.
Bug:
Change-Id: I3a1baf0e4c8cf19a0aa149da2bea623c1349a9ca
Reviewed-on: https://chromium-review.googlesource.com/774890
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49549}
Both can be used to optionally initialize an object, but with
base::Optional it will be stack-allocated.
R=ahaas@chromium.org
Change-Id: I9977e1b2e0532505f8582cc68e27687aaeebd33d
Reviewed-on: https://chromium-review.googlesource.com/781920
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49548}
On x64, we optimize out EmbeddedReferences, unless we explicitly
indicate serialization is enabled. We serialize js-to-wasm wrappers,
which include such references.
Bug: v8:7083
Change-Id: I976da4af74bf7ee3245e1465b8e47f2c042ec3b4
Reviewed-on: https://chromium-review.googlesource.com/780207
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49546}
