Skip to content

V
V8
Switch branch/tag
  1. 30 Jun, 2020 1 commit
  3. 22 Jun, 2020 1 commit
  5. 31 Mar, 2020 1 commit
  7. 07 Jan, 2020 1 commit
  9. 14 Nov, 2019 1 commit
  11. 22 Oct, 2019 1 commit
  13. 13 Sep, 2019 1 commit
  15. 23 Jun, 2019 1 commit
  17. 21 Jun, 2019 1 commit
  19. 17 Jun, 2019 1 commit
  21. 13 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [arm64] Fix handling of handles in assembler · 66412e0f
      Sigurd Schneider authored 
      Previously, the handle's location was used as a proxy for the heap
object, i.e, we put the handle into the constant pool, to avoid the
need for GC visiting the constant pool entries during code generation.
The handle locations are replaced by the corresponding heap object
when the code is copied to the heap.

This CL changes the handling in the assembler: Instead of putting
in the handle location (which is a machine word) we put in a small
index number into a table. This will be useful for putting 32bit
constants into the constant pool.

This new approach also has the advantage that ordering the
constant pool entries by value produces a deterministic order
after this change.

Change-Id: Id47d56d487a0b64d1d1504a47937c8779ee02b13
Bug: v8:7703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648094
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62144}
      66412e0f
  23. 27 May, 2019 1 commit
  25. 24 May, 2019 1 commit
  27. 23 May, 2019 2 commits
  29. 21 May, 2019 1 commit
  31. 20 May, 2019 3 commits
  33. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored 
      Failure addressed by not exposing the new test to the jitless environment.
(jgruber@ on TBR).

New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
compressed pointers in generated code. Enum name EMBEDDED_OBJECT
changed to FULL_EMBEDDED_OBJECT.

RelocInfo::[set_]target_object() abstract away the difference between
FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.

Compressed embedded objects can only be created at this time on
x64 with pointer compression turned on. Arm64 constant pools don't
support compressed objects at this time.

NOPRESUBMIT=true

Bug: v8:7703
TBR: jgruber@chromium.org
Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  35. 29 Apr, 2019 2 commits
  37. 11 Apr, 2019 1 commit
  39. 04 Apr, 2019 1 commit
  41. 03 Apr, 2019 1 commit
    • Paolo Severini's avatar
      Reland "V8 x64 backend doesn't emit ABI compliant stack frames" · 969cb0c7
      Paolo Severini authored 
      This is a reland of 3cda21de

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/+/1534618Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60581}
      969cb0c7
  43. 20 Mar, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "V8 x64 backend doesn't emit ABI compliant stack frames" · 9f6ddb48
      Leszek Swirski authored 
      This reverts commit 3cda21de.

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/+/1532321Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60372}
      9f6ddb48
  45. 19 Mar, 2019 1 commit
    • Paolo Severini's avatar
      V8 x64 backend doesn't emit ABI compliant stack frames · 3cda21de
      Paolo Severini authored 
      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/+/1469329Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60330}
      3cda21de
  47. 07 Feb, 2019 1 commit
  49. 30 Jan, 2019 1 commit
  51. 22 Jan, 2019 1 commit
  53. 17 Jan, 2019 2 commits
  55. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [assembler] Allow to pass custom buffer implementations · 1a3aab51
      Clemens Hammacher authored 
      When generating an Assembler, you currently have two choices: Either
let the Assembler allocate a growable internal buffer, which is owned
by the Assembler. Or provide an externally allocated buffer, which
cannot grow.
This CL changes this interface to allow providing any implementation of
a buffer. The provided buffer can be a view to an externally owned
buffer, which still can grow.
This will be used to split WebAssembly compilation and code submission.
The buffer needs to be able to grow, but cannot be owned by the
Assembler because it has to survive until the code is submitted.

R=mstarzinger@chromium.org

Bug: v8:8689
Change-Id: Ib6c5ebffc8b71d0778944abac34f02c5cc7dbd79
Reviewed-on: https://chromium-review.googlesource.com/c/1411347
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58848}
      1a3aab51
  57. 21 Dec, 2018 1 commit
    • Sigurd Schneider's avatar
      Reland "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 2a72b8ac
      Sigurd Schneider authored 
      This is a reland of f63a657e

Original change's description:
> [deoptimizer] Refactor GenerateDeoptimizationEntries
>
> This reduces preprocessor-expanded source size by 64,359 from
>
> gen         (   21 files):    71,570 to    1,613,100 (   23x)
> src         (  624 files):   367,830 to   52,964,659 (  144x)
> test        (  392 files):   490,924 to   37,360,916 (   76x)
> third_party (  432 files):   239,085 to    9,547,902 (   40x)
> total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
>
> to
>
> gen         (   21 files):    71,570 to    1,613,100 (   23x)
> src         (  624 files):   367,837 to   52,919,005 (  144x)
> test        (  392 files):   490,924 to   37,342,211 (   76x)
> third_party (  432 files):   239,085 to    9,547,902 (   40x)
> total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
>
> Bug: v8:8562
> Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
> Reviewed-on: https://chromium-review.googlesource.com/c/1384091
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58424}

TBR=jarin@chromium.org,ulan@chromium.org

Bug: v8:8562
Change-Id: I7a8a350414941f49c6155ff43e36e0cb0b2006e5
Reviewed-on: https://chromium-review.googlesource.com/c/1387497Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58437}
      2a72b8ac
  59. 20 Dec, 2018 1 commit
  61. 19 Dec, 2018 1 commit
  63. 17 Dec, 2018 3 commits
    • Sigurd Schneider's avatar
      Reland "[assembler] Split out CPUFeatures into its own file" · 01b0afd5
      Sigurd Schneider authored 
      This is a reland of 3ad101f5

Original change's description:
> [assembler] Split out CPUFeatures into its own file
>
> This reduces the preprocessor expanded source size by 84,675 LoC:
>
> gen         (   20 files):    71,349 to    1,523,934 (   21x)
> src         (  624 files):   367,410 to   53,253,894 (  145x)
> test        (  392 files):   490,503 to   37,436,176 (   76x)
> third_party (  432 files):   239,085 to    9,547,902 (   40x)
> total       ( 1520 files): 1,183,031 to  102,736,424 (   87x)
>
> to
>
> gen         (   20 files):    71,349 to    1,523,794 (   21x)
> src         (  624 files):   367,411 to   53,186,896 (  145x)
> test        (  392 files):   490,504 to   37,418,639 (   76x)
> third_party (  432 files):   239,085 to    9,547,902 (   40x)
> total       ( 1520 files): 1,183,033 to  102,651,749 (   87x)
>
>
> Change-Id: Ia8a79092051a42815b65e86a0784297915368c9b
> Reviewed-on: https://chromium-review.googlesource.com/c/1291471
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58266}

TBR=marja@chromium.org,clemensh@chromium.org,ulan@chromium.org

Change-Id: I5b857666508b1c80dcadd0b470aada37dd49077e
Reviewed-on: https://chromium-review.googlesource.com/c/1379872Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58278}
      01b0afd5
    • Maya Lekova's avatar
      Revert "[assembler] Split out CPUFeatures into its own file" · 316b152a
      Maya Lekova authored 
      This reverts commit 3ad101f5.

Reason for revert: Broken Android Arm64 debug builder - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Android%20Arm64%20-%20debug%20builder/3089

Original change's description:
> [assembler] Split out CPUFeatures into its own file
> 
> This reduces the preprocessor expanded source size by 84,675 LoC:
> 
> gen         (   20 files):    71,349 to    1,523,934 (   21x)
> src         (  624 files):   367,410 to   53,253,894 (  145x)
> test        (  392 files):   490,503 to   37,436,176 (   76x)
> third_party (  432 files):   239,085 to    9,547,902 (   40x)
> total       ( 1520 files): 1,183,031 to  102,736,424 (   87x)
> 
> to
> 
> gen         (   20 files):    71,349 to    1,523,794 (   21x)
> src         (  624 files):   367,411 to   53,186,896 (  145x)
> test        (  392 files):   490,504 to   37,418,639 (   76x)
> third_party (  432 files):   239,085 to    9,547,902 (   40x)
> total       ( 1520 files): 1,183,033 to  102,651,749 (   87x)
> 
> 
> Change-Id: Ia8a79092051a42815b65e86a0784297915368c9b
> Reviewed-on: https://chromium-review.googlesource.com/c/1291471
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58266}

TBR=ulan@chromium.org,marja@chromium.org,sigurds@chromium.org,clemensh@chromium.org

Change-Id: I111f9bbef9e66cd1ee7f4206b6af1097f7c50e66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1379933Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58268}
      316b152a
    • Sigurd Schneider's avatar
      [assembler] Split out CPUFeatures into its own file · 3ad101f5
      Sigurd Schneider authored 
      This reduces the preprocessor expanded source size by 84,675 LoC:

gen         (   20 files):    71,349 to    1,523,934 (   21x)
src         (  624 files):   367,410 to   53,253,894 (  145x)
test        (  392 files):   490,503 to   37,436,176 (   76x)
third_party (  432 files):   239,085 to    9,547,902 (   40x)
total       ( 1520 files): 1,183,031 to  102,736,424 (   87x)

to

gen         (   20 files):    71,349 to    1,523,794 (   21x)
src         (  624 files):   367,411 to   53,186,896 (  145x)
test        (  392 files):   490,504 to   37,418,639 (   76x)
third_party (  432 files):   239,085 to    9,547,902 (   40x)
total       ( 1520 files): 1,183,033 to  102,651,749 (   87x)


Change-Id: Ia8a79092051a42815b65e86a0784297915368c9b
Reviewed-on: https://chromium-review.googlesource.com/c/1291471Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58266}
      3ad101f5
  65. 13 Dec, 2018 1 commit
    • Sigurd Schneider's avatar
      Reland "Reland "Reland "[code-comments] Put code comments into the code object""" · b55dd17f
      Sigurd Schneider authored 
      This is a reland of 9c0a4858

Original change's description:
> Reland "Reland "[code-comments] Put code comments into the code object""
>
> This is a reland of ed3d6472
>
> This reland fixes that padding at the end of Wasm instruction streams
> triggered asserts in the code printer.
>
> Original change's description:
> > Reland "[code-comments] Put code comments into the code object"
> >
> > This is a reland of e774cffe
> >
> > This reland disables a test as v8:8548 is blocking it, which was
> > broken by a recent CL. CQ did not catch this because the merge-base
> > CQ used did not yet contain the CL that caused v8:8548.
> >
> > Original change's description:
> > > [code-comments] Put code comments into the code object
> > >
> > > Code comments in the snapshot can now be enabled with gn
> > > arg 'v8_enable_snapshot_code_comments'
> > >
> > > Bug: v8:7989
> > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3
> > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173
> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#58020}
> >
> > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org
> >
> > Bug: v8:7989, v8:8548
> > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9
> > Reviewed-on: https://chromium-review.googlesource.com/c/1361166
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#58028}
>
> Bug: v8:7989, v8:8548
> Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d
> Reviewed-on: https://chromium-review.googlesource.com/c/1371784
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58221}

TBR=jgruber@chromium.org,mstarzinger@chromium.org

Bug: v8:7989, v8:8548, v8:8593
Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b
Reviewed-on: https://chromium-review.googlesource.com/c/1375919Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58232}
      b55dd17f