Skip to content

V
V8
Switch branch/tag
  1. 29 Oct, 2021 1 commit
  3. 07 Oct, 2021 1 commit
  5. 24 Sep, 2021 1 commit
  7. 15 Sep, 2021 1 commit
  9. 06 Aug, 2021 1 commit
  11. 29 Jul, 2021 1 commit
  13. 14 May, 2021 1 commit
  15. 15 Apr, 2021 1 commit
    • Thibaud Michaud's avatar
      [wasm][x64] Fix OSR shadow stack violation · 06a2c2e0
      Thibaud Michaud authored 
      We currently allow OSR (On-Stack Replacement) of arbitrarily deep return
addresses. This is in direct violation of Intel CET's shadow stack,
which we plan to enable eventually.

This change works around this by postponing OSR until after we return to
the old code. The main changes are:
- Reserve a slot in Liftoff frames to store the OSR target,
- Skip the return address modification, and instead store the new code
pointer in the dedicated slot,
- Upon returning to the old code, check the slot and do an indirect jump
to the new code if needed.

CET also prevents indirect jumps to arbitrary locations, so the last
point is also a CET violation. Valid indirect jump targets must be
marked with the ENDBRANCH instruction, which I will do in a follow-up
CL.

Bug: v8:11654
Change-Id: I6925005211aa95d60803b9409e3c07c7c226b25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826127
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73977}
      06a2c2e0
  17. 16 Mar, 2021 1 commit
  19. 05 Mar, 2021 1 commit
  21. 28 Jan, 2021 2 commits
  23. 15 Jan, 2021 1 commit
  25. 19 Nov, 2020 1 commit
  27. 17 Nov, 2020 2 commits
  29. 12 Nov, 2020 1 commit
    • Vicky Kontoura's avatar
      [wasm] Reverse count logic for the tiering of js-to-wasm wrappers · eb0ef4d7
      Vicky Kontoura authored 
      This CL reverses the count logic for the tiering strategy of the
js-to-wasm wrappers. The initial approach was that calls to each
function were counted up, until a threshold was reached and the function
would tier up. With this CL, each function is assigned a budget of calls
that can be handled through the generic wrapper. Calls are counted down
until the budget is exhausted, which will trigger the tier-up
for the function.

This approach comes with two advantages. Firstly, determining whether
a function's budget is exhausted is as simple as checking the flags set
from the decrement of the budget. Secondly, the code generated by the
generic wrapper does not depend on the specific value of the initial
budget.

Bug: v8:10982
Change-Id: I5e186c6cf836a9c197b41d0f7ad075b07c87a4da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2532300Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#71153}
      eb0ef4d7
  31. 14 Oct, 2020 1 commit
  33. 29 Sep, 2020 1 commit
  35. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][memory64] Start implementing the memory64 proposal · 18da0875
      Clemens Backes authored 
      This is a first small step for implementing the memory64 proposal:
1. Add a feature flag.
2. Add the 0x04 and 0x05 limits flag for memory64.
3. Read memory limits as LEB-encoded u64 (instead of u32) if a memory64
   limit flag was read.
4. Unify {MaximumFlag} and {MemoryFlag}, which was used inconsistently
   before.
5. Add test for memory limits encoded with >5 bytes.
6. Move some macros from module-decoder-unittest.cc to wasm-macro-gen.h.

Note that still the same limits for the maximum number of pages applies
as before, i.e. you cannot specify a memory >4GB yet. But you can encode
that small number in >5 bytes.

R=manoskouk@chromium.org

Bug: v8:10949
Change-Id: I90a4f08426ae714a67440281785eb00cfc24a349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423712
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70110}
      18da0875
  37. 30 Jun, 2020 1 commit
  39. 19 Jun, 2020 1 commit
  41. 18 Jun, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Change ValueType representation to account for new types · 52f65296
      Manos Koukoutos authored 
      Motivation:
Changes to the typed function references and gc proposals solidified
the notion of heap type, clarified nullable vs. non-nullable reference
types, and introduced rtts, which contain an integer depth field in
addition to a heap type. This required us to overhaul our ValueType
representation, which results in extensive changes.

To keep this CL "small", we do not try to implement the binary encoding
as described in the proposals, but rather devise a simpler one of our
own (see below). Also, we do not try to implement additional
functionality for the new types.

Changes:
- Introduce HeapType. Move heap types from ValueType to HeapType.
- Introduce Nullability for reference types.
- Rework ValueType helper methods.
- Introduce rtts in ValueType with an integer depth field. Include depth
  in the ValueType encoding.
- Make the constructor of ValueType private, instead expose static
  functions which explicitly state what they create.
- Change every switch statement on ValueType::Kind. Sometimes, we need
  nested switches.
- Introduce temporary constants in ValueTypeCode for nullable types,
  use them for decoding.
- In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'.
- Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in
  subtyping.
- kWasmFuncRef initializers are now non-nullable. Initializers are
  only required to be subtypes of the declared global type.
- Change tests and fuzzers as needed.

Bug: v8:7748
Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68408}
      52f65296
  43. 10 Jun, 2020 1 commit
  45. 09 Jun, 2020 1 commit
  47. 27 May, 2020 1 commit
  49. 05 May, 2020 1 commit
  51. 20 Apr, 2020 1 commit
  53. 17 Apr, 2020 1 commit
  55. 26 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Reduce size of {WasmCode} objects · c626bc5e
      Clemens Backes authored 
      This is a first step to make {WasmCode} objects smaller. Many code
offsets are currently stored in {size_t} even though there were
originally (during assembly) an int. Others are stored in {uint32_t}.

This CL switches the function index and all code lengths and offsets to
int, because
a) bigger code is not supported anyway, and
b) the style guide recommends int over unsigned types.

This makes the {WasmCode} 24 bytes smaller on x64 (from 144 to 120
bytes).

R=ahaas@chromium.org

Bug: v8:10254
Change-Id: I8f78bf4be64d59cf9393e3b6662d9d3bd153d387
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074217Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66462}
      c626bc5e
  57. 15 Jan, 2020 1 commit
  59. 25 Sep, 2019 1 commit
    • Ingvar Stepanyan's avatar
      Add support for reporting raw Wasm scripts · c7848612
      Ingvar Stepanyan authored 
      This addition will allow to experiment with parsing DWARF information from
WebAssembly on the frontend side for improved debugging.

The frontend must explicitly opt-in to this experiment by setting
`supportsWasmDwarf: true` in `Debugger.enable` params.

When this option is present, and Wasm appears to contain DWARF information
(heuristic: `.debug_info` custom section is present), V8 will not try to
disassemble and report each WebAssembly function as a separate fake script, but
instead will report Wasm module as a whole.

Note that V8 already does this when Wasm is associated with a source map.

Additionally, this CL adds a dedicated `Debugger.getWasmBytecode` command that
accepts scriptId and returns raw wire bytes of the chosen WebAssembly module.

Change-Id: I7a6e80daf8d91ffaaba04fa15688f2ba9552870f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809375
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63969}
      c7848612
  61. 15 Jul, 2019 1 commit
  63. 08 Jul, 2019 1 commit
  65. 05 Jun, 2019 1 commit
    • Thibaud Michaud's avatar
      [wasm] Early compilation of import wrappers · b15b2c91
      Thibaud Michaud authored 
      Compile import wrappers during module compilation by introducing import
wrapper compilation units, the goal being to reduce instantiation time.

For each wrapper, we assume the imported function is going to be a
kJSFunctionArityMatchSloppy at instantiation time, which should be the
most common case. If the function turns out to have a different kind the
wrapper is going to be recompiled with the correct kind during instantiation.

R=ahaas@chromium.org, clemensh@chromium.org
CC=titzer@chromium.org

Bug: v8:9231
Change-Id: Ieb050b09d1c19f2a5a3e59132a1864dadb06775d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630685
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61993}
      b15b2c91
  67. 24 May, 2019 1 commit
  69. 18 Apr, 2019 1 commit
  71. 18 Mar, 2019 1 commit
  73. 26 Feb, 2019 1 commit
  75. 29 Nov, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Parse DataCount section for bulk-memory · cb62c6ed
      Ben Smith authored 
      The bulk-memory proposal adds a new DataCount section that declares the
number of data segments that are expected to be seen in the Data
section. This is similar to the way the number of functions is split
between the Function and Code sections.

The DataCount section occurs before the Code section, so we can do
single-pass validation of the new `memory.init` and `memory.drop`
instructions, which have data segment indices as immediates.

Bug: v8:7747
Change-Id: Ibc5a7ee9336dbc5d0fd667572c42cb065c048e00
Reviewed-on: https://chromium-review.googlesource.com/c/1352792
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57951}
      cb62c6ed