Skip to content

V
V8
Switch branch/tag
  1. 18 May, 2020 1 commit
    • Clemens Backes's avatar
      [utils] Synchronize across StdoutStream instances · a0687c71
      Clemens Backes authored 
      We constantly fight against scrambled output with --print-wasm-code and
other flags. Passing --single-threaded only partially mitigates this,
because there could still be multiple isolates (e.g. Workers), and we
sometimes failed to really execute in a single thread if that flag was
set.
Hence this CL solves the problem in a more fundamental way: Whenever a
{StdoutStream} is constructed, it implicitly takes a global recursive
mutex. The recursive mutex is needed because we still have some printing
methods that don't take a stream as parameter, and instead create their
own instance of {StdoutStream}, which should not crash of course.

The overhead of taking a mutex should be acceptable, since output to
stdout mostly happens if special tracing flags have been passed, and is
slow anyway.

This CL ensures that the {StdoutStream} is used at least for
--print-code, --print-wasm-code, and --trace-turbo-graph.
More flags can later be ported on demand.

The {JSHeapBroker} class was modified to not contain a {StdoutStream},
but instead create one on demand.

R=mlippautz@chromium.org, tebbi@chromium.org
CC=ahaas@chromium.org

Bug: v8:10506
Change-Id: Ib9cf8d76aa79553b4215bb7775e6d47a8179aafa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201767Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67855}
      a0687c71
  3. 14 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add off thread deserialization · 595609fb
      Leszek Swirski authored 
      Add a new OffThreadObjectDeserializer, which can deserialize a snapshot
into an OffThreadIsolate.

This involves templating the Deserializer base class on Isolate, and
amending OffThreadHeap to be able to create Reservations same as the
main-thread Heap can. Various off-thread incompatible methods are
stubbed out as UNREACHABLE in OffThreadIsolate overloads.

There is currently no API entry into the off-thread deserialization, but
under --stress-background-compile it now runs the CodeDeserializer (i.e.
code cache deserialization) in a background thread.

Bug: chromium:1075999

Change-Id: I2453f51ae31df4d4b6aa94b0804a9d6d3a03781e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172741
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67799}
      595609fb
  5. 07 May, 2020 1 commit
  7. 06 May, 2020 1 commit
  9. 17 Apr, 2020 2 commits
    • Clemens Backes's avatar
      [base] Fix {StaticCharVector} and add {StaticOneByteVector} · e04eb281
      Clemens Backes authored 
      {StaticCharVector}, according to its name, should return a
{Vector<const char>}. For getting a {Vector<const uint8_t>}, the method
should be called {StaticOneByteVector}, analog to the
{OneByteVector} methods that already exist.

Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot
be, since it contains a {reinterpret_cast}. The same holds for
{Vector::cast} in general.

This CL
- changes the return type of {StaticCharVector} to be
  {Vector<const char>},
- introduces a new {StaticOneByteVector} which returns
  {Vector<const uint8_t>},
- fixes constexpr annotations at various methods returning {Vector}s,
- refactors users of {StaticCharVector} to either use
  {StaticOneByteVector} instead, or work on {char} if that makes more
  sense.

R=leszeks@chromium.org

Bug: v8:10426
Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67213}
      e04eb281
    • Clemens Backes's avatar
      [base][vector] Test constexpr factories · 80e5e2b4
      Clemens Backes authored 
      Test some constexpr factories. StaticCharVector is not actually
constexpr, this will be fixed in a follow-up CL.

R=leszeks@chromium.org

Bug: v8:10426
Change-Id: I16fdf79cd7d4b3f54d7cf73e15bdff2306810f06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154192
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67210}
      80e5e2b4
  11. 05 Mar, 2020 3 commits
    • Clemens Backes's avatar
      Reland "[wasm] Further reduce the size of WasmCode" · 13cdf3a7
      Clemens Backes authored 
      This is a reland of 79398ab0

Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
>   undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}

Tbr: ahaas@chromium.org
Bug: v8:10254
Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66598}
      13cdf3a7
    • Clemens Backes's avatar
      Revert "[wasm] Further reduce the size of WasmCode" · 28afd1c9
      Clemens Backes authored 
      This reverts commit 79398ab0.

Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186

Original change's description:
> [wasm] Further reduce the size of WasmCode
> 
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
> 
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
> 
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
> 
> Drive-by: Add some more checks to {Vector::cast} to protect against
>   undefined behaviour.
> 
> R=​ahaas@chromium.org
> 
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}

TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org

Change-Id: Id80aa82cfce8942879031032b322ee66855b5600
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66597}
      28afd1c9
    • Clemens Backes's avatar
      [wasm] Further reduce the size of WasmCode · 79398ab0
      Clemens Backes authored 
      Also, save dynamic allocations (plus their memory overhead).
This is realized by storing the relocation information, source position
table, and protected instruction information together in one "metadata"
byte array.
For each of the three components, we just store their size, such that
the accessors can return the respecitive {Vector} views as before.

This makes each WasmCode object 24 bytes smaller on 64-bit
architectures. It also saves a few more bytes per code object because
less padding is needed for the individual allocations, and each dynamic
allocation comes with some constant memory overhead.

Since the protected instructions will just be stored in a byte array
now, some APIs are refactored to just return that byte array directly
(instead of an array of {ProtectedInstructionData}). This also
simplifies serialization and deserialization, and will allow for
switching to a more compact representation in the future.

Drive-by: Add some more checks to {Vector::cast} to protect against
  undefined behaviour.

R=ahaas@chromium.org

Bug: v8:10254
Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66596}
      79398ab0
  13. 20 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Avoid unnecessary jump tables · 1403fd7d
      Clemens Backes authored 
      If multiple code spaces are created, each of them currently gets its own
jump table (on 64 bit platforms). Since we try to allocate new code
spaces right after existing ones, this is often not necessary. We could
instead reuse the existing jump table(s).
This saves code space for the unneeded jump tables and avoid the cost of
patching the redundant jump tables when we replace code objects.

This CL implements this by checking whether an existing jump table (or
pair of far jump table and (near) jump table) fully covers a new code
space, and reuses the existing jump table in that case.

R=ahaas@chromium.org

Change-Id: Id8751b9c4036cf8f85f9baa2b0be8b2cfb5716ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043846Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66364}
      1403fd7d
  15. 20 Jan, 2020 1 commit
  17. 16 Jan, 2020 1 commit
  19. 02 Dec, 2019 1 commit
  21. 26 Nov, 2019 1 commit
  23. 25 Nov, 2019 4 commits
  25. 20 Nov, 2019 1 commit
  27. 15 Nov, 2019 1 commit
  29. 14 Nov, 2019 1 commit
  31. 12 Nov, 2019 3 commits
  33. 08 Nov, 2019 3 commits
  35. 31 Oct, 2019 1 commit
  37. 30 Oct, 2019 1 commit
  39. 23 Oct, 2019 1 commit
    • Clemens Backes's avatar
      Speed up {MemCopy} and {MemMove} for small sizes · 50784597
      Clemens Backes authored 
      The same change on the {CopyChars} function gave an unexpected 10-20%
speedup on microbenchmarks across platforms (ia32, x64, Atom_x64).
This CL explores whether a similar change generally speeds up {MemCopy}
and {MemMove} (only on x64 for now). If this is the case, we might be
able to carefully extend the same pattern to other platforms and remove
custom assembly implementations without too much regression.

R=leszeks@chromium.org

Bug: v8:9810
Change-Id: Ib9674807b67cd2a463680b97a91ae1b41c3be65b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871607Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64498}
      50784597
  41. 19 Oct, 2019 1 commit
  43. 16 Oct, 2019 1 commit
  45. 08 Oct, 2019 1 commit
  47. 07 Oct, 2019 1 commit
  49. 18 Sep, 2019 2 commits
    • Clemens Hammacher's avatar
      Reland "Disallow nullptr arguments for {CopyChars}" · 8da3ed08
      Clemens Hammacher authored 
      This is an unmodified reland of
60624b56. Nosnap bots do not block
LKGR any more: https://crbug.com/v8/9737#c10.

Original change's description:
> Disallow nullptr arguments for {CopyChars}
>
> This allows to remove special casing for the {count == 0} case, which
> was needed because {memmove} does not accept {nullptr} arguments even
> if the {count} is zero.
>
> R=leszeks@chromium.org
>
> Bug: v8:9396
> Change-Id: Iaef3cdbbffa74c2ba1c4e4501dafd943282cbcd9
> Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807366
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63838}

TBR=leszeks@chromium.org

Bug: v8:9396
Change-Id: I6ab13575f13df060b450ff105e4b9db516671dcf
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809365Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63863}
      8da3ed08
    • Clemens Hammacher's avatar
      Reland^2 "Remove all custom CopyCharsUnsigned implementations" · 3b808dee
      Clemens Hammacher authored 
      This is an unmodified reland of
9febc505. Nosnap bots do not block
LKGR any more: https://crbug.com/v8/9737#c10.

Original change's description:
> Reland "Remove all custom CopyCharsUnsigned implementations"
>
> This is a reland of 5d8c4890
>
> Original change's description:
> > Remove all custom CopyCharsUnsigned implementations
> >
> > It's unclear whether the custom implementation have any advantage over
> > the standard library one's.
> > Since we update our toolchain and standard library regularly, it might
> > well be the case that the custom implementations are slower by now.
> >
> > Thus this CL removes all {CopyCharsUnsigned} implementations and
> > implements {CopyChars} generically using {std::copy_n}.
> >
> > Note that this does not touch the {MemMove} and {MemCopy} functions
> > yet, as we have seen regressions when trying to remove them before
> > (https://crbug.com/v8/8675#c5).
> >
> > R=leszeks@chromium.org
> >
> > Bug: v8:9396
> > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63808}
>
> Bug: v8:9396
> Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
> Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63823}

TBR=leszeks@chromium.org

Bug: v8:9396
Change-Id: I793524d76b8b9c93d2a98c73e8d72967880fe1cf
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809362
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63857}
      3b808dee
  51. 17 Sep, 2019 3 commits
    • Adam Klein's avatar
      Revert "Reland "Remove all custom CopyCharsUnsigned implementations"" · 24c35b92
      Adam Klein authored 
      This reverts commits 9febc505
(along with followup commit 60624b56).

Reason for revert: Breaks win32 nosnap shared, blocking lkgr & roll:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/35145

nosnap bots may be deprecated, but as long as they're in LKGR
we need to mind them.

Original change's description:
> Reland "Remove all custom CopyCharsUnsigned implementations"
>
> This is a reland of 5d8c4890
>
> Original change's description:
> > Remove all custom CopyCharsUnsigned implementations
> >
> > It's unclear whether the custom implementation have any advantage over
> > the standard library one's.
> > Since we update our toolchain and standard library regularly, it might
> > well be the case that the custom implementations are slower by now.
> >
> > Thus this CL removes all {CopyCharsUnsigned} implementations and
> > implements {CopyChars} generically using {std::copy_n}.
> >
> > Note that this does not touch the {MemMove} and {MemCopy} functions
> > yet, as we have seen regressions when trying to remove them before
> > (https://crbug.com/v8/8675#c5).
> >
> > R=leszeks@chromium.org
> >
> > Bug: v8:9396
> > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63808}
>
> Bug: v8:9396
> Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
> Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63823}

TBR=leszeks@chromium.org,clemensh@chromium.org

Change-Id: Ic53ab2293d5dc7722a1121d1aa1159328a6ed8f5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808035Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63854}
      24c35b92
    • Clemens Hammacher's avatar
      Disallow nullptr arguments for {CopyChars} · 60624b56
      Clemens Hammacher authored 
      This allows to remove special casing for the {count == 0} case, which
was needed because {memmove} does not accept {nullptr} arguments even
if the {count} is zero.

R=leszeks@chromium.org

Bug: v8:9396
Change-Id: Iaef3cdbbffa74c2ba1c4e4501dafd943282cbcd9
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807366Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63838}
      60624b56
    • Clemens Hammacher's avatar
      Reland "Remove all custom CopyCharsUnsigned implementations" · 9febc505
      Clemens Hammacher authored 
      This is a reland of 5d8c4890

Original change's description:
> Remove all custom CopyCharsUnsigned implementations
>
> It's unclear whether the custom implementation have any advantage over
> the standard library one's.
> Since we update our toolchain and standard library regularly, it might
> well be the case that the custom implementations are slower by now.
>
> Thus this CL removes all {CopyCharsUnsigned} implementations and
> implements {CopyChars} generically using {std::copy_n}.
>
> Note that this does not touch the {MemMove} and {MemCopy} functions
> yet, as we have seen regressions when trying to remove them before
> (https://crbug.com/v8/8675#c5).
>
> R=leszeks@chromium.org
>
> Bug: v8:9396
> Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63808}

Bug: v8:9396
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63823}
      9febc505
  53. 16 Sep, 2019 1 commit