Skip to content

V
V8
Switch branch/tag
  1. 18 Feb, 2022 2 commits
  3. 15 Feb, 2022 2 commits
  5. 14 Feb, 2022 1 commit
  7. 11 Feb, 2022 1 commit
    • Manos Koukoutos's avatar
      [wasm][fuzzer] Restructure and fix bugs in wasm-compile · 318719a1
      Manos Koukoutos authored 
      Changes:
- GenerateInitExpr should emit a function reference to a function that
  is known to exist when funcref is expected.
- Add functions by signature index to the WasmModuleBuilder, so we avoid
  signature canonicalization, which currently does not work for wasm-gc.
- Remove printing of recursive groups in the WasmModuleBuilder. Instead,
  restrict type definitions to only refer to previous types.
- Some local restructuring of code, comments.

Bug: chromium:1296162
Change-Id: I5abd9bf8ec21ef6a51f00bc960b78519f2ec94f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3452433Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79054}
      318719a1
  9. 10 Feb, 2022 1 commit
  11. 09 Feb, 2022 1 commit
  13. 31 Jan, 2022 1 commit
  15. 27 Jan, 2022 2 commits
    • Manos Koukoutos's avatar
      [wasm-gc] Implement iso-recursive types · fe531e1f
      Manos Koukoutos authored 
      This CL replaces the equirecursive type system for wasm-gc with the
isorecursive hybrid type system presented here:
https://github.com/WebAssembly/gc/issues/257.

In broad strokes, this includes the following changes:
- In the module decoder, remove equirecursive types. Implement recursive
  type groups, subtype definitions, and function/struct/array
  definitions. Treat nominal modules as syntactic sugar of an
  isorecursive module, where all types belong in the same recursive
  group.
- Remove rtt.sub and all related infrastructure.
- Change subtyping to work with explicit supertypes only.
- Add ValidSubtypeDefinition in subtyping, to check that subtype
  declarations are valid during decoding.
- Remove the subtyping cache.
- Add support for functions to have specific signature index in
  WasmModuleBuilder and in test-gc.cc.
- Adapt tests.

Current restrictions:
- Recursive groups are not stored beyond decoding.
- Type canonicalization is not implemented. No tests relying on types
  being considered identical post-canonicalization.
- No cross-module subtyping is possible. Tests relying on cross-module
  subtyping have been commented out.

Bug: v8:7748
Change-Id: I69fd04ecc5611f6230c95d5c89d1c520163fffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416239Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78816}
      fe531e1f
    • Manos Koukoutos's avatar
      [wasm] Small refactoring for module types · 9566a6e3
      Manos Koukoutos authored 
      Changes:
- Introduce {TypeDefinition} for wasm modules.
- Introduce an enum {TypeDefinition::Kind} to represent the three
  different definition types.
- Collapse the {types}, {type_kinds} and {supertypes} vectors into a
  single vector of {TypeDefinition}s.
- Use {TypeDefinition} in WasmModuleBuilder.
- Drive-by: Remove {kNullIndex} in WasmModuleBuilder.
- Drive-by: Tidy-up wasm-module.h.

Change-Id: I97c2c268bcad745176243c693cf169bfa5714f94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416233Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78813}
      9566a6e3
  17. 26 Jan, 2022 1 commit
  19. 12 Jan, 2022 2 commits
  21. 11 Jan, 2022 1 commit
  23. 04 Jan, 2022 1 commit
    • Manos Koukoutos's avatar
      [wasm] Unify treatment of expressions in elem. segments · e9440c45
      Manos Koukoutos authored 
      We unify the implementation of element segment expression entries with
other initializer expressions: we represent them with a {WireBytesRef}
and decode them with {InitExprInterface}. Except for reducing code
duplication, this also fixes a bug where {global.get} entries in element
segments could reference invalid globals.

Changes:
- Change {WasmElemSegment::Entry} to a union of a {WireBytesRef}
  initializer expression and a {uint32_t} function index.
- In module-decoder, change parsing of expression entries to use
  {consume_init_expr}. Add type checking to
  {consume_element_func_index}, to complement type checking happening in
  {consume_init_expr}.
- In module-instantiate.cc:
  - Move instantiation of indirect tables before loading of element
    segments. This way, when we call {UpdateDispatchTables} in
    {SetTableEntry}, the indirect table for the current table will also
    be updated.
  - Consolidate table entry instantiation into {SetTableEntry}, which
    handles lazily instantiated functions, or dispatches to
    {WasmTableObject::Set}.
  - Rename {InitializeIndirectFunctionTables} to
    {InitializeNonDefaultableTables}.
  - Change {InitializeNonDefaultableTables} and {LoadElemSegmentImpl}
    to use {EvaluateInitExpression}.
- Add a test to exclude mutable/non-imported globals from the element
  section.
- Update tests as needed.
- Update .js module emission in wasm-fuzzer-common.

Change-Id: I29c541bbca8531e8d0312ed95869c8e78a5a0c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364082Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78476}
      e9440c45
  25. 20 Dec, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][fuzzer] Do not enable shared memory · 2344edb2
      Clemens Backes authored 
      Shared array buffers are not tracked by the garbage collector, which
makes the fuzzer run out of memory pretty quickly. Since shared memory
is not needed any more for testing atomics, we can just make the memory
non-shared again.

This also improves the performance of the fuzzer (execs/s) by more than
2x locally.

R=ahaas@chromium.org

Bug: chromium:1281419
Change-Id: Ic7803617d6a14aaa698d9181327ec20b21d29faa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350764Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78418}
      2344edb2
  27. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored 
      This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:

V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox

This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.

Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.

Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  29. 13 Dec, 2021 1 commit
  31. 08 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Introduce ReusableUnoptimizedCompileState · b3e1eb0c
      Leszek Swirski authored 
      Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
which stores a couple of pointers and most importantly the Zone and
AstValueFactory of the parse. This allows the Zone and AstValueFactory
to be reused across multiple parses, rather than re-initialising
per-Parse.

With this, we can amend the LazyCompileDispatcher to initialise one
LocalIsolate, Zone and AstValueFactory per background thread loop,
rather than one per compile task, which allows us to reduce per-task
costs and re-use the AstValueFactory's string table and previous String
internalizations.

Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78289}
      b3e1eb0c
  33. 30 Nov, 2021 1 commit
  35. 17 Nov, 2021 2 commits
  37. 16 Nov, 2021 1 commit
    • Clemens Backes's avatar
      [fuzzer][wasm] Explicitly test mid-tier register allocation · 97390bdc
      Clemens Backes authored 
      This CL refactors how the first byte(s) of the input are used to set
internal configuration, like which compiler to use and whether Liftoff
will be used as reference instead of the interpreter.

We now always use exactly one byte, and use it for all internal
configuration. If more bits are needed in the future we can either
extend to two bytes, or use the same bits for multiple things, while
avoiding to lose coverage of all interesting configurations.

For now, we use the first byte to derive
- which compiler to use per function,
- whether to use Liftoff as reference, and
- (new) whether to globally enable the mid-tier register allocator.

R=thibaudm@chromium.org

Bug: v8:12330
Change-Id: I2cae6628554ca8f7e08115015b36f9f0a6b8c34f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253156
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77929}
      97390bdc
  39. 05 Nov, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm][fuzzer] Complex init. expressions in JS testcase · 74d9a764
      Manos Koukoutos authored 
      We enable struct.new and array.init initializer expressions in the JS
testcase generated by --wasm-fuzzer-gen-test. We needed to make some
changes in the WasmInitExpr class, and to implement a new interface for
the WasmFullDecoder, which constructs a WasmInitExpr.
Changes:
- Make WasmInitExpr a ZoneObject. Use a pointer for its operands_ field.
  This is needed so WasmInitExpr is trivially copiable, and thus usable
  as a Value type in WasmFullDecoder.
- Implement a WasmFullDecoder interface in wasm-fuzzer-common that
  constructs a WasmInitExpr. Use it to decode initializers in the
  module generated by the fuzzer.
- Change AppendInitExpr to take a WasmInitExpr as argument.
- Fix an issue with printing of struct definitions.
- Change initializer expression used for structs to struct.new_with_rtt.
  This is consistent with the currently used structural types.

Bug: v8:11954
Change-Id: I65a87cc98701a54f32500be192b3b6eef2ff6c8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257712Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77730}
      74d9a764
  41. 02 Nov, 2021 2 commits
  43. 26 Oct, 2021 1 commit
  45. 18 Oct, 2021 1 commit
  47. 13 Oct, 2021 2 commits
  49. 12 Oct, 2021 1 commit
  51. 08 Oct, 2021 1 commit
  53. 07 Oct, 2021 1 commit
  55. 04 Oct, 2021 1 commit
  57. 01 Oct, 2021 1 commit
  59. 28 Sep, 2021 2 commits
  61. 27 Sep, 2021 1 commit
  63. 23 Sep, 2021 1 commit