This reverts commit 62e168308c.
Reason for revert: it will be relanded after branch
Original change's description:
> Reland x5 [arraybuffer] Rearchitect backing store ownership
>
> This reverts commit 8fdb23873b.
>
> Original change's description:
> > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
> >
> > This is a reland of bc33f5aeba
> >
> > Contributed by titzer@chromium.org
> >
> > Original change's description:
> > > [arraybuffer] Rearchitect backing store ownership
> > >
> > > This CL completely rearchitects the ownership of array buffer backing stores,
> > > consolidating ownership into a {BackingStore} C++ object that is tracked
> > > throughout V8 using unique_ptr and shared_ptr where appropriate.
> > >
> > > Overall, lifetime management is simpler and more explicit. The numerous
> > > ways that array buffers were initialized have been streamlined to one
> > > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > > and the construction and destruction of the BackingStore object itself
> > > handles the underlying page or embedder-allocated memory.
> > >
> > > The embedder API remains unchanged for now. We use the
> > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > > keep the backing store alive properly, even in the case of aliases
> > > from live heap objects. Thus the embedder has a lower chance of making
> > > a mistake. Long-term, we should move the embedder to a model where they
> > > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > TBR=yangguo@chromium.org
> >
> > BUG=v8:9380,v8:9221,chromium:986318
> >
> > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63041}
>
> TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
>
> Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63461}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: Id8f67a68ab398032eb2975b1b24ee125394d9c4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776095
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63471}
This reverts commit 8fdb23873b.
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63461}
This reverts commit 5611f70b3d.
Reason for revert: flaky tests: v8:9588, v8:9587
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9380, v8:9221, chromium:986318
Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63081}
This is a reland of bc33f5aeba
Contributed by titzer@chromium.org
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
TBR=yangguo@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63041}
This reverts commit df8e617772.
Reason for revert: Multiple flakes in apparently related areas:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0
Original change's description:
> "Reland x3 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221,chromium:986318
> TBR=ulan@chromium.org
>
> Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63007}
TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org
Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221, chromium:986318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63011}
This is a reland of 517ab73fd7
Updates since original: now compressed pointers passed to the function
GetObjectProperties are required to be sign-extended. Previously, the
function allowed zero-extended values, but that led to ambiguity on
pointers like 0x88044919: is it compressed or is the heap range actually
centered on 0x100000000?
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
Bug: v8:9376
Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63008}
This is a reland of bc33f5aeba
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
TBR=ulan@chromium.org
Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63007}
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend
doesn't emit unwinding info and also because it doesn't emit ABI compliant
stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and
documented below:
https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0
This problem can be fixed similarly for Windows ARM64 by observing that V8
frames usually all have the same prolog which maintains a chain via frame
pointer (fp or x29 register).
stp fp, lr, [sp, ...]
One exception is JSEntry which stops fp pointer chain and needs to be handled
specially.
So it is possible to define XDATA with UNWIND_CODE which specify how Windows
should walk through V8 dynamic frames. The same as X64, since V8 Code objects
are all allocated in the same code-range for an Isolate, it is possible to
register at most 2 XDATA and a group of PDATA entries to cover stack walking
for all the code generated inside that code-range. This is more than 1
PDATA/XDATA because according to the Windows ARM64 exeption handling document,
1 PDATA can cover less than 1MB code range (see below doc).
https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling
This PR implements stackwalk for Windows ARM64 to be on par with X64, including
embedded builtins, jitted code and wasm jitted code, but not including register
handler for handling exception only, because there is no backward compatibility
to maintain for Windows ARM64 which was released since 1709 windows build.
Bug: chromium:893460
Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63002}
This reverts commit 517ab73fd7.
Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62899}
This change begins to implement the functionality described in
https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
for investigating V8 state in crash dumps.
This change adds a new library, v8_debug_helper, for providing platform-
agnostic assistance with postmortem debugging. This library can be used
by extensions built for debuggers such as WinDbg or lldb. Its public API
is described by debug-helper.h; currently the only method it exposes is
GetObjectProperties, but we'd like to add more functionality over time.
The API surface is restricted to plain C-style structs and pointers, so
that it's easy to link from a debugger extension built with a different
toolchain.
This change also adds a new cctest file to exercise some basic
interaction with the new library.
The API function GetObjectProperties takes an object pointer (which
could be compressed, or weak, or a SMI), and returns a string
description of the object and a list of properties the object contains.
For now, the list of properties is entirely based on Torque object
definitions, but we expect to add custom properties in future updates so
that it can be easier to make sense of complex data structures such as
dictionaries.
GetObjectProperties does several things that are intended to generate
somewhat useful results even in cases where memory may be corrupt or
unavailable:
- The caller may optionally provide a type string which will be used if
the memory for the object's Map is inaccessible.
- All object pointers are compared against the list of known objects
generated by mkgrokdump. The caller may optionally provide the
pointers for the first pages of various heap spaces, to avoid spurious
matches. If those pointers are not provided, then any matches are
prefixed with "maybe" in the resulting description string, such as
"maybe UndefinedValue (0x4288000341 <Oddball>)".
Bug: v8:9376
Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62882}
This reverts commit 306cf40344.
Reason for revert: performance regressions / too near branch point
TBR=mslekova@chromium.org
BUG=v8:9380
Change-Id: If77630b73eafbf1190c823199fe2a34361da303f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714867
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62867}
This is a reland of bc33f5aeba
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
Bug: v8:9380, v8:9221
Change-Id: I9a2525753ae2424108d074fa81df5f25d945c824
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62847}
This adds a simple test calling:
generate-bytecode-expectations --check-baseline
It's added on one CQ and one CI builder. The infra side specifying the
command line landed here:
https://crrev.com/c/1709454
For the command to succeed on swarming we instruct the isolate server
to archive the executable alongside with all the *.golden files needed
for the --check-baseline command.
Bug: v8:9520
Change-Id: I358ca7a7142c0fdaa7f6960515e524729a481394
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709424
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62844}
This reverts commit bc33f5aeba.
Reason for revert: Still failing (OOM on win32): https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22210
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Iea755df9aaa1e95d284135bd0a6681b1340b6832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708487
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62811}
This is a reland of 31cd5d83d3
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
Bug: v8:9380, v8:9221
Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62809}
This reverts commit 31cd5d83d3.
Reason for revert: It breaks my heart to revert this, but it fails differently on several bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/26671.
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Ib35788ba8c31192d90cbc72df3dbc41030f109de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691034
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62578}
This CL completely rearchitects the ownership of array buffer backing stores,
consolidating ownership into a {BackingStore} C++ object that is tracked
throughout V8 using unique_ptr and shared_ptr where appropriate.
Overall, lifetime management is simpler and more explicit. The numerous
ways that array buffers were initialized have been streamlined to one
Attach() method on JSArrayBuffer. The array buffer tracker in the
GC implementation now manages std::shared_ptr<BackingStore> pointers,
and the construction and destruction of the BackingStore object itself
handles the underlying page or embedder-allocated memory.
The embedder API remains unchanged for now. We use the
v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
keep the backing store alive properly, even in the case of aliases
from live heap objects. Thus the embedder has a lower chance of making
a mistake. Long-term, we should move the embedder to a model where they
manage backing stores using shared_ptr to an opaque backing store object.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221
Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62572}
The client API provides a much simpler interface so that we don't have
to deal with producers, consumers etc. directly. This CL removes all the
code that dealt with the more complex API used previously.
The architecture used here requires that the embedder call into
Tracing::Initialize() to set up the tracing backend. The tracing
controller then connects to this backend when calling
DataSource::Register() and Tracing::NewTrace(). This will ultimately
avoid the need for a virtual call (or two) for every trace event that
need to be dispatched over the API - chrome can provide a backend
and V8 will connect to it opaquely with the same code when tracing is
enabled.
Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I6b74fbb49ffcc89638caeb59ed3d5cc81238f3e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634916
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62568}
Introduce a helper class for regular expression parsing
and use it to improve load poison tests readability and
maintainability.
Extend load poisoning tests for arm64 platform (e.g.
for both regular and compressed references cases).
Change-Id: Ie62dfd14a60186feaa5f48e1a6122d77766472af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645913
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62493}
Adds basic support for CompressedHeapConstants to Arm64 by moving to a ldr_w
instruction and passing COMPRESSED_EMBEDDED_OBJECT as the RelocInfo. However,
we still haven't made the COMPRESSED_EMBEDDED_OBJECT be actually compressed
in the code-stream (they still take up a full 64-bits). Support for this will
be added next.
Adding a test on macro assembler that checks that the
RelocInfo::COMPRESSED_EMBEDDED_OBJECT is flowing through.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977, v8:7703, v8:9298
Change-Id: Ibc64cdfdd85d5cdfa060ed6227b10bb47eae3a8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635692
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62306}
Extract tests related to array buffers and typed arrays to their own
.cc files.
R=mstarzinger@chromium.org
Change-Id: Ic80205d02b62db1565670ecf2bb4c0dbe52fab49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662301
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62219}
These were only used by test-log/EquivalenceOfLoggingAndTraversal,
which itself has been marked as failing since 2013. This CL removes
the test itself as well as the TEST natives kind.
Bug: v8:7624,v8:2857
Change-Id: Iedf2b1c94e31ccd1ea885d72bf1fac5d33defa90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643467
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61984}
Add a new abstract class TraceEventListener which is just an interface
for consuming trace events. This separates the V8-specific stuff that
an actual perfetto consumer needs to do e.g. handling the has_more flag
and signalling back to the controller with a semaphore.
This is a change from the previous plan of making the PerfettoConsumer
class sub-classable to implement custom consumption of trace events.
This will be difficult when the consumer is created outside of the
PerfettoTracingController as we can't hook up the
consumer_finished_semaphore_ that belongs to the controller.
Now the PerfettoTracingController is responsible for the Consumer life-
cycle and hides it entirely from callers. We add the
AddTraceEventListener() method to allow callers to register a listener
either for testing or a JSON listener for real tracing.
This lets us write tests that can store all the trace events in memory
without first converting them to JSON, letting us write test more
easily. There's an example test add to test-tracing - more tests using
this style will follow.
Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I2d2b0f408b1c7bed954144163e1968f40d772c1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628789
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61854}
Mechanical change with the exception of one threaded test, that had
to be turned into a normal test to turn green.
R=jgruber@chromium.org
Bug: v8:9183
Change-Id: Ie7c3350415e21f93e8161a3c844cbe165ecd7da5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612899
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61520}
Both MSVC and Clang require a mainCRTStartup symbol for the cctest
executable to compile. All objects from the cctest_sources source
set are bundled into a library which does not contain this symbol.
Bug: v8:7854
Change-Id: I88cd26209114daa84574e3b20046613b1560fa98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1357039
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61206}
Code relocation info is now always allocated in old-space. Before relocation
info allocated for placeholders and builtins (which get replaced with
trampolines in nosnap builds) would become unreachable. Since read-only space
is not GCed and ReadOnlyHeapIterator doesn't check for reachability,
ValidateSnapshot would fail finding unreachable objects returned by
ReadOnlyHeapIterator.
Because trampoline relocation info gets replaced with canonical one, this only
affects no-embdded-builtins nosnap builds, which don't get much benefit from
read-only relocation info anyway.
A new check has been added to the read-only deserializer to verify that every
read-only object is reachable at mksnapshot-time.
The CombinedHeapIterator iteration order was changed to iterate over
read-only space first, because that's how HeapIterator worked.
This is a reland of 3d1d8eae77
Original change's description:
> [heap] Skip ro-space from heap iterators, add CombinedHeapIterator.
>
> Read-only space sharing requires an iterator independent of heap. This
> also enables future removal of read-only space from heap.
>
> Bug: v8:7464
> Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795
> Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60819}
Bug: v8:7464
Change-Id: I49ae070955b77956962334a84f762ab29052d5ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Cr-Commit-Position: refs/heads/master@{#61185}
Read-only space sharing requires an iterator independent of heap. This
also enables future removal of read-only space from heap.
Bug: v8:7464
Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60819}
Remove unused includes and add includes that were indirect.
Remove UnboundQueue which was not used anywhere.
Change-Id: If47faac45fc9c16a27453ecabed927ea00df3045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557136
Auto-Submit: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60672}
This is a reland of 3cda21de77
Original change's description:
> V8 x64 backend doesn't emit ABI compliant stack frames
>
> On 64 bit Windows, the OS stack walking does not work because the V8 x64
> backend doesn't emit unwinding info and also because it doesn't emit ABI
> compliant stack frames. See
> https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
> for more details.
>
> This problem can be fixed by observing that V8 frames usually all have the same
> prolog and epilog:
>
> push rbp,
> mov rbp, rsp
> ...
> pop rbp
> ret N
>
> and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
> should walk through V8 frames. Furthermore, since V8 Code objects are all
> allocated in the same code-range for an Isolate, it is possible to register a
> single PDATA/XDATA entry to cover stack walking for all the code generated
> inside that code-range.
>
> This PR contains changes required to enable stack walking on Win64:
>
> EmbeddedFileWriter now adds assembler directives to the builtins
> snapshot source file (embedded.cc) to emit additional entries in the .pdata and
> in the .xdata section of the V8 executable. This takes care of stack walking
> for embedded builtins. (The case of non-embedded builtins is not supported).
> The x64 Assembler has been modified to collect the information required to emit
> this unwind info for builtins.
>
> Stack walking for jitted code is handled is Isolate.cpp, by registering
> dynamically PDATA/XDATA for the whole code-range address space every time a new
> Isolate is initialized, and by unregistering them when the Isolate is
> destroyed.
>
> Stack walking for WASM jitted code is handled is the same way in
> wasm::NativeModule (wasm/wasm-code-manager.cpp).
>
> It is important to note that Crashpad and Breakpad are already registering
> PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
> builtins). Since it is not possible to register multiple PDATA entries for the
> same address range, a new function is added to the V8 API:
> SetUnhandledExceptionCallback() can be used by an embedder to register its own
> unhandled exception handler for exceptions that arise in v8-generated code.
> V8 embedders should be modified accordingly (code for this is in a separate PR
> in the Chromium repository:
> https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
>
> All these changes are experimental, behind:
>
> the 'v8_win64_unwinding_info' build flag, and
> the '--win64-unwinding-info' runtime flag.
>
> Bug: v8:3598
> Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#60330}
Bug: v8:3598
Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60581}
This reverts commit 3cda21de77.
Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400)
Original change's description:
> V8 x64 backend doesn't emit ABI compliant stack frames
>
> On 64 bit Windows, the OS stack walking does not work because the V8 x64
> backend doesn't emit unwinding info and also because it doesn't emit ABI
> compliant stack frames. See
> https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
> for more details.
>
> This problem can be fixed by observing that V8 frames usually all have the same
> prolog and epilog:
>
> push rbp,
> mov rbp, rsp
> ...
> pop rbp
> ret N
>
> and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
> should walk through V8 frames. Furthermore, since V8 Code objects are all
> allocated in the same code-range for an Isolate, it is possible to register a
> single PDATA/XDATA entry to cover stack walking for all the code generated
> inside that code-range.
>
> This PR contains changes required to enable stack walking on Win64:
>
> EmbeddedFileWriter now adds assembler directives to the builtins
> snapshot source file (embedded.cc) to emit additional entries in the .pdata and
> in the .xdata section of the V8 executable. This takes care of stack walking
> for embedded builtins. (The case of non-embedded builtins is not supported).
> The x64 Assembler has been modified to collect the information required to emit
> this unwind info for builtins.
>
> Stack walking for jitted code is handled is Isolate.cpp, by registering
> dynamically PDATA/XDATA for the whole code-range address space every time a new
> Isolate is initialized, and by unregistering them when the Isolate is
> destroyed.
>
> Stack walking for WASM jitted code is handled is the same way in
> wasm::NativeModule (wasm/wasm-code-manager.cpp).
>
> It is important to note that Crashpad and Breakpad are already registering
> PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
> builtins). Since it is not possible to register multiple PDATA entries for the
> same address range, a new function is added to the V8 API:
> SetUnhandledExceptionCallback() can be used by an embedder to register its own
> unhandled exception handler for exceptions that arise in v8-generated code.
> V8 embedders should be modified accordingly (code for this is in a separate PR
> in the Chromium repository:
> https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
>
> All these changes are experimental, behind:
>
> the 'v8_win64_unwinding_info' build flag, and
> the '--win64-unwinding-info' runtime flag.
>
> Bug: v8:3598
> Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#60330}
TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com
Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:3598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60372}
On 64 bit Windows, the OS stack walking does not work because the V8 x64
backend doesn't emit unwinding info and also because it doesn't emit ABI
compliant stack frames. See
https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
for more details.
This problem can be fixed by observing that V8 frames usually all have the same
prolog and epilog:
push rbp,
mov rbp, rsp
...
pop rbp
ret N
and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
should walk through V8 frames. Furthermore, since V8 Code objects are all
allocated in the same code-range for an Isolate, it is possible to register a
single PDATA/XDATA entry to cover stack walking for all the code generated
inside that code-range.
This PR contains changes required to enable stack walking on Win64:
EmbeddedFileWriter now adds assembler directives to the builtins
snapshot source file (embedded.cc) to emit additional entries in the .pdata and
in the .xdata section of the V8 executable. This takes care of stack walking
for embedded builtins. (The case of non-embedded builtins is not supported).
The x64 Assembler has been modified to collect the information required to emit
this unwind info for builtins.
Stack walking for jitted code is handled is Isolate.cpp, by registering
dynamically PDATA/XDATA for the whole code-range address space every time a new
Isolate is initialized, and by unregistering them when the Isolate is
destroyed.
Stack walking for WASM jitted code is handled is the same way in
wasm::NativeModule (wasm/wasm-code-manager.cpp).
It is important to note that Crashpad and Breakpad are already registering
PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
builtins). Since it is not possible to register multiple PDATA entries for the
same address range, a new function is added to the V8 API:
SetUnhandledExceptionCallback() can be used by an embedder to register its own
unhandled exception handler for exceptions that arise in v8-generated code.
V8 embedders should be modified accordingly (code for this is in a separate PR
in the Chromium repository:
https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
All these changes are experimental, behind:
the 'v8_win64_unwinding_info' build flag, and
the '--win64-unwinding-info' runtime flag.
Bug: v8:3598
Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60330}
This CL only provides the implementation of memory.{init,copy,fill} and
data.drop.
Bug: v8:8965
Change-Id: I439f2520bfee8f147e4b0d1d31f954aaad2e14ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510575
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60253}
Moving to gtest allows negative test cases as the current parser
implementation exits the process on a parser error. The CL adds two
small negative tests. The idea is less to get full coverage, but to
have a place for regression tests.
Drive-by-change: Lexer errors need a valid source position scope and
Json parser needs a valid SourceId, otherwise we read OOB when the
error message is generated.
R=petermarshall@chromium.org
Bug: v8:8880
Change-Id: I56c4b9e0a29c8333b2e5e44f8116e5178552d2f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1498472
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60014}
Design Doc: https://goo.gl/9G9d9k
The initial prototype consists of a few parts:
The VS Code extension is now built using TypeScript. The build artifact
is checked-in along side the extension. The extension now starts up
the language server when it is activated. The path to the LS
executable is configurable via VS Code settings.
The language server is a separate executable. It adds a light-weight
object model on top of a Json Parser for reading/writing LSP requests
and responses. The current server is very much bare-bones featurewise:
- Tell the client that the server can handle "goto definition"
- Recompile when Torque files change
- Goto definition support for Macros/Builtins, local variables
and arguments.
R=mathias@chromium.org, mvstanton@chromium.org, tebbi@chromium.org
Bug: v8:8880
Change-Id: Ie9b433e64ee63e9aa757b6bf71e5d52beb15b079
Reviewed-on: https://chromium-review.googlesource.com/c/1494354
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59960}
This CL contains a basic Json parser used to read and write the
Json-RPC messages of the language server protocol.
This CL is part of the initial language server implementation but
submitted separately for easier review.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: Icea040975e1ed1d587954c3342d8d876e01c26b8
Reviewed-on: https://chromium-review.googlesource.com/c/1479956
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59848}
This is a step towards making gn check pass on v8 without third_party
Change-Id: I6a256d65159695e2ba2a5d44c0437cac9b28aa3a
Bug: v8:8834, v8:8855
Reviewed-on: https://chromium-review.googlesource.com/c/1475460
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59641}
This adds preliminary support for exception handling to the interpreter.
Note that due to missing reference type support, the exception object is
not yet correctly put onto the operand stack. Also exceptions raised by
call operations are not handled properly yet.
R=clemensh@chromium.org
TEST=cctest/test-run-wasm-exceptions
BUG=v8:8091
Change-Id: Ie68ca9448c7beafe8967dff5bb5de6642edcc9e4
Reviewed-on: https://chromium-review.googlesource.com/c/1436017
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59131}
V8 is almost completely JS-free. There's no need to ship the minifier
any more.
Bug: v8:7624,v8:5505,v8:4240,v8:4235,v8:4188,v8:1557
Change-Id: Iee15bf68c66bac27a67fe70e10b1edd4dcef89d1
Reviewed-on: https://chromium-review.googlesource.com/c/1386146
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58392}
This is a reland of f849396c3a
Original change's description:
> [nojit] Remove code stubs
>
> All stubs have been migrated to builtins. This CL removes most related
> code.
>
> Bug: v8:7777, v8:5784
> Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad
> Reviewed-on: https://chromium-review.googlesource.com/c/1365284
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58093}
Tbr: mstarzinger@chromium.org,yangguo@chromium.org,jkummerow@chromium.org,bmeurer@chromium.org
Bug: v8:7777, v8:5784
Change-Id: I005ee2a820d49a75a90481d262a310e4ccfd1391
Reviewed-on: https://chromium-review.googlesource.com/c/1367746
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58101}
All stubs have been migrated to builtins. This CL removes most related
code.
Bug: v8:7777, v8:5784
Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad
Reviewed-on: https://chromium-review.googlesource.com/c/1365284
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58093}
If the size of a large code object is larger than
kMaxRegularHeapObjectSize, then it should be allocated in the large code
space. Currently if the size is > kMaxRegularHeapObjectSize but <
512000, then it can still be allocated in the normal code space.
Change-Id: I72dbd38803c3d5d414bae85e9e0b15482e50e1c2
Reviewed-on: https://chromium-review.googlesource.com/c/1363137
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58046}
This adds a new target :generated_cc_files which generates all
generated .cc files and is quick to build (~5sec on my machine).
TBR=yangguo@chromium.org
Change-Id: I51485635671b55302b06f1ea300e86ef1745931e
Bug: v8:8526
Reviewed-on: https://chromium-review.googlesource.com/c/1354881
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57941}
This API allows the embedder to provide a stack and PC, FP and
SP registers. V8 will then attempt to unwind the stack to the C++ frame
that called into JS. This API is signal-safe, meaning it does not call
any signal-unsafe OS functions or read/write any V8 state.
Bug: v8:8116
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I7e3e73753b711737020b6a5f11946096658afa6f
Reviewed-on: https://chromium-review.googlesource.com/c/1186724
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57749}
This test cases ensures that it is possible to maintain a coherent
instruction cache by using {Assembler::FlushICache} in any order with
respect to changing page permissions via {SetPermissions}.
R=ulan@chromium.org
TEST=cctest/test-icache
BUG=v8:6792
Change-Id: I1778bbbe94b40856d9732a9990a931b5a956a439
Reviewed-on: https://chromium-review.googlesource.com/c/1344113
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57651}
This is a reland of 0b13f0f517
Original change's description:
> [snapshot] Emit the embedded blob as assembly instead of inline assembly
>
> The motivation behind this is that MSVC doesn't support inline assembly
> on x64. Emitting the embedded blob as a plain assembly file will give us
> MSVC support (and possibly faster compilation times as a side-effect).
>
> Bug: v8:6666,v8:8349
> Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
> Reviewed-on: https://chromium-review.googlesource.com/c/1329205
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57524}
Tbr: yangguo@chromium.org,mvstanton@chromium.org
Bug: v8:6666, v8:8349
Change-Id: Ib35696b60a9cd01bc2edf459c8e8d84716e3438d
Reviewed-on: https://chromium-review.googlesource.com/c/1337733
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57546}
This reverts commit 0b13f0f517.
Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20debug/17373
Original change's description:
> [snapshot] Emit the embedded blob as assembly instead of inline assembly
>
> The motivation behind this is that MSVC doesn't support inline assembly
> on x64. Emitting the embedded blob as a plain assembly file will give us
> MSVC support (and possibly faster compilation times as a side-effect).
>
> Bug: v8:6666,v8:8349
> Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
> Reviewed-on: https://chromium-review.googlesource.com/c/1329205
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57524}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org
Change-Id: I35f7763f86b4de01e74827a95706b969b43af55e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:8349
Reviewed-on: https://chromium-review.googlesource.com/c/1337574
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57528}
The motivation behind this is that MSVC doesn't support inline assembly
on x64. Emitting the embedded blob as a plain assembly file will give us
MSVC support (and possibly faster compilation times as a side-effect).
Bug: v8:6666,v8:8349
Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2
Reviewed-on: https://chromium-review.googlesource.com/c/1329205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57524}
This is a reland of fcbb023b0e
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe
TBR=mlippautz@chromium.org
Bug: chromium:893460
Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52
Reviewed-on: https://chromium-review.googlesource.com/c/1297300
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56965}
This reverts commit fcbb023b0e.
Reason for revert: blocks roll https://chromium-review.googlesource.com/c/chromium/src/+/1296315
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
TBR=bbudge@chromium.org,ulan@chromium.org,machenbach@chromium.org,hpayer@chromium.org,brucedawson@chromium.org,mlippautz@chromium.org,ahaas@chromium.org,bmeurer@chromium.org,Tom.Tan@microsoft.com
Change-Id: I0b804af6dfca9409a655194fa6e5407f209be2dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:893460
Reviewed-on: https://chromium-review.googlesource.com/c/1296460
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56912}
This change added Windows ARM64 ABI support, major things are:
1. Excluding x18 register from any usage because it is reserved as
platform register. Preserve alignment after the change.
2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
still LLP64.
3. Stack guard page probe for large allocation on stack.
Reference:
Windows ARM64 ABI:
https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
Bug: chromium:893460
Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
Reviewed-on: https://chromium-review.googlesource.com/c/1285129
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56881}
Headers are not included in jumbo builds so excluding
them has no meaning and will cause problems in a future
version of jumbo. This patch removes two such headers.
Change-Id: I19eadf989ff69a4e1116ba265ecb37236d67efd4
Reviewed-on: https://chromium-review.googlesource.com/c/1290793
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Daniel Bratell <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#56809}
These test mainly the data structures of JSWeakFactory / JSWeakCell.
BUG=v8:8179
Change-Id: I20ffd07c18bbb2e21c69d11aa65d1e245203cc82
Reviewed-on: https://chromium-review.googlesource.com/c/1267939
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56569}
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}
Previously the builtins table had a value for every single
OperandScale/Bytecode combination regardless of whether it was valid.
This change makes it so that only valid bytecode handlers are stored in
the builtins table. This prevents placeholders being serialized into the
snapshot (and embedded into the binary) saving 9KB in
CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66
entries in the builtins table.
To do this, it generates a new header file bytecodes-builtins-list.h
which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros.
Since list macros cannot be used to conditionally generate elements in
the C-preprocessor, this is done by generator executable, compiled from
interpreter/generate-flat-headers.cc.
Additionally the generator creates the flat bytecode list so that it is
transposed from the previous result, i.e. the results are grouped by
bytecode and then operand scale rather than operand scale then bytecode.
This should give better locality for commonly used bytecodes and may
allow less commonly used ExtraWide bytecodes to never be mapped into
memory at all.
The cost to storing the handlers densely is that looking up a handler
now requires a binary search through the builtins table, but this should
only happen during debugging. It is also fixable at least for non-wide
handlers and could be improved for wide ones if the need arises.
Bug: v8:8068
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667
Reviewed-on: https://chromium-review.googlesource.com/1209304
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55757}
Adds support for zone allocated (off-heap) ConsumedPreParsingScopeData to
enable worker-thread access to PreParsingScopeData during parallel IIFE
compile tasks.
In order to avoid code-duplication, a templated
BaseConsumedPreParsingScopeData is added which implements the logic for
decoding the bytestream into scope data. Two implementations of this
base class are instantiated for each of the underlying serialized scope date:
- ZoneConsumedPreParsedScopeData for exposing ZonePreParsedScopeData
- OnHeapConsumedPreParsedScopeData for exposing on-heap PreParsedScopeData
The interface for each of these classes is the ConsumedPreParsingScopeData,
which exposes the methods required by the parser to deserialize the required
data.
As a side-cleanup, moved Ucs2CharLength and Utf8LengthHelper implementations
to cc file so that we don't get a linker error if one of them are unused by
the cc file including the header.
BUG=v8:8041
Change-Id: Id502312d32fe4a9ddb6f5d2d9d3e3a9d30b9b27d
Reviewed-on: https://chromium-review.googlesource.com/1199462
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55711}
This CL changes the call-site of SmiLexicographicCompare to a fast
c call instead of a runtime call. The runtime function is not deleted
as it is still used in InnerArraySort.
The test is also moved from mjsunit to cctest, to make removal of the
runtime function easier in the future.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: Ie961eeb094c13018e9ec28b68f7c444d7f889036
Reviewed-on: https://chromium-review.googlesource.com/1201587
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55642}
When v8_enable_embedded_bytecode_handlers is true, initialize the
bytecode dispatch table from the builtins table. Also stops creating
the handlers more than once as the SetupInterpreter will now always do
nothing even when not starting from a snapshot.
In the short term, with the flag enabled all the bytecode handlers are
eagerly deserialized.
Finally, the bytecode handlers are marked as non-isolate independent to
prevent them being embedded in the binary until they can be converted.
Bug: v8:8068
Change-Id: I9e5ef7f1dce1b2d11c7aa26526f06b53f8939697
Reviewed-on: https://chromium-review.googlesource.com/1188477
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55581}
- Implement all the I64Atomic operations on ARM
- Change assembler methods to use Registers instead of memory operands
- Move atomics64 test up be tested on all archs, disable tests on MIPS
BUG:v8:6532
Change-Id: I91bd42fa819f194be15c719266c36230f9c65db8
Reviewed-on: https://chromium-review.googlesource.com/1180211
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55416}
This adds initial support for concurrently patching jump table slots. It
is needed once different Isolates share code (for the --wasm-shared-code
feature). We need to ensure that instructions holding the target address
within a jump table slot do not cross cache-line boundaries. To do this,
the jump table has been split into consecutive pages.
Note that this also adds a stress test for multiple threads hammering at
a single slot concurrently. The test is currently limited to the ia32
and the x64 architecture, but will be extended to cover others. The test
reliably triggers tearing of the target address on almost every run of
the test and hence serves to prevent regressions.
R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018
Change-Id: Ife56bbb61ffcae5d8906ca7b8c604b195603707c
Reviewed-on: https://chromium-review.googlesource.com/1163664
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54942}
This CL depends on Reland^2 "Avoiding re-externalization of strings"
(Idb1b6d1b29499f66bf8cd704977c40b027f99dbd)..
Previously landed as Ied341ec6268000343d2a577b22f2a483460b01f5 and
I3fe2b294f6e038d77787cf0870d244ba7cc20550
Previously reviewed at https://chromium-review.googlesource.com/1121736 and
https://chromium-review.googlesource.com/1118164
Bug: chromium:845409
Change-Id: Ied50bbcaa22a90ecaf15dca19dbc9aaec1737223
Reviewed-on: https://chromium-review.googlesource.com/1147227
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Rodrigo Bruno <rfbpb@google.com>
Cr-Commit-Position: refs/heads/master@{#54712}
This is a reland of a462a7854a
Original change's description:
> [turboassembler] Introduce hard-abort mode
>
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
>
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
>
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
>
> R=mstarzinger@chromium.org
>
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}
Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
This reverts commit a462a7854a.
Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726
Original change's description:
> [turboassembler] Introduce hard-abort mode
>
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
>
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
>
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
>
> R=mstarzinger@chromium.org
>
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.
This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.
Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.
R=mstarzinger@chromium.org
Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
This is a first set of test cases for sharing an {WasmEngine} and the
contained {WasmCode} between multiple Isolates. Currently this can only
be done using internal API methods on the Isolate, an external API that
is usable by embedders does not exist yet.
R=clemensh@chromium.org
TEST=cctest/test-wasm-shared-engine
BUG=v8:7424
Change-Id: I35541a76b5aceec4519e3a46e6a9ef4d01cad22b
Reviewed-on: https://chromium-review.googlesource.com/1126382
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54248}
Now that ReadOnlyRoots is used everywhere to access the read-only roots,
this makes the Heap accessors for such roots private.
It also adds tests that the roots reachable from ReadOnlyRoots are all
in RO_SPACE as well as tests that the roots still publicly accessible
from Heap are not in RO_SPACE. There's a white list in the file for
the few roots where the root pointer itself can change. (For instance
materialized_objects points to empty_fixed_array to start with before
before later pointing to a mutable array).
Also fixes up new use of heap->empty_fixed_array() in elements.cc added
since I cleaned it up.
Bug: v8:7786
Change-Id: I9ac7985c9f85910b5b22d2f9f559dfd04d43ed44
Reviewed-on: https://chromium-review.googlesource.com/1126252
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54240}
This is a reland of c2f1090db8, fixing jumbo builds.
Original change's description:
> [wasm] Move serialization tests to own file
>
> Move out all serialization related tests to
> {test-wasm-serialization.cc}, to reduce the size of
> {test-run-wasm-module.cc}.
>
> R=titzer@chromium.org
>
> Bug: v8:7754
> Change-Id: I0b2133baf69e2557df27d1733cc267d1d4cf7452
> Reviewed-on: https://chromium-review.googlesource.com/1107980
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53909}
TBR=titzer@chromium.org
Bug: v8:7754
Change-Id: Ic0bb02b1b782676c6100daa2d588adce8b54c388
Reviewed-on: https://chromium-review.googlesource.com/1109838
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53919}
Move out all serialization related tests to
{test-wasm-serialization.cc}, to reduce the size of
{test-run-wasm-module.cc}.
R=titzer@chromium.org
Bug: v8:7754
Change-Id: I0b2133baf69e2557df27d1733cc267d1d4cf7452
Reviewed-on: https://chromium-review.googlesource.com/1107980
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53909}
DevTools may process another protocol message during API interrupt this
API may lead to createInjectedScript reentrance and will fail.
Let's postpone interrupts.
Bug: chromium:846099
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: Ia06e034a6287087e4674559d8911d2f4a0b1b459
Reviewed-on: https://chromium-review.googlesource.com/1086372
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53531}
After [1], a manual dependency on exe_and_shlib_deps is no longer necessary
since it's automatically added. This CL removes all remaining manual references
to exe_and_shlib_deps.
[1] d7ed1f0a9c
BUG=chromium:845700
R=machenbach
Change-Id: I17da573b7b6509a690caf8be6ae6afc180105f07
Reviewed-on: https://chromium-review.googlesource.com/1082913
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53500}
In the process, add a few simple tests for "constexpr" expressions, which
identified a few bugs that are also fixed in this CL.
Change-Id: I97486c781572642d2b574b92133b1f9cda3db592
Reviewed-on: https://chromium-review.googlesource.com/1055493
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53135}
The memory metric samples memory usage immediately after forcing GC via
LowMemoryNotification. This makes the metric sensitive to the unmapper
tasks timing.
This patch forces eager unmapping in CollectAllAvailableGarbage.
It also forces eager unmapping of non-regular chunks at the beginning
of Mark-Compact to avoid accumulation of non-regular chunks.
Bug: chromium:833291, chromium:826384
Change-Id: Iddf02cd4ab8613385d033899d29525fe6ee47fdd
Reviewed-on: https://chromium-review.googlesource.com/1017102
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52696}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
R=mstarzinger@chromium.org
Change-Id: Ia35a3ce91a8f6135767fa764e185cde8bbc889f4
Reviewed-on: https://chromium-review.googlesource.com/997932
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52436}
This reverts commit 57bf0bfefb.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Merge the WasmContext into WasmInstanceObject
>
> This change makes lifetime management of WasmCode much simpler.
> By using the WasmInstanceObject as the context for WASM code execution,
> including the pointer to the memory base and indirect function tables,
> this keeps the instance alive when WASM code is on the stack, since
> the instance object is passed as a parameter and spilled onto the stack.
> This is in preparation of sharing the code between instances and
> isolates.
>
> Bug: v8:7424
>
> Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
> Reviewed-on: https://chromium-review.googlesource.com/958520
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52361}
TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7424
Reviewed-on: https://chromium-review.googlesource.com/995418
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52364}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
Reviewed-on: https://chromium-review.googlesource.com/958520
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52361}
Remove IsBlockTerminator and introduce InstructionScheduler::AddTerminator in
order to handle block terminator instructions.
Instead of the kBlockTerminator flags, we now rely on Instruction::IsTrap(),
Instruction::IsDeoptimizeCall() and explicitly denoting block terminators
when adding them with InstructionScheduler::AddTerminator().
IsBlockTerminator incorrectly included deopts when they were not at the end of
a block, which meant that an instruction with side effects could have been
reordered with respect to a deopt as the deopt was not identified correctly.
Since the snapshot does not contain deopts, this is not causing any problems
at the moment (the scheduler is only enabled on the snapshot).
Change-Id: I1c2dad748a9398a3355630d9a542f4ac89afaa42
Reviewed-on: https://chromium-review.googlesource.com/960501
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#52019}
Implement in-place weak reference handling in GC.
Turn FeedbackVector::optimized_code_or_smi into an in-place weak reference (this
is the only in-place weak reference at this point).
(See bug for design doc.)
BUG=v8:7308
TBR=yangguo@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I16d65dc768f10ed431252e23a0df07bee9063534
Reviewed-on: https://chromium-review.googlesource.com/948493
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51731}
