Skip to content

V
V8
Switch branch/tag
  1. 07 Nov, 2018 1 commit
  3. 05 Nov, 2018 2 commits
  5. 02 Nov, 2018 2 commits
    • Ross McIlroy's avatar
      Reland "Get BytecodeArray via current frame where possible." · 3530998c
      Ross McIlroy authored 
      This is a reland of 7350e7b2

Disabled LayoutTest that was causing issues and will rebaseline once this has rolled.

Original change's description:
> Get BytecodeArray via current frame where possible.
>
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
>
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
>
> BUG=v8:8395
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}

TBR=mythria@chromium.org

Bug: v8:8395
Change-Id: I63044138f876a1cdfb8bb71499732a257f30d29a
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314336Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57219}
      3530998c
    • Maya Lekova's avatar
      Revert "Get BytecodeArray via current frame where possible." · ea27a244
      Maya Lekova authored 
      This reverts commit 7350e7b2.

Reason for revert: Braking layout test, blocking the roll, see
https://bugs.chromium.org/p/v8/issues/detail?id=8405

Original change's description:
> Get BytecodeArray via current frame where possible.
> 
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
> 
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
> 
> BUG=v8:8395
> 
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}

TBR=rmcilroy@chromium.org,mythria@chromium.org

Change-Id: Ie5db0ec1d68ca01d62e9880a4476704ad4d013b5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8395
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314330Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57205}
      ea27a244
  7. 01 Nov, 2018 1 commit
    • Ross McIlroy's avatar
      Get BytecodeArray via current frame where possible. · 7350e7b2
      Ross McIlroy authored 
      With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
Instead of getting the bytecode array from the SFI, get it from the frame instead
(which is a strong pointer). Note: This won't actually change behaviour since the
fact that the bytecode array was on the frame will retain it strongly, however it
makes the contract that the BytecodeArray must exist at these points more explicit.

Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.

BUG=v8:8395

Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
Reviewed-on: https://chromium-review.googlesource.com/c/1310193
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57198}
      7350e7b2
  9. 26 Oct, 2018 2 commits
  11. 22 Oct, 2018 2 commits
  13. 12 Oct, 2018 1 commit
  15. 10 Oct, 2018 1 commit
    • Hai Dang's avatar
      Add iterator protectors for JSMapIterator/JSSet/JSSetIterator. · 60d3ce72
      Hai Dang authored 
      The MapIterator protector protects the original iteration behaviors of
Map.prototype.keys(), Map.prototype.values(), and Set.prototype.entries().
It does not protect the original iteration behavior of
Map.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
  %MapIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
  holder is the %IteratorPrototype%. Note that this also invalidates the
  SetIterator protector (see below).

The SetIterator protector protects the original iteration behavior of
Set.prototype.keys(), Set.prototype.values(), Set.prototype.entries(),
and Set.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
  %SetIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
  holder is the %SetPrototype% OR %IteratorPrototype%. This means that
  setting Symbol.iterator on a MapIterator object can also invalidate the
  SetIterator protector, and vice versa, setting Symbol.iterator on a
  SetIterator object can also invalidate the MapIterator. This is an over-
  approximation for the sake of simplicity.

Bug: v8:7980
Change-Id: I54ad6e4c7f19ccc27d7001f6c4b6c8d6ea4ee871
Reviewed-on: https://chromium-review.googlesource.com/c/1273102Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56530}
      60d3ce72
  17. 01 Oct, 2018 1 commit
  19. 17 Sep, 2018 4 commits
  21. 14 Sep, 2018 3 commits
  23. 13 Sep, 2018 1 commit
  25. 04 Sep, 2018 1 commit
  27. 28 Aug, 2018 1 commit
  29. 24 Aug, 2018 1 commit
  31. 23 Aug, 2018 1 commit
  33. 21 Aug, 2018 1 commit
  35. 17 Aug, 2018 1 commit
  37. 13 Aug, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Check the isolate if WebAssembly threads are enabled. · 1408e127
      Andreas Haas authored 
      With the origin trial for WebAssembly threads, threads can be turned on
and off by the embedder depending on the context we are currently in.
With this CL we call the embedder callback stored on the isolate to
determine whether threads are enabled in the current context or not.

Design decision:
I decided to extend the {WasmFeaturesFromIsolate} function to ask the
embedder if WebAssembly threads are enabled. This is the function which
defines dynamically which features are turned on. It would be awkward
to have two such functions, one which calls the embedder and one which
does not.
A downside is that in WasmJs::Install the embedder does not seem to be
ready to be called. That's why I changed the code there to call
{WasmFeaturesFromFlags} instead.

R=titzer@chromium.org, mstarzinger@chromium.org

Bug: chromium:868844
Change-Id: I6bfa89960a54cec71992756e3717bbb3a9fe195e
Reviewed-on: https://chromium-review.googlesource.com/1169180
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55076}
      1408e127
  39. 03 Aug, 2018 1 commit
  41. 01 Aug, 2018 1 commit
  43. 31 Jul, 2018 1 commit
  45. 23 Jul, 2018 1 commit
  47. 12 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [cleanup] Remove Isolate parameter from object print · 13b899a5
      Leszek Swirski authored 
      With ReadOnlyRoots and GetIsolate on JSReceiver, we can remove almost
every isolate parameter from <Object>::Print. The remaining ones, like
Map, are special-caseable for read-only maps, and as a result we can
remove isolate parameters from <Object>::Print entirely.

This patch also opportunistically cleans up a few places where isolates
were only needed for Object::Print, such as TransitionAccessors and
DescriptorArrays.

TBR=yangguo@chromium.org,mstarzinger@chromium.org

Bug: v8:7786
Change-Id: Id44bd53b9893e679eea5f37b9548257595a1bfd9
Reviewed-on: https://chromium-review.googlesource.com/1133385Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54401}
      13b899a5
  49. 10 Jul, 2018 1 commit
  51. 05 Jul, 2018 1 commit
  53. 03 Jul, 2018 1 commit
  55. 27 Jun, 2018 1 commit
  57. 26 Jun, 2018 1 commit
  59. 25 Jun, 2018 1 commit
  61. 22 Jun, 2018 1 commit