TBR=ishell@chromium.org
Bug: v8:6457
Change-Id: I09d7d6ff8460688b7ddf25f733aea73a620db953
Reviewed-on: https://chromium-review.googlesource.com/523037
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45699}
Today, the semantics of:
WebAssembly.instantiate
and
WebAssembly.compile().then(new WebAssemblyInstance)
are subtly different, to the point where attempting the proposed
change uncovered bugs.
In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.
This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.
- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2806073002
Cr-Original-Commit-Position: refs/heads/master@{#44592}
Committed: 7829af3275
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44669}
Reason for revert:
Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824
Original issue's description:
> [wasm] instantiate expressed in terms of compile
>
> Today, the semantics of:
>
> WebAssembly.instantiate
>
> and
>
> WebAssembly.compile().then(new WebAssemblyInstance)
>
> are subtly different, to the point where attempting the proposed
> change uncovered bugs.
>
> In the future, it's possible that .instantiate actually have different
> semantics - if we pre-specialized to the provided ffi, for example.
> Right now that's not the case.
>
> This CL:
> - gets our implementation closer to what developers may write using
> the compile -> new Instance alternative, in particular wrt promise
> creation. By reusing code paths, we uncover more bugs, and keep
> maintenance cost lower.
>
> - it gives us the response-based WebAssembly.instantiate implicitly.
> Otherwise, we'd need that same implementation on the blink side. The
> negative is maintenance: imagine if the bugs I mentioned could only be
> found when running in Blink.
>
> BUG=chromium:697028
>
> Review-Url: https://codereview.chromium.org/2806073002
> Cr-Commit-Position: refs/heads/master@{#44592}
> Committed: 7829af3275TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2810203002
Cr-Commit-Position: refs/heads/master@{#44614}
Today, the semantics of:
WebAssembly.instantiate
and
WebAssembly.compile().then(new WebAssemblyInstance)
are subtly different, to the point where attempting the proposed
change uncovered bugs.
In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.
This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.
- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44592}
The following aspects were changed for the reland:
* The DeferredHandleScope is supposed with a specific pattern,
i.e. allocate handles in a normal HandleScope and then
reopen them in the DeferredHandleScope.
* Set the native_context when it is used in a task.
Change-Id: Ia42c46ec6bc73179cb1f458e36658414ff85cc23
Reviewed-on: https://chromium-review.googlesource.com/468809
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44434}
Memory.Grow should detach the ArrayBuffer associated with the Mem object after Grow. Currently, when guard pages are enabled protection is changed to make more of the buffer accessible. This does not work for when the buffer should be detached after grow, because the memory object has a reference to the same buffer befor/after grow.
R=titzer@chromium.org, eholk@chromium.org
Review-Url: https://codereview.chromium.org/2653183003
Cr-Commit-Position: refs/heads/master@{#42717}
- Currently WebAssembly.Memory.grow() assumes that it always has an instance associated with it,
fix to grow and reflect new size when no instance is associated with memory object.
- Correctness fixes for the js api, throw range errors instead of generic errors
BUG=chromium:680938
R=bradnelson@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2638243002
Cr-Commit-Position: refs/heads/master@{#42432}
- updated WebAssembly.Instance ctor uses in our tests to match spec
- disallowing mem section *and* mem import, as per spec
BUG=v8:5824
Review-Url: https://codereview.chromium.org/2627763002
Cr-Commit-Position: refs/heads/master@{#42278}
Also ensuring it is validation error to specify more than
one memory import.
BUG=v8:5824
Review-Url: https://codereview.chromium.org/2624853002
Cr-Commit-Position: refs/heads/master@{#42205}
