This reverts commit df8e617772.
Reason for revert: Multiple flakes in apparently related areas:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0
Original change's description:
> "Reland x3 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221,chromium:986318
> TBR=ulan@chromium.org
>
> Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63007}
TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org
Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221, chromium:986318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63011}
This is a reland of bc33f5aeba
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
TBR=ulan@chromium.org
Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63007}
Original CL:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and
WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only
used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray
instead of
> assuming the array was created with the correct size. This
simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule()
and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
R=ahaas@chromium.org, clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I03aa901a1df65af28f864d9aabe2b134ea132e99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724213
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62996}
This reverts commit 425fa3ae15.
Reason for revert: test failure https://bugs.chromium.org/p/v8/issues/detail?id=9554 reverting the root cause has merge conflicts due to changes in same file
Original change's description:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
> assuming the array was created with the correct size. This simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule() and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
TBR=binji@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I8dcad7ddcd4601f657b6263bf22009907284fce3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719230
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62926}
This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
The intent is to make the various ways of creating a module (sync,
async, deserialize, import) more similar.
After this change, a NativeModule will always be created before a
WasmModuleObject. This will make it easier to look up a cached
NativeModule given its wire bytes.
The following changes are made:
* Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
size estimate by default. A different code size estimate is only used in
tests.
* Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
assuming the array was created with the correct size. This simplifies
WasmModuleObject::New(), and matches what CompileToNativeModule()
does.
* Remove the WasmModuleObject::New() constructor that creates a
NativeModule. This case was only used in DeserializeNativeModule() and
in test code.
Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62925}
This reverts commit 306cf40344.
Reason for revert: performance regressions / too near branch point
TBR=mslekova@chromium.org
BUG=v8:9380
Change-Id: If77630b73eafbf1190c823199fe2a34361da303f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714867
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62867}
This is a reland of bc33f5aeba
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
Bug: v8:9380, v8:9221
Change-Id: I9a2525753ae2424108d074fa81df5f25d945c824
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62847}
This reverts commit bc33f5aeba.
Reason for revert: Still failing (OOM on win32): https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22210
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Iea755df9aaa1e95d284135bd0a6681b1340b6832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708487
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62811}
This is a reland of 31cd5d83d3
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
Bug: v8:9380, v8:9221
Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62809}
Even though this is not spec'ed yet, it's good to have an implementation
so that we can use clusterfuzz on it.
I changed the parameter order (hopefully) everywhere to
(table_dst_index, table_src_index, ...). This corresponds to the
(dst, src, ...) parameter order for the entry indices.
R=binji@chromium.org
Bug: v8:7581 chromium:980475
Change-Id: I2fb36ffd4bb2f2be5b22c8366732295fa6759236
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698386
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62661}
Even though this is not spec'ed yet, it's good to have an implementation
so that we can use clusterfuzz on it.
R=binji@chromium.org
Bug: v8:7581
Change-Id: I323625322e5240dc6ac224dce8a1f1f7f6070758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695478
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62656}
This fixes a corner-case where a {WasmExportedFunction} that represents
a re-export of a JavaScript callable from another module was identified
correctly, but not all corner-cases were correctly covered. Concretely
we failed to check for function signatures incompatible with JavaScript.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-9447
BUG=v8:9447
Change-Id: Ia6c73c82f4c1b9c357c08cde039be6af100727d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690941
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62632}
Change-Id: Ia506f4741e6ff9f024199d1b1fa7abb7dafe2b25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682835
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62581}
This reverts commit 31cd5d83d3.
Reason for revert: It breaks my heart to revert this, but it fails differently on several bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/26671.
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Ib35788ba8c31192d90cbc72df3dbc41030f109de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691034
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62578}
This CL completely rearchitects the ownership of array buffer backing stores,
consolidating ownership into a {BackingStore} C++ object that is tracked
throughout V8 using unique_ptr and shared_ptr where appropriate.
Overall, lifetime management is simpler and more explicit. The numerous
ways that array buffers were initialized have been streamlined to one
Attach() method on JSArrayBuffer. The array buffer tracker in the
GC implementation now manages std::shared_ptr<BackingStore> pointers,
and the construction and destruction of the BackingStore object itself
handles the underlying page or embedder-allocated memory.
The embedder API remains unchanged for now. We use the
v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
keep the backing store alive properly, even in the case of aliases
from live heap objects. Thus the embedder has a lower chance of making
a mistake. Long-term, we should move the embedder to a model where they
manage backing stores using shared_ptr to an opaque backing store object.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221
Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62572}
This is the combined second and third step of refactoring indirect
function calls through tables with index > 0 to work without runtime
calls.
The first CL introduces the WasmIndirectFunctionTable heap object. For
a table of type anyfunc within a WebAssembly instance,
WasmIndirectFunctionTable stores the size, the signature id's, the
call targets, and the reference parameters for that table. I used the
names that are already used for the matching fields of the
WasmInstanceObject.
The second CL expands the IndirectFunctionTableEntry to work also on
WasmIndirectFunctionTable objects. All changes to a function table go
through this class.
The third CL introduces uses of the WasmIndirectFunctionTable. In this
CL I change the code generation in TurboFan to replace runime calls with
direct accesses to the new WasmIndirectFunctionTable. Additionally I
extended the initialization of WasmIndirectFunctionTable, and also
implement Table.grow.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: Ic7615c0138562d27897683358ddc0943add1acfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684186
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62515}
This CL was generated by an automatic clang AST rewriter using this
matcher expression:
callExpr(
callee(
cxxMethodDecl(
hasName("operator->"),
ofClass(isSameOrDerivedFrom("v8::internal::Object"))
)
),
argumentCountIs(1)
)
The "->" at the expression location was then rewritten to ".".
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org
Bug: v8:9183, v8:3770
No-Try: true
No-Tree-Checks: true
Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61764}
Up until now, we cached export wrappers per export index. With the
anyref proposal potentially many more functions will need export
wrappers, e.g. any function that is stored in a table, and any
function accessed by the new ref.func instruction.
With this CL, we change the caching scheme an do the caching per
signature. Thereby we can guarantee that any export wrapper which
potentially exists can be stored in the cache.
For cctests which use wasm-run-utils, we don't know the size of the
cache anymore ahead of time. However, we assume that no more than
5 signatures will be used in any cctest. If this assumption is not
true, we can just adjust the number.
The cache is now accessed in all code paths where we need an export
wrapper.
Bug: chromium:962850
Change-Id: I32df60dfa7801d1e71f7d837da091f388198af1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615247
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61752}
I did the implementation with a runtime function. I extracted some code
from the implementation of table.get.
By accident I formatted anyfunc.js. However, since it's an improvement,
I don't want to undo it. I didn't change anything in the older tests
though, I only added new tests at the end.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I31832ccc817e1e7989f486d6487108c14d21bbea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1602701
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61442}
... to minimize pollution of v8::internal namespace.
This CL also removes usages of WriteBarrierKind from CodeAssembler interface.
Bug: v8:9183
Change-Id: I7e87c0a98cfd08b3740a022cf12d3aab415da67a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599176
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61301}
Our {Vector} template provides both {start} and {begin} methods. They
return exactly the same value. Since the {begin} method is needed for
iteration, and is also what standard containers provide, this CL
switches all uses of the {start} method to use {begin} instead.
Patchset 1 was auto-generated by using this clang AST matcher:
callExpr(
callee(
cxxMethodDecl(
hasName("start"),
ofClass(hasName("v8::internal::Vector")))
),
argumentCountIs(0))
Patchset 2 was created by running clang-format. Patchset 3 then
removes the now unused {Vector::start} method.
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
Bug: v8:9183
Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61081}
The wasm engine is the same for all units, thus we should store (or
get) it in the compilation task, and not store it duplicated in each
compilation unit.
R=mstarzinger@chromium.org
Bug: v8:8916, v8:8343
Change-Id: Id4b062b5b8a52228b4d6051a67e025088a61d466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559863
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60754}
This is a reland of 63608968b6
The previous CL failed on Windows, but it was a general bug. The
dropped_elem_segments was not being set on the instance properly in
cctests, so`table.init` instructions would fail by reading uninitialized
data.
I took this opportunity to also add an implementation of
`elem.drop` in the interpreter, and ported the JS tests for those too.
Original change's description:
> [wasm] Implement table.init for interpreter
>
> This also fixes CheckCallViaJS when a trap occurs. In that case, the
> trap callback is called instead of an exception being thrown, so if it
> isn't handled, a bogus result will be returned instead.
>
> Bug: v8:8965
> Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60473}
Bug: v8:8965
Change-Id: Ia547d9530b7ca67fde5bd94539f49153b796e82d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547142
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60664}
Locks for compilation state callbacks and for the native module are
again taken one after the other. As a consequence, publishing compiled
Wasm code again happens in parallel. Compile times are now comparable to
before lazy hints were enabled.
Bug: chromium:949050
Change-Id: I45c52254d046de080938bd131fd3ed8116660bef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552787
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60646}
This is a reland of 09fa63a935
Original change's description:
> [wasm-hints] Enabled Lazy Compilation by Hint
>
> Hints for lazy compilation are now taken into consideration. If the
> custom hints section suggests lazy compilatin we do so unless the module
> consists of a single function.
>
> Bug: v8:9003
> Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
> Commit-Queue: Frederik Gossen <frgossen@google.com>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60557}
Bug: v8:9003
No-Try: true
Change-Id: I8d6f4518aa548c815fba4e6e62d2206129336cc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547851
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60564}
This reverts commit 09fa63a935.
Reason for revert: Falkes on https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/29942
Original change's description:
> [wasm-hints] Enabled Lazy Compilation by Hint
>
> Hints for lazy compilation are now taken into consideration. If the
> custom hints section suggests lazy compilatin we do so unless the module
> consists of a single function.
>
> Bug: v8:9003
> Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
> Commit-Queue: Frederik Gossen <frgossen@google.com>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60557}
TBR=mstarzinger@chromium.org,clemensh@chromium.org,frgossen@google.com
Change-Id: I18dd424fe8cf05f220f7498bb1ebe4b9fce7d240
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9003
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547668
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60558}
Hints for lazy compilation are now taken into consideration. If the
custom hints section suggests lazy compilatin we do so unless the module
consists of a single function.
Bug: v8:9003
Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60557}
This reverts commit 63608968b6.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19535
Original change's description:
> [wasm] Implement table.init for interpreter
>
> This also fixes CheckCallViaJS when a trap occurs. In that case, the
> trap callback is called instead of an exception being thrown, so if it
> isn't handled, a bogus result will be returned instead.
>
> Bug: v8:8965
> Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60473}
TBR=binji@chromium.org,mstarzinger@chromium.org
Change-Id: Iee528ac2f16988b25579af3555e6f17974cb0b05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8965
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539498
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60474}
This also fixes CheckCallViaJS when a trap occurs. In that case, the
trap callback is called instead of an exception being thrown, so if it
isn't handled, a bogus result will be returned instead.
Bug: v8:8965
Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60473}
Both js-to-wasm-wrapper-cache-inl.h and wasm-import-wrapper-cache-inl.h
do not include any inl headers, thus they can be plain headers. If they
ever need to include inl headers again, we should split out the
respective functions into a separete inl header to follow the usual
pattern to have *both* a plain header *and* an inl header.
R=mstarzinger@chromium.org
Bug: v8:8834
Change-Id: I1b1b917a8e2c47f1354522479f8c57475bee6244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535826
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60431}
Most of the mjsunit/wasm/table-copy.js tests have been ported to
cctests, so they can be tested with all execution tiers.
Bug: v8:8965
Change-Id: I448719be30a4b2bddb9e2cffb4c74d3134db2f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529548
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60396}
The reason for the revert was that Liftoff did not bail out on indirect
calls to tables other than table 0. Whenever the Liftoff code got
executed, the test would fail.
Original message:
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.
The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: Iedd56ee7acb281441bca32ffd3dc7157203ee1ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532072
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60382}
When running wasm tests, the interpreter previously used a static
collection of function indexes stored in WasmTable to perform
call_indirect calls internal to that module. This has the wrong behavior
if the table is changed (via WasmTableObject::Set, `table.copy`, or
`table.init`).
This CL changes the cctests to always generate an intepreter entry for
all functions, and stores those entries in the dispatch table. This
allows us to use the same execution path as for non-testing code.
The interpreter entry compiler needed to be changed to support
multi-value returns too, since a 64-bit integer return value may be
lowered to two 32-bit integer returns.
Bug: v8:9016
Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60380}
This prepares a refactoring to add and publish compilation results in
batches. For this, we need to separate the two phases, so that we can
lock the module, allocate all the code space, release the lock, copy
the code, lock the module, publish the code, and release the lock
again.
In particular, this CL does the following:
1) It removes the {AddOwnedCode} method. The functionality of creating
the {WasmCode} and memcpy'ing the instruction into that is done in
the other {Add*Code} methods. Adding to {owned_code_} is done in
{PublishCode}.
2) {PublishInterpreterEntry} is now functionally equivalent to
{PublishCode}, so it's removed.
3) After {AddCode}, the caller has to call {PublishCode}. In a
follow-up CL, this will be called in batches (first {AddCode} them
all, then {PublishCode} them all).
4) {AddCompiledCode} now assumes that the {WasmCompilationResult}
succeeded. Otherwise, the caller should directly call {SetError} on
the {CompilationState}.
5) {PublishCode} is now the chokepoint for installing code to the code
table, the owned code vector, the jump table, and setting interpreter
redirections. It replaces previous direct calls to {InstallCode} or
explicitly adding to {owned_code_}.
6) Increasing the {generated_code_size_} counter is now done in
{AllocateForCode}, which is the chokepoint for allocating space for
generated code. This way, we will only increase this counter once
once we allocate in batches.
R=titzer@chromium.org
Bug: v8:8916
Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60369}
This reverts commit 9d167f57e0.
Reason for revert: There is a crash on https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20026
Original change's description:
> [wasm][anyref] Add support of call-indirect for multiple tables
>
> With this CL it is possible to use any anyfunc table in call-indirect,
> not just the first table.
>
> The current implementation is based on runtime calls. This is just an
> initial implementation which should be replaced by a
> dispatch-table-based eventually. However, this implementation allows
> us to move forward with the anyref proposal implementation.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7581
> Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60360}
TBR=mstarzinger@chromium.org,ahaas@chromium.org
Change-Id: Iba4b84078aa070498be7e79212970b94595f5757
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7581
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532069
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60362}
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.
The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60360}
This makes it easier to publish them in batches. Function index and
requested compilation tier are duplicated from the WasmCompilationUnit.
R=titzer@chromium.org
Bug: v8:8916
Change-Id: I87852670be029b1d729f98f01729362ca379fb50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529009
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60325}
This CL only provides the implementation of memory.{init,copy,fill} and
data.drop.
Bug: v8:8965
Change-Id: I439f2520bfee8f147e4b0d1d31f954aaad2e14ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510575
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60253}
Added a new compilation unit for Wasm interpreter in order to make it
a first-class tier in the future. Adapted Wasm interpreter usage to
work with the new interface. The new compilation unit is currently
not used.
Change-Id: Ib9e1d0dc6ca1b03467cc43059f03ce153bb96400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514734
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60183}
When using a shared WebAssembly.Memory, always try to reserve up to the
maximum to avoid having to move the buffer. If after multiple retries
it is not possible to reserve the maximum, fall back to initial size
reservation.
- Add new methods to allocate a Shared WebAssemblyMemory.buffer
- Use these to reserve upto the mazimum for a Shared WebAssembly.Memory
- Cleanup js-api so actual allocation is done inside the constructor
BUG: v8:8564
Change-Id: I97815c7c94a2b84416cd867fb23b3c815d7f0f12
Reviewed-on: https://chromium-review.googlesource.com/c/1480910
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59805}
This takes heap-inl.h out of the "Giant Include Cluster".
Naturally, that means adding a bunch of explicit includes
in a bunch of places that relied on transitively including
them before.
As of this patch, no header file outside src/heap/ includes
heap-inl.h.
Bug: v8:8562,v8:8499
Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4
Reviewed-on: https://chromium-review.googlesource.com/c/1459659
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59617}
When executing the interpreter, we should not try to create compiled
code. Otherwise we cannot implement and test a feature in the
interpreter in isolation.
R=ahaas@chromium.orgCC=fgm@chromium.org
Change-Id: I2074de31650a52b38b2f6e530e20b427d2d1db65
Reviewed-on: https://chromium-review.googlesource.com/c/1462876
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59493}
In some test-run-wasm-js cctests we want to call wasm code through the
js-to-wasm wrapper. This did not work if we wanted to run the wasm code
in the interpreter, because we never compiled a WasmInterpreterEntry,
and we did not patch the jump table.
With this CL we do both now.
R=clemensh@chromium.orgCC=fgm@chromium.org
Change-Id: I49971c5079053ed572928da7eab3e6ea3cb57c25
Reviewed-on: https://chromium-review.googlesource.com/c/1435941
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59170}
