Skip to content

V
V8
Switch branch/tag
  1. 16 Oct, 2017 1 commit
  3. 10 Oct, 2017 1 commit
    • Eric Holk's avatar
      [wasm] Remove --wasm-guard-pages flag · 69d790e5
      Eric Holk authored 
      This flag was originally added as a staging mechanism to let us land and test
guard regions without the full trap handler feature landing. Additionally, we
thought we might enable guard regions without trap handlers on some systems.

Trap handlers are now supported, and there's not a real compelling reason for
why we need guard regions without trap handlers. Keeping the separate flag leads
to confusion, since some code treats guard regions and trap handlers the same,
while other code treats them as independent.

Removing this flag and its associated special cases makes everything more
uniform and predictable.

R=gdeepti@chromium.org

Change-Id: Icebab91d1f1e0c55e7a35c75b880085d37fa14ae
Reviewed-on: https://chromium-review.googlesource.com/706570Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48411}
      69d790e5
  5. 09 Oct, 2017 2 commits
  7. 06 Oct, 2017 2 commits
  9. 02 Oct, 2017 1 commit
  11. 28 Sep, 2017 1 commit
  13. 27 Sep, 2017 1 commit
  15. 11 Sep, 2017 1 commit
    • Deepti Gandluri's avatar
      [wasm] Memory.Grow with guard pages enabled should adjust memory allocated · 2aecded2
      Deepti Gandluri authored 
       - Memory.Grow with guard pages enabled should adjust amount of allocated
   memory, and not allocate a new buffer. This was disabled because previously
   the backing store was freed in the MemoryFinalizer, and we needed to be sure
   that the backing store is not released till the last buffer using it is
   released. This is now safe as we no longer use the MemoryFinalizer
 - SetProtection should use Guard/Unprotect that use mprotect underneath,
   instead of CommitRegion/UncommitRegion that use mmap
 - Move buffer allocation to the end to avoid inconsistent memory due to GC

BUG=v8:5886

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d7edb884bd1e3167eb5fbced6953c6401688d40
Reviewed-on: https://chromium-review.googlesource.com/629517Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47960}
      2aecded2
  17. 08 Sep, 2017 1 commit
  19. 04 Sep, 2017 1 commit
  21. 31 Aug, 2017 1 commit
  23. 28 Aug, 2017 1 commit
  25. 18 Aug, 2017 1 commit
  27. 03 Aug, 2017 5 commits
  29. 19 Jul, 2017 1 commit
  31. 13 Jul, 2017 1 commit
  33. 12 Jul, 2017 1 commit
  35. 10 Jul, 2017 2 commits
  37. 07 Jul, 2017 2 commits
    • titzer's avatar
      [wasm] Remove the use of private symbols for branding. · 01148639
      titzer authored 
      Instead, rely on the underlying instance types for WebAssembly.* types.

R=clemensh@chromium.org, rossberg@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2971093003
Cr-Commit-Position: refs/heads/master@{#46478}
      01148639
    • 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
  39. 05 Jul, 2017 1 commit
  41. 29 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Use pending exceptions consistently · d6aed443
      Clemens Hammacher authored 
      In our internal code, we should only use pending exceptions. They will
be converted to scheduled exceptions on the API boundary.
Hence, the ErrorThrower just sets a pending exception; it should never
have to think about scheduled exceptions. The new
ScheduledErrorThrower inherits from ErrorThrower and reschedules any
pending exceptions in its destructor (turning them into scheduled
exceptions).
In some situations, there might already be a scheduled exception, e.g.
when calling other API methods (v8::Value::Get). In this case, the
ErrorThrower should also not set another pending exception. For the
reasons mentioned above, this can only be handled in the
ScheduledErrorThrower, which is used the API methods.

This fixes one DCHECK failure and one TODO about scheduled exceptions
if no instance can be created, because the start function throws.

R=mtrofin@chromium.org, mstarzinger@chromium.org
BUG=v8:6232,chromium:736256

Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
Reviewed-on: https://chromium-review.googlesource.com/548641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46314}
      d6aed443
  43. 28 Jun, 2017 1 commit
  45. 20 Jun, 2017 1 commit
  47. 07 Jun, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Refactor Table.Set · 3a4ba583
      Andreas Haas authored 
      The old implementation of Table.Set in wasm-js.cc accessed information
which should be hidden from this level of abstraction, e.g. the internal
structure of a WasmTableObject. With this CL, all that is done in
wasm-js.cc is the extraction of parameters. The actual logic is happening
in wasm-module.{h|cc}. This CL will also make refactoring wasm-module.cc
easier.

R=clemensh@chromium.org, mtrofin@chromium.org

Change-Id: Ifbce6f739459dffc9f9d47e4cd8227638867f3e9
Reviewed-on: https://chromium-review.googlesource.com/525694
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45754}
      3a4ba583
  49. 06 Jun, 2017 1 commit
  51. 02 Jun, 2017 1 commit
  53. 24 May, 2017 2 commits
  55. 23 May, 2017 1 commit
  57. 18 May, 2017 1 commit
    • Mircea Trofin's avatar
      [wasm] {compile|instantiate}Streaming · 47702c53
      Mircea Trofin authored 
      As per spec, (https://github.com/WebAssembly/design/pull/1068), we
don't have compile/instantiate overloads anymore, instead, we
have explicitly named members.

This change introduces the new APIs, implements instantiateStreaming
based on compileStreaming, and uses the existing embedder mechanism.
It does not yet remove the functionality from compile/instantiate -
we do that after we adopt the new APIs on the blink side.

Also, it temporarily handles exceptions on the v8 side, which is also
something we'll move to the blink side.

Bug: 
Change-Id: I77673b1c0d395dfcf13b2f25464fd5dfd99c8d82
Reviewed-on: https://chromium-review.googlesource.com/508852
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45411}
      47702c53
  59. 10 May, 2017 1 commit
    • gdeepti's avatar
      [wasm] Do not unregister an ArrayBuffer if it is already external · e2fc979e
      gdeepti authored 
       - Currently if GrowMemory is called with pages = 0, an attempt is made to
   unregister the ArrayBuffer even if it is external. Cleanup so all Detaching
   of ArrayBuffer is centralized to one method, and can only be called fromJS.
 - Gate creating WeakHandles to the memory on the buffer having guard pages
   enabled. Currently creating a WeakHandle is gated only on if the buffer
   is_external true. If a buffer is marked is_external = true to begin with,
   the WeakHandle is created and the Finalizer is run causing the program to
   crash.

BUG=chromium:717647

Review-Url: https://codereview.chromium.org/2867233002
Cr-Commit-Position: refs/heads/master@{#45238}
      e2fc979e
  61. 05 May, 2017 1 commit