1. 07 Jul, 2017 1 commit
    • titzer's avatar
      [wasm] Introduce instance types for WebAssembly.* objects. · 17001a05
      titzer authored
      This CL refactors the internal representation of JavaScript-exposed
      WebAssembly objects to be more like other such objects in V8. By introducing
      a new instance type for each of the JS-exposed types, we get more robust
      typechecking without using embedder fields (which were previously used
      when these objects where instance type JS_API_OBJECT).
      
      In addition to the new instance types, the subclasses X of JSObject
      (WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
      now have appropriate Is##X() methods on Object and are now robust.
      
      BUG=v8:6547
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2964943002
      Cr-Commit-Position: refs/heads/master@{#46475}
      17001a05
  2. 22 Jun, 2017 1 commit
  3. 27 Apr, 2017 1 commit
  4. 04 Apr, 2017 1 commit
  5. 21 Mar, 2017 2 commits
    • mtrofin's avatar
      Reland of [wasm] Transferrable modules (patchset #1 id:1 of... · 9dfa4639
      mtrofin authored
      Reland of [wasm] Transferrable modules (patchset #1 id:1 of https://codereview.chromium.org/2762163002/ )
      
      Reason for revert:
      Temporarily disabled tests on chromium side (https://codereview.chromium.org/2764933002)
      
      Original issue's description:
      > Revert of [wasm] Transferrable modules (patchset #13 id:280001 of https://codereview.chromium.org/2748473004/ )
      >
      > Reason for revert:
      > Breaks layout tests:
      > https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14312
      >
      > See https://github.com/v8/v8/wiki/Blink-layout-tests
      >
      > Original issue's description:
      > > [wasm] Transferrable modules
      > >
      > > We want to restrict structured cloning in Chrome to:
      > > - postMessage senders and receivers that are co-located
      > > in the same process
      > > - indexedDB (just https).
      > >
      > > For context, on the Chrome side, we will achieve the postMessage part
      > > by using a mechanism similar to transferrables: the
      > > SerializedScriptValue will have a list of wasm modules, separate from
      > > the serialized data stream; and this list won't be copied cross
      > > process boundaries. The IDB part is achieved by explicitly opting in
      > > reading/writing to the serialization stream. To block attack vectors
      > > in IPC cases, the default for deserialization will be to expect data
      > > in the wasm transfers list.
      > >
      > > This change is the V8 side necessary to enabling this design. We
      > > introduce TransferrableModule, an opaque datatype exposed to the
      > > embedder. Internally, TransferrableModules are just serialized data,
      > > because we don't have a better mechanism, at the moment, for
      > > de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
      > > Context).
      > >
      > > The chrome defaults will be implemented in the
      > > serialization/deserialization delegates on that side. For the v8 side
      > > of things, in the absence of a serialization delegate, the V8
      > > serializer will write to serialization stream. In the absence of a
      > > deserialization delegate, the deserializer won't work. This asymmetry
      > > is intentional - it communicates to the embedder the need to make a
      > > policy decision, otherwise wasm serialization/deserialization won't
      > > work "out of the box".
      > >
      > > BUG=v8:6079
      > >
      > > Review-Url: https://codereview.chromium.org/2748473004
      > > Cr-Commit-Position: refs/heads/master@{#43955}
      > > Committed: https://chromium.googlesource.com/v8/v8/+/99743ad460ea5b9795ba9d70a074e75d7362a3d1
      >
      > TBR=jbroman@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
      > # Skipping CQ checks because original CL landed less than 1 days ago.
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > BUG=v8:6079
      >
      > Review-Url: https://codereview.chromium.org/2762163002
      > Cr-Commit-Position: refs/heads/master@{#43981}
      > Committed: https://chromium.googlesource.com/v8/v8/+/e538b70e1a45289dfe0fa9789563f023a5e9c22b
      
      TBR=jbroman@chromium.org,bradnelson@chromium.org,machenbach@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:6079
      
      Review-Url: https://codereview.chromium.org/2762273002
      Cr-Commit-Position: refs/heads/master@{#43994}
      9dfa4639
    • machenbach's avatar
      Revert of [wasm] Transferrable modules (patchset #13 id:280001 of... · e538b70e
      machenbach authored
      Revert of [wasm] Transferrable modules (patchset #13 id:280001 of https://codereview.chromium.org/2748473004/ )
      
      Reason for revert:
      Breaks layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14312
      
      See https://github.com/v8/v8/wiki/Blink-layout-tests
      
      Original issue's description:
      > [wasm] Transferrable modules
      >
      > We want to restrict structured cloning in Chrome to:
      > - postMessage senders and receivers that are co-located
      > in the same process
      > - indexedDB (just https).
      >
      > For context, on the Chrome side, we will achieve the postMessage part
      > by using a mechanism similar to transferrables: the
      > SerializedScriptValue will have a list of wasm modules, separate from
      > the serialized data stream; and this list won't be copied cross
      > process boundaries. The IDB part is achieved by explicitly opting in
      > reading/writing to the serialization stream. To block attack vectors
      > in IPC cases, the default for deserialization will be to expect data
      > in the wasm transfers list.
      >
      > This change is the V8 side necessary to enabling this design. We
      > introduce TransferrableModule, an opaque datatype exposed to the
      > embedder. Internally, TransferrableModules are just serialized data,
      > because we don't have a better mechanism, at the moment, for
      > de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
      > Context).
      >
      > The chrome defaults will be implemented in the
      > serialization/deserialization delegates on that side. For the v8 side
      > of things, in the absence of a serialization delegate, the V8
      > serializer will write to serialization stream. In the absence of a
      > deserialization delegate, the deserializer won't work. This asymmetry
      > is intentional - it communicates to the embedder the need to make a
      > policy decision, otherwise wasm serialization/deserialization won't
      > work "out of the box".
      >
      > BUG=v8:6079
      >
      > Review-Url: https://codereview.chromium.org/2748473004
      > Cr-Commit-Position: refs/heads/master@{#43955}
      > Committed: https://chromium.googlesource.com/v8/v8/+/99743ad460ea5b9795ba9d70a074e75d7362a3d1
      
      TBR=jbroman@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:6079
      
      Review-Url: https://codereview.chromium.org/2762163002
      Cr-Commit-Position: refs/heads/master@{#43981}
      e538b70e
  6. 20 Mar, 2017 1 commit
    • mtrofin's avatar
      [wasm] Transferrable modules · 99743ad4
      mtrofin authored
      We want to restrict structured cloning in Chrome to:
      - postMessage senders and receivers that are co-located
      in the same process
      - indexedDB (just https).
      
      For context, on the Chrome side, we will achieve the postMessage part
      by using a mechanism similar to transferrables: the
      SerializedScriptValue will have a list of wasm modules, separate from
      the serialized data stream; and this list won't be copied cross
      process boundaries. The IDB part is achieved by explicitly opting in
      reading/writing to the serialization stream. To block attack vectors
      in IPC cases, the default for deserialization will be to expect data
      in the wasm transfers list.
      
      This change is the V8 side necessary to enabling this design. We
      introduce TransferrableModule, an opaque datatype exposed to the
      embedder. Internally, TransferrableModules are just serialized data,
      because we don't have a better mechanism, at the moment, for
      de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
      Context).
      
      The chrome defaults will be implemented in the
      serialization/deserialization delegates on that side. For the v8 side
      of things, in the absence of a serialization delegate, the V8
      serializer will write to serialization stream. In the absence of a
      deserialization delegate, the deserializer won't work. This asymmetry
      is intentional - it communicates to the embedder the need to make a
      policy decision, otherwise wasm serialization/deserialization won't
      work "out of the box".
      
      BUG=v8:6079
      
      Review-Url: https://codereview.chromium.org/2748473004
      Cr-Commit-Position: refs/heads/master@{#43955}
      99743ad4
  7. 22 Feb, 2017 1 commit
  8. 17 Feb, 2017 1 commit
  9. 01 Feb, 2017 1 commit
  10. 28 Jan, 2017 1 commit
    • jbroman's avatar
      ValueSerializer: Support efficiently reading and writing one-byte strings. · bf511b42
      jbroman authored
      memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
      serializing and deserializing long ASCII strings, according to
      blink_perf.bindings -- and these are already in a fast path where the entire
      string is known to be ASCII (but this has to be checked). The win may be
      larger for strings in Latin-1 but not ASCII (though I suspect this is an
      uncommon case).
      
      A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
      survive wire format version number changes.
      
      This is the first of a series of wire format changes from the previous Blink
      format. The deserializer continues to be able to read the old format, but
      Chromium M56 will no longer be able to read the messages written by this, in M58.
      
      BUG=chromium:686159
      
      Review-Url: https://codereview.chromium.org/2658793004
      Cr-Commit-Position: refs/heads/master@{#42753}
      bf511b42
  11. 27 Jan, 2017 1 commit
  12. 03 Jan, 2017 1 commit
  13. 16 Dec, 2016 1 commit
  14. 15 Dec, 2016 1 commit
  15. 12 Nov, 2016 1 commit
  16. 04 Nov, 2016 1 commit
  17. 04 Oct, 2016 1 commit
  18. 20 Sep, 2016 1 commit
  19. 17 Sep, 2016 1 commit
  20. 14 Sep, 2016 3 commits
  21. 06 Sep, 2016 1 commit
  22. 02 Sep, 2016 1 commit
  23. 30 Aug, 2016 1 commit
  24. 29 Aug, 2016 1 commit
    • jbroman's avatar
      Blink-compatible serialization of array buffer views. · 248f3daf
      jbroman authored
      The format of this is a little strange, and has to do with the previous
      implementation maintaining a "stack" of objects as it works. As a result,
      the format writes the array buffer before giving any hint that the reason
      for doing so is to obtain a view wrapping it. Handling this without creating
      an explicit on-heap stack requires checking whether the next tag is 'V'
      after obtaining an array buffer.
      
      BUG=chromium:148757
      
      Review-Url: https://codereview.chromium.org/2287653002
      Cr-Commit-Position: refs/heads/master@{#38984}
      248f3daf
  25. 26 Aug, 2016 1 commit
  26. 25 Aug, 2016 2 commits
  27. 24 Aug, 2016 1 commit
  28. 23 Aug, 2016 2 commits
  29. 22 Aug, 2016 1 commit
  30. 18 Aug, 2016 3 commits
  31. 17 Aug, 2016 2 commits
    • jbroman's avatar
      Blink-compatible deserialization of old object format. · 058a7ee0
      jbroman authored
      The "version 0" format did not deal with references, and used a stack model to
      deserialize objects (conceptually, a postorder tree traversal). This requires
      an explicit stack, so special logic is added to decode this format.
      
      All subsequent versions also put an object marker at the beginning, which is
      equivalent to how the current version serializes.
      
      BUG=chromium:148757
      
      Review-Url: https://codereview.chromium.org/2248893003
      Cr-Commit-Position: refs/heads/master@{#38686}
      058a7ee0
    • jbroman's avatar
      Blink-compatible serialization of dictionary-like objects. · 1031a79f
      jbroman authored
      As part of this CL, object reference tracking is implemented (and tested with a
      self-referential object). This sort of reference tracking will be shared with
      other receivers (array, date, regexp and host objects).
      
      Not included in this CL is compatibility with version-0 objects (which don't
      support a non-tree object graph, and require a little stack to correctly
      deserialize).
      
      BUG=chromium:148757
      
      Review-Url: https://codereview.chromium.org/2246093003
      Cr-Commit-Position: refs/heads/master@{#38683}
      1031a79f
  32. 15 Aug, 2016 1 commit