Skip to content

V
V8
Switch branch/tag
  1. 27 Jun, 2022 1 commit
  3. 22 Jun, 2022 1 commit
  5. 09 Jun, 2022 1 commit
  7. 13 May, 2022 1 commit
  9. 18 Feb, 2022 1 commit
  11. 16 Feb, 2022 1 commit
  13. 02 Feb, 2022 1 commit
  15. 20 Jan, 2022 1 commit
  17. 13 Aug, 2021 1 commit
  19. 12 Aug, 2021 1 commit
  21. 07 Jul, 2021 1 commit
  23. 21 Apr, 2021 1 commit
  25. 12 Apr, 2021 1 commit
  27. 23 Feb, 2021 2 commits
  29. 24 Nov, 2020 1 commit
  31. 14 Sep, 2020 1 commit
  33. 31 Aug, 2020 1 commit
    • Jake Hughes's avatar
      [heap] Add object start bitmap for conservative stack scanning · 5f6aa2e5
      Jake Hughes authored 
      With conservative stack scanning enabled, a snapshot of the call stack
upon entry to GC will be used to determine part of the root-set. When
the collector walks the stack, it looks at each value and determines
whether it could be a potential on-heap object pointer. However, unlike
with Handles, these on-stack pointers aren't guaranteed to point to the
start of the object: the compiler may decide hide these pointers, and
create interior pointers in C++ frames which the GC doesn't know about.

The solution to this is to include an object start bitmap in the header
of each page. Each bit in the bitmap represents a word in the page
payload which is set when an object is allocated. This means that when
the collector finds an arbitrary potential pointer into the page, it can
walk backwards through the bitmap until it finds the relevant object's
base pointer. To prevent the bitmap becoming stale after compaction, it
is rebuilt during object sweeping.

This is experimental, and currently only works with inline allocation
disabled, and single generational collection.

Bug: v8:10614
Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69615}
      5f6aa2e5
  35. 02 Jul, 2020 1 commit
  37. 03 Jun, 2020 1 commit
  39. 11 May, 2020 1 commit
  41. 17 Apr, 2020 1 commit
  43. 09 Mar, 2020 1 commit
  45. 20 Feb, 2020 1 commit
    • Paolo Severini's avatar
      Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub · 03fc4149
      Paolo Severini authored 
      This is the first piece of the wasm debugging prototype (besides the changes to
add/remove breakpoints in WasmModuleObject made with
https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737).

This changelist adds the infrastructure for a GDB-remote stub that will be used
to manage debugging sessions via the gdb-remote protocol.
It enables the creation and termination of debugging sessions over TCP
connections that are managed in a separate thread.
The logic to actually send, receive and decode GDB-remote packets will be part
of a future changelist.

Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with:
  --wasm-gdb-remote                  Enables Wasm debugging with LLDB
                                     (default: false)
  --wasm-gdb-remote-port             TCP port to be used for debugging
                                     (default: 8765)
  --wasm-pause-waiting-for-debugger  Pauses the execution of Wasm code waiting
                                     for a debugger (default: false)
  --trace-wasm-gdb-remote            Enables tracing of Gdb-remote packets
                                     (default: false)

Note that most of this code is "borrowed" from the code of the Chromium NaCL
GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub).

Implementation details:
- class GdbServer acts as a singleton manager for the gdb-remote stub. It is
  instantiated as soon as the first Wasm module is loaded in the Wasm engine.
- class GdbServerThread spawns the worker thread for the TCP connection.
- class Transport manages the socket connection, in a portable way.
- class Session represents a remote debugging session.
- class Target represents a debugging target and it’s the place where the
  debugging packets will be processed and will implement the logic to debug
  a Wasm engine.

Bug: chromium:1010467
Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66379}
      03fc4149
  47. 18 Feb, 2020 1 commit
  49. 13 Feb, 2020 1 commit
  51. 18 Dec, 2019 1 commit
  53. 04 Nov, 2019 1 commit
  55. 31 Oct, 2019 1 commit
  57. 29 Oct, 2019 1 commit
  59. 16 Oct, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" · 69efc4c3
      Simon Zünd authored 
      This is a reland of 1c56974f

This is a plain reland of the original CL. The original CL was speculatively
reverted, but ended up not being the cause for bot failures.

Original change's description:
> Unconditionally enable snapshot builds and remove 'v8_use_snapshot'
>
> This CL removes 'v8_use_snapshot' and the usages of the implied
> V8_USE_SNAPSHOT define. One test runner unittest was updated to use the
> "asan" variant instead of the now obsolete "no_snap" variant.
>
> Related chromium CL: https://crrev.com/c/1796325.
>
> Bug: v8:8531
> Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64290}

TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org

Bug: v8:8531
Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64305}
      69efc4c3
  61. 15 Oct, 2019 2 commits
  63. 07 Oct, 2019 1 commit
  65. 20 Sep, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Use instance types of known Maps in v8_debug_helper · 1d3c4975
      Seth Brenith authored 
      If we can read an object's Map pointer but not any data from the Map
itself, we may still be able to accurately describe the object's type if
the Map pointer matches one of the known Maps from the snapshot.
GetObjectProperties uses that data in one of two ways:
- If it is sure that the Map pointer matches a known Map, then it uses
  the type from that Map and continues as if it read the type normally.
- If the Map pointer is at the right offset within a heap page to match
  a known Map, but the caller didn't provide the addresses of the first
  pages in Map space or read-only space, then the type of that Map is
  just a guess and gets returned in a separate array. This gives the
  caller the opportunity to present guessed types to the user, and
  perhaps call again using the guessed type as the type hint.

Bug: v8:9376
Change-Id: I187f67b77e76699863a14534a9d635b79f654124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63908}
      1d3c4975
  67. 18 Jun, 2019 1 commit
  69. 27 May, 2019 1 commit
    • Peter Marshall's avatar
      [tracing] Add a way to test perfetto traces. · d365f62e
      Peter Marshall authored 
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61854}
      d365f62e
  71. 09 Apr, 2019 1 commit
    • Jakob Gruber's avatar
      [build] Compile compiler with optimizations in fast mksnapshot mode · 7e896fe5
      Jakob Gruber authored 
      This changes debug builds [1] to compile src/compiler sources twice:

1. with optimizations, used in mksnapshot to improve performance.
2. without optimizations, linked into d8 and v8 libraries.

While this adds ~200 compilation targets, these can be built in parallel
and should not add much time overall.

This brings mksnapshot runtime back down to 11 seconds on my machine.

[1] The full condition is:
    is_debug && !v8_optimized_debug && v8_enable_fast_mksnapshot

Cq-Include-Trybots: luci.chromium.try:android_arm64_dbg_recipe
Cq-Include-Trybots: luci.chromium.try:fuchsia_x64
Bug: v8:8767
Change-Id: Iac57bf8331395d9eda9be5d192e8eeeded182ae6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532335
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60713}
      7e896fe5
  73. 02 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "Reland^2 "[build] disable C++ optimization for mksnapshot code."" · 5f58a82b
      Tobias Tebbi authored 
      This reverts commit 6beea97e.

Reason for revert: https://crbug.com/942497

Original change's description:
> Reland^2 "[build] disable C++ optimization for mksnapshot code."
>
> This is a reland of a6b95a6a
>
> In addition to UBSan, also ASAN needs optimizations.
> So this CL doesn't disable optimizations for all sanitizer builds.
>
> Original change's description:
> > Reland "[build] disable C++ optimization for mksnapshot code."
> >
> > This is a reland of cee2f772
> >
> > Original change's description:
> > > [build] disable C++ optimization for mksnapshot code.
> > >
> > > By disabling C++ optimizations for code that's only run in mksnapshot,
> > > that is, CSA and Torque-generated code, we can save compile time.
> > > I observed up to 2x improvements of compile time for some files,
> > > while the mksnapshot time did not increase significantly.
> > >
> > > Bug: v8:7629
> > > Change-Id: I96be2966611b2471b68023e0dd9e351d94f0013c
> > > Reviewed-on: https://chromium-review.googlesource.com/c/1460941
> > > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#59585}
> >
> > Bug: v8:7629
> > Change-Id: I8330f93173ab3d7b400e15ea4935bbe8256b250f
> > Reviewed-on: https://chromium-review.googlesource.com/c/1473292
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#59606}
>
> Bug: v8:7629
> Change-Id: I42175c472d8e41345573df81645dfe3accc9d8c4
> Reviewed-on: https://chromium-review.googlesource.com/c/1475396
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59632}

TBR=yangguo@chromium.org,sigurds@chromium.org,tebbi@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:7629 chromium:942497
Change-Id: Ie51d7b53440230b41fb763541908cb1162d8850d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549158
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60577}
      5f58a82b
  75. 26 Mar, 2019 1 commit