1. 18 Dec, 2018 2 commits
  2. 08 Dec, 2018 1 commit
  3. 04 Dec, 2018 1 commit
  4. 30 Nov, 2018 1 commit
  5. 05 Nov, 2018 1 commit
  6. 17 Oct, 2018 1 commit
  7. 11 Oct, 2018 1 commit
  8. 23 Jul, 2018 1 commit
  9. 26 Jun, 2018 5 commits
    • Georg Neis's avatar
      Reland "Reland "Introduce MutableHeapNumber class."" · f1c79e02
      Georg Neis authored
      This is a reland of f0bcbc90.
      A few casts were still wrong.
      
      Original change's description:
      > Reland "Introduce MutableHeapNumber class."
      >
      > This is a reland of 40ac6b18, which
      > was incorrect due to a bad merge.
      >
      > Original change's description:
      > > Introduce MutableHeapNumber class.
      > >
      > > V8 knows heap numbers and mutable heap numbers. They have
      > > difference instance types, but in C++ code we've used the
      > > same class for both (HeapNumber). Confusingly, however,
      > > IsHeapNumber would return false for mutable heap numbers,
      > > while HeapNumber::cast would succeed.
      > >
      > > This CL adds a separate class MutableHeapNumber and
      > > eliminates the confusing behavior.
      > >
      [...]
      > TBR=bmeurer@chromium.org
      > TBR=ulan@chromium.org
      >
      > Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
      > Reviewed-on: https://chromium-review.googlesource.com/1114539
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54022}
      
      Change-Id: I19a33da4b6abcd445b528a84d4f56ba1964d337b
      Reviewed-on: https://chromium-review.googlesource.com/1114100
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54027}
      f1c79e02
    • Georg Neis's avatar
      Revert "Reland "Introduce MutableHeapNumber class."" · 722dfb70
      Georg Neis authored
      This reverts commit f0bcbc90.
      
      Reason for revert: Still failing bots.
      
      Original change's description:
      > Reland "Introduce MutableHeapNumber class."
      > 
      > This is a reland of 40ac6b18, which
      > was incorrect due to a bad merge.
      > 
      > Original change's description:
      > > Introduce MutableHeapNumber class.
      > >
      > > V8 knows heap numbers and mutable heap numbers. They have
      > > difference instance types, but in C++ code we've used the
      > > same class for both (HeapNumber). Confusingly, however,
      > > IsHeapNumber would return false for mutable heap numbers,
      > > while HeapNumber::cast would succeed.
      > >
      > > This CL adds a separate class MutableHeapNumber and
      > > eliminates the confusing behavior.
      > >
      > > TBR=bmeurer@chromium.org
      > >
      > > Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
      > > Reviewed-on: https://chromium-review.googlesource.com/1113544
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#54012}
      > 
      > TBR=bmeurer@chromium.org
      > TBR=ulanchromium.org
      > 
      > Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
      > Reviewed-on: https://chromium-review.googlesource.com/1114539
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54022}
      
      TBR=ulan@chromium.org,jarin@chromium.org,neis@chromium.org,bmeurer@chromium.org
      
      Change-Id: I99c226e95dfb0b913903cc83193f6e51de8c1b47
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/1114099Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54024}
      722dfb70
    • Georg Neis's avatar
      Reland "Introduce MutableHeapNumber class." · f0bcbc90
      Georg Neis authored
      This is a reland of 40ac6b18, which
      was incorrect due to a bad merge.
      
      Original change's description:
      > Introduce MutableHeapNumber class.
      >
      > V8 knows heap numbers and mutable heap numbers. They have
      > difference instance types, but in C++ code we've used the
      > same class for both (HeapNumber). Confusingly, however,
      > IsHeapNumber would return false for mutable heap numbers,
      > while HeapNumber::cast would succeed.
      >
      > This CL adds a separate class MutableHeapNumber and
      > eliminates the confusing behavior.
      >
      > TBR=bmeurer@chromium.org
      >
      > Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
      > Reviewed-on: https://chromium-review.googlesource.com/1113544
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54012}
      
      TBR=bmeurer@chromium.org
      TBR=ulanchromium.org
      
      Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
      Reviewed-on: https://chromium-review.googlesource.com/1114539Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54022}
      f0bcbc90
    • Yang Guo's avatar
      Revert "Introduce MutableHeapNumber class." · 983456f5
      Yang Guo authored
      This reverts commit 40ac6b18.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21009
      
      Original change's description:
      > Introduce MutableHeapNumber class.
      > 
      > V8 knows heap numbers and mutable heap numbers. They have
      > difference instance types, but in C++ code we've used the
      > same class for both (HeapNumber). Confusingly, however,
      > IsHeapNumber would return false for mutable heap numbers,
      > while HeapNumber::cast would succeed.
      > 
      > This CL adds a separate class MutableHeapNumber and
      > eliminates the confusing behavior.
      > 
      > TBR=bmeurer@chromium.org
      > 
      > Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
      > Reviewed-on: https://chromium-review.googlesource.com/1113544
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54012}
      
      TBR=ulan@chromium.org,jarin@chromium.org,neis@chromium.org,bmeurer@chromium.org
      
      Change-Id: I358a822f20b9110def968e69463a753a2a32c68c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/1114538Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54013}
      983456f5
    • Georg Neis's avatar
      Introduce MutableHeapNumber class. · 40ac6b18
      Georg Neis authored
      V8 knows heap numbers and mutable heap numbers. They have
      difference instance types, but in C++ code we've used the
      same class for both (HeapNumber). Confusingly, however,
      IsHeapNumber would return false for mutable heap numbers,
      while HeapNumber::cast would succeed.
      
      This CL adds a separate class MutableHeapNumber and
      eliminates the confusing behavior.
      
      TBR=bmeurer@chromium.org
      
      Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
      Reviewed-on: https://chromium-review.googlesource.com/1113544
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54012}
      40ac6b18
  10. 06 Apr, 2018 1 commit
  11. 08 Mar, 2018 3 commits
  12. 25 Jan, 2018 1 commit
    • Yang Guo's avatar
      Introduce SimpleNumberDictionary. · 3857b44e
      Yang Guo authored
      This is somewhat of a revival of what used to be
      UnseededNumberDictionary. The difference to NumberDictionary is that
      each entry only has two fields (no field for property details) and there
      is no header field for a bitfield.
      
      The reason for this change is memory regression introduced when we
      removed UnseededNumberDictionary (6e1c57ea). We now use
      SimpleNumberDictionary for
      - slow template instantiation cache
      - code stubs table
      - value serializer map
      - stack frame cache
      - type profile source positions
      
      R=ishell@chromium.org, ulan@chromium.org
      
      Bug: chromium:783695
      Change-Id: I3cd32e485060bb379fb2279eeefbbbded7455f0e
      Reviewed-on: https://chromium-review.googlesource.com/885811Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50869}
      3857b44e
  13. 18 Jan, 2018 1 commit
  14. 07 Nov, 2017 1 commit
  15. 20 Oct, 2017 1 commit
  16. 16 Oct, 2017 1 commit
  17. 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
  18. 22 Jun, 2017 1 commit
  19. 27 Apr, 2017 1 commit
  20. 04 Apr, 2017 1 commit
  21. 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
  22. 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
  23. 22 Feb, 2017 1 commit
  24. 17 Feb, 2017 1 commit
  25. 01 Feb, 2017 1 commit
  26. 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
  27. 27 Jan, 2017 1 commit
  28. 03 Jan, 2017 1 commit
  29. 16 Dec, 2016 1 commit
  30. 15 Dec, 2016 1 commit
  31. 12 Nov, 2016 1 commit
  32. 04 Nov, 2016 1 commit