1. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  2. 21 May, 2019 1 commit
  3. 12 Dec, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Group anyref parameter · 9f3c996d
      Andreas Haas authored
      To allow any-ref parameters, we have to make sure that any-ref stack
      parameters get seen by the GC. This CL is a first step into that
      direction. The goal of this CL is to group any-ref parameters at the
      stack side of the parameters. This means that in the stack frame
      iterator we do not need information about where anyref parameters are
      in the stack frame. We only need information about how many anyref
      parameters there are at the bottom of the stack frame.
      
      
      R=mstarzinger@chromium.org
      
      Also-By: mstarzinger@chromium.org
      Bug: v8:7581
      Change-Id: I3ff7cc38fabed5f8e51b5b990190e35f3ea29803
      Reviewed-on: https://chromium-review.googlesource.com/c/1371827
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58184}
      9f3c996d
  4. 04 Dec, 2018 1 commit
  5. 12 Jul, 2018 1 commit
  6. 03 May, 2018 1 commit
  7. 30 May, 2017 1 commit
  8. 16 Mar, 2017 1 commit
  9. 20 Feb, 2017 1 commit
    • clemensh's avatar
      [wasm] Add JSToWasmWrapperCache to reuse generated wrapper code · 7a91e3c6
      clemensh authored
      The generated code for JSToWasm wrappers only depends on the signature
      of the exported function. Hence, we can reuse the generated code and
      just patch the reference to the called wasm code.
      
      For the unity-wasm benchmark, we reach a hit rate of 98.07% for this
      cache, and only 395 instead of 20471 wrappers are compiled. This brings
      down instantiation time from 2.9s to 1.6s on a MBP.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2705993002
      Cr-Commit-Position: refs/heads/master@{#43322}
      7a91e3c6
  10. 19 Oct, 2016 1 commit
    • titzer's avatar
      [wasm] Use a Managed<WasmModule> to hold metadata about modules. · 418b239f
      titzer authored
      This CL refactors the handling of metadata associated with WebAssembly
      modules to reduce the duplicate marshalling of data from the C++ world
      to the JavaScript world. It does this by wrapping the C++ WasmModule*
      object in a Foreign that is rooted from the on-heap WasmCompiledModule
      (which is itself just a FixedArray). Upon serialization, the C++ object
      is ignored and the original WASM wire bytes are serialized. Upon
      deserialization, the C++ object is reconstituted by reparsing the bytes.
      
      This is motivated by increasing complications in implementing the JS
      API, in particular WebAssembly.Table, which must perform signature
      canonicalization across instances.
      
      Additionally, this CL implements the proper base + offset initialization
      behavior for tables.
      
      R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
      BUG=v8:5507, chromium:575167, chromium:657316
      
      Review-Url: https://chromiumcodereview.appspot.com/2424623002
      Cr-Commit-Position: refs/heads/master@{#40434}
      418b239f
  11. 20 Sep, 2016 1 commit
  12. 28 Jun, 2016 3 commits
    • mtrofin's avatar
      Revert "Revert "[wasm] Complete separation of compilation and instantiation"" · 9d6014ad
      mtrofin authored
      This reverts commit 1eb1dfab.
      
      The original compilation separation change avoided associating a heap
      for the wasm instance if memory was not provided, nor needed. The
      grow memory CL assumed the old behavior, where a memory buffer was
      always present, but may have had a zero size.
      
      The 2CLS  landed shortly after one another. We decided to treat the
      grow memory as the race condition winner, so this CL here re-lands
      compilation separation, plus adjusts grow memory to deal with
      the undefined mem buffer.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2102193003
      Cr-Commit-Position: refs/heads/master@{#37352}
      9d6014ad
    • mtrofin's avatar
      Revert "[wasm] Complete separation of compilation and instantiation" · 1eb1dfab
      mtrofin authored
      This reverts commit 0c7ee927.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2103983003
      Cr-Commit-Position: refs/heads/master@{#37351}
      1eb1dfab
    • mtrofin's avatar
      [wasm] Complete separation of compilation and instantiation · 0c7ee927
      mtrofin authored
      Support for serializing/deserializing the compiled wasm module.
      
      We want to reuse the javascript snapshotting mechanics, at least in the
      short term, when we still use the JS heap for the compiled wasm code.
      Given that a module may be compiled in one v8 instance and then
      instantiated later, in a different instance, whatever information we need
      at instantiation time must also be serializable.
      
      We currently hold on to the un-decoded wasm bytes, for enabling
      debugging scenarios. This imposes a ~20% penalty on the memory
      requirements of the wasm compiled code. We do not need this data
      otherwise, for runtime, and it is sensible to consider eventually loading it
      on demand. Therefore, I intentionally avoided relying on it and re-
      decoding the wasm module data, and instead saved the information
      necessary to support instantiation.
      
      Given how whatever we need to persist must be serializable, the CL
      uses a structure made out of serializable objects (fixed arrays mostly)
      for storing this information. I preferred going this route rather than
      adding more wasm-specific support to the serializer, given that we want
      to eventually move off the JS heap, and therefore the serializer.
      
      Additionally, it turns out this extra information is relatively not complex:
      minimal structure, little nesting depth, mostly simple data like numbers
      or byte blobs, or opaque data like compiled functions.
      
      This CL also moves export compilation ahead of instantiation time.
      
      This change added a helper getter to FixedArray, to make typed retrieval
      of elements easier.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2094563002
      Cr-Commit-Position: refs/heads/master@{#37348}
      0c7ee927
  13. 04 May, 2015 1 commit