1. 10 Jun, 2021 1 commit
  2. 07 Jun, 2021 2 commits
  3. 25 May, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up spec'ed max memory vs dynamic max · 2d04a627
      Clemens Backes authored
      There are two different limits for the maximum memory size in
      WebAssembly:
      1) A 4GB limit which is the same on all platforms, and is observable for
      JS programs. It is used to limit the allowed declared maximum size of a
      wasm memory.
      2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise)
      which can be further limited using a command-line flag. This limit is
      used whenever actually allocating or growing a wasm memory. This limit
      is not directly observable, but we make sure that no wasm memory will
      ever be bigger than this limit.
      
      The second limit is the one we should check against when allocating or
      growing memory, while the first limit should be used when validating
      a module (or the parameters for WebAssembly.Memory). The compiler can
      rely on no memory being bigger than the second limit, which again is
      never bigger than the first limit.
      
      This CL adds some more documentation to the two limits, and cleans up
      all usages.
      This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime}
      obsolete.
      
      R=jkummerow@chromium.org
      
      Bug: chromium:1207263
      Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74742}
      2d04a627
  4. 14 May, 2021 1 commit
  5. 11 May, 2021 1 commit
  6. 13 Apr, 2021 1 commit
  7. 25 Mar, 2021 1 commit
  8. 23 Mar, 2021 1 commit
    • Andreas Haas's avatar
      [api] Add callback to set up conditional features · 16d9298a
      Andreas Haas authored
      Origin trials allow webpages to use experimental features even though
      the features are not yet enabled by default. These features will then
      get enabled per execution context: it is possible that the feature is
      enabled in one execution context but disabled in another execution
      context. In V8 we check for origin trials by calling a callback provided
      by the embedder that takes the context as a parameter and returns
      whether a feature is enabled in this context or not.
      
      This approach fails when a feature changes the context itself, e.g. by
      extending the global object. In that case the context is not available
      yet to check for the origin trial.
      
      To solve the problem this CL adds a new API function that can be called
      by the embedder to notify V8 that context with the origin trial
      information is finished. After that V8 can read the origin trial
      information from the context and extend e.g. the global object with the
      origin trial features.
      
      Additionally to the API this CL also adds code to enable the
      WebAssembly.Exception constructor conditionally, depending on whether
      it has been enabled by an origin trial or not.
      
      The Blink-side change: https://crrev.com/c/2775573
      
      R=ulan@chromium.org, jkummerow@chromium.org
      
      Change-Id: Ic05c4a89eb3e0e31469e49da8767d630c43b2e00
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773287Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73597}
      16d9298a
  9. 22 Mar, 2021 1 commit
  10. 17 Mar, 2021 1 commit
  11. 05 Mar, 2021 1 commit
  12. 24 Feb, 2021 1 commit
  13. 23 Feb, 2021 1 commit
  14. 22 Feb, 2021 1 commit
  15. 28 Jan, 2021 2 commits
  16. 15 Jan, 2021 1 commit
  17. 07 Jan, 2021 2 commits
  18. 05 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug][wasm] Move DebugEvaluate implementation to wasm-debug.cc. · 5fc4649d
      Benedikt Meurer authored
      Previously the proxies that make up the DebugEvaluate implementation for
      Wasm frames lived in wasm-js.cc, but that was quite confusing since
      
      (a) the rest of the debug support for Wasm lives in wasm-debug.cc (and
          we intend to eventually unify the DebugEvaluate and Scope objects),
          and
      (b) the wasm-js.cc file is explicitly about the WebAssembly JS API
          that's part of the WebAssembly specification, and the DebugEvaluate
          proxies aren't part of that.
      
      Bug: chromium:1162229, chromium:1071432, chromium:1127914
      Change-Id: I63016dcace6d8e2af4a03c8eed4f02d464c1dee1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609418
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71911}
      5fc4649d
  19. 29 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [wasm][debug] Expose instance and module instead of imports / exports. · ad42f966
      Benedikt Meurer authored
      The "imports" and "exports" that were exposed on WebAssembly frames via
      Debug-Evaluate aren't useful for the DWARF C/C++ extension (and likely
      not for any other language extension), since they only expose static
      information that's easily available (upfront) by reading the Wasm wire
      bytes.
      
      In fact, there are already standardized functions in the WebAssembly
      specification, namely `WebAssembly.Module.imports(module)` and
      `WebAssembly.Module.exports(module)`, which yield static information
      about the imports and exports of a Wasm module.
      
      So instead of exposing special, non-standard "imports" and "exports", we
      now instead expose both the "instance" and the "module" objects via both
      the Debug Proxy and the Scope view, and also add internal [[Exports]]
      and [[Imports]] properties to WasmModuleObject, which under the hood use
      the standard methods mentioned above.
      
      Fixed: chromium:1162069
      Bug: chromium:1071432, chromium:1083146
      Screenshot: https://imgur.com/lcaW2jL.png
      Doc: https://docs.google.com/document/d/1rqbu0jKTl3q_xCxLnKzkjGXWEsHnJ9aERVhKV9RNDgE#bookmark=id.925bb2qgou38
      Change-Id: Ie27e55bb08ea5f90493c57375bf2b48dfb11a4d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606050
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71893}
      ad42f966
  20. 03 Dec, 2020 1 commit
  21. 30 Nov, 2020 1 commit
  22. 19 Nov, 2020 1 commit
  23. 17 Nov, 2020 1 commit
  24. 11 Nov, 2020 2 commits
  25. 06 Nov, 2020 1 commit
  26. 06 Oct, 2020 2 commits
  27. 05 Oct, 2020 1 commit
  28. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove --wasm-max-mem-pages-growth flag · 5f265c33
      Clemens Backes authored
      This unifies {max_initial_mem_pages} and {max_maximum_mem_pages} into
      {max_mem_pages}.
      The {CompilationEnv} constructor was incorrectly using the former
      instead of the latter anyway. This did not really matter though, since
      they typically have the same value.
      Also, there is not a single test that sets --wasm-max-mem-pages-growth.
      
      R=manoskouk@chromium.org
      CC=jkummerow@chromium.org
      
      Bug: v8:10949
      Change-Id: Ib7ab9b4c239d50b72013087eda5a214829c90369
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426619Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70114}
      5f265c33
  29. 21 Sep, 2020 1 commit
  30. 18 Sep, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Preparation for typed function tables · a5f68abe
      Manos Koukoutos authored
      Changes:
      - Rename IsSignatureEqual -> MatchesSignature for consistency
      - Add WasmInstanceObject field to WasmTableObject.
      - Improve some error messages related to tables in
        function-body-decoder-impl.h.
      - Introduce WasmTable::IsValidTableType. Use it wherever appropriate.
      - Overload equality operators in HeapType to work with
        HeapType::Representation.
      - Rename DynamicTypeCheckRef -> TypecheckJSObject.
      - Handle WasmCapiFunctions in TypecheckJSObject.
      - Use TypecheckJSObject in WasmTableObject::IsValidElement.
      - A few more minor improvements.
      
      Bug: v8:9495
      Change-Id: I2867dd3486d7c31717ac26b87a50e15cf2b898be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416491
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70001}
      a5f68abe
  31. 14 Sep, 2020 1 commit
  32. 06 Aug, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Check size of tables dynamically · 47434265
      Andreas Haas authored
      We used to check the size of tables at compile time, and threw a
      CompilationError if a given size exceeded the implementation-defined
      limit. However, the spec defines that an error should only be thrown
      when the implementation-defined limit is reached, which is either at
      instantiation time of during runtime at a table.grow.
      
      With this CL the V8 implementation becomes spec compliant in this
      regard.
      
      R=jkummerow@chromium.org
      
      Bug: v8:10556
      Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69267}
      47434265
  33. 03 Aug, 2020 1 commit
  34. 01 Jul, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm] Properly implement parsing of s33 values · 5df74c35
      Manos Koukoutos authored
      Motivation:
      We used to approximate s33/i33 value parsing by first checking for
      specific negative codes, and then parsing an u32 value if that failed.
      This is not correct in all cases.
      
      Changes:
      - Implement i33 parsing in Decoder.
      - Factor out parsing of heap types into read_heap_type.
      - Introduce HeapType::kBottom.
      - Introduce helper functions in WasmFeatures and value_type_reader.
      - Remove macros from the parsing of value types.
      - HeapType::code now returns an i32 for compatibility with the i33
        requirement.
      - Introduce HeapType::Repr.
      - Renamings: HeapType::type() -> representation(),
                   ValueType::heap() -> heap_representation()
      
      Bug: v8:7748
      Change-Id: I04deabce8837a48af2226411cd706a397f9e5725
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2274118
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68633}
      5df74c35
  35. 29 Jun, 2020 1 commit