- 06 Aug, 2020 1 commit
-
-
Andreas Haas authored
We used to check the size of tables at compile time, and threw a CompilationError if a given size exceeded the implementation-defined limit. However, the spec defines that an error should only be thrown when the implementation-defined limit is reached, which is either at instantiation time of during runtime at a table.grow. With this CL the V8 implementation becomes spec compliant in this regard. R=jkummerow@chromium.org Bug: v8:10556 Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69267}
-
- 16 Jun, 2020 1 commit
-
-
Manos Koukoutos authored
Changes: - Simplify and generalize ToValueTypeString. - Fix some error messages in msjunit so that they reflect the underlying error better. - Change 'exn' -> 'exnref' to match exception-handling proposal. Bug: v8:7581 Change-Id: I264f6c9aa598a57f39d5a4d01399af64db83a2b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243214 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68364}
-
- 12 Jun, 2020 1 commit
-
-
Andreas Haas authored
We want to enable the wasm-bigint implementation by default. However, at the moment there exist several tests which fail when wasm-bigint gets enabled. With this CL we adjust or delete these tests so that they pass once wasm-bigint gets enabled. At the same time we disable these tests for now, and re-enable them in the CL that flips the flag. R=jkummerow@chromium.org Bug: v8:7741 Change-Id: I733bfe7ff19e403913b143e6ea86ab13602ab993 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243212 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68328}
-
- 04 Dec, 2019 1 commit
-
-
Michael Starzinger authored
This fixes the operation functions (i.e. WebIDL interface member and namespace member operations) for WebAssembly to not have 'prototype' properties and not be marked as constructors. R=ahaas@chromium.org TEST=mjsunit/wasm/js-api BUG=chromium:1027945 Change-Id: I4db753a9ca570b95c45cb033c36de65bcafafe8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950483Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65329}
-
- 29 Nov, 2019 1 commit
-
-
Michael Starzinger authored
This fixes the accessor functions (getters and setters) for WebAssembly accessor properties to not have 'prototype' properties and not be marked as constructors. R=ahaas@chromium.org TEST=mjsunit/wasm/js-api BUG=chromium:1027945 Change-Id: I0288f511fee1f99997031b41354ecf7b8629b783 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943157 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#65265}
-
- 30 Apr, 2019 1 commit
-
-
Andreas Haas authored
This CL refactors WasmTableObject::Grow to make it usable for the table.grow instruction of WebAssembly. The refactored version of WasmTableObject::Grow does additionally: * Check if growing is possible * Grow the FixedArray backing store of the table and initialize the new fields. * Calculate the return value of WasmTableObject::Grow. R=jkummerow@chromium.org Bug: v8:7581 Change-Id: Ic6c867b96c30bd987ea281d5b3515a04bc5a3900 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588136 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#61112}
-
- 13 Mar, 2019 1 commit
-
-
Andreas Haas authored
This Cl adds a type to {WasmTableObject}, and extends {WasmTableObject::Set} and {WasmTableObject::Get} to support anyref tables. I did it in one CL so that I can write tests. R=mstarzinger@chromium.org Bug: v8:7581 Change-Id: I6c6d78f84715a7805f7bb881a63d3c1174f6a6ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511332Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#60206}
-
- 12 Mar, 2019 1 commit
-
-
Andreas Haas authored
According to the wasm js-spec, the table index can be uint32. The implementation in our implementation expected an int though. We did not check for the int overflow. I replaced the throwing of the exception in WasmTableObject::Get to use the ErrorThrower instead of throwing the exception with Isolate::Throw directly. The reason is that I see with other CL's that I have to throw several errors, and I don't want to introduce a new message and MessageId for every error. Moreover, the ErrorThrower is a standard way in wasm to throw errors. It feels right to throw the error the same way here. R=mstarzinger@chromium.org Bug: chromium:940296 Change-Id: Idb77c813506fe66a3192b66fe0e8e807b80580ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514496 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60181}
-
- 08 Mar, 2019 1 commit
-
-
Andreas Haas authored
We have to create WasmExportedFunction objects for any WebAssembly function which may escape a WebAssembly instance. Up until now we created these WasmExportedFunction objects eagerly during instantiation time: for any exported function, and any element in an exported table we create such an object. With the anyref proposal, the table.get instruction can allow any function in a table to escape its instance. Therefore we would have to create a WasmExportedFunction object for any function which is put into a table. With this CL we create WasmExportedFunctions for table entries lazily. We initialize tables with placeholders consisting of the instance and the function index. If we encounter a placeholder in table.get, we create the WasmExportedFunction for the expected function to return it. R=mstarzinger@chromium.org CC=titzer@chromium.org Bug: v8:7581 Change-Id: I4f32bd7433285d0b04a22c0fb70b736bac55b3f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505575Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#60115}
-
- 05 Mar, 2019 1 commit
-
-
Sven Sauleau authored
Align the Table implementation limits with the JavaScript Embedding limits defined in the specification (from MAX_UINT32 to 1e7). Introduce a new helper (max_table_init_entries) that returns the maximum number of Table entry at initialization. It takes into account the maximum Table size, which can be passed by a flag. Bug: v8:8633 Change-Id: Idfa19418e81f478f7886a30876e66c9b216e25ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496971 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#60036}
-
- 01 Mar, 2019 1 commit
-
-
Sven Sauleau authored
Replaces assertErrorMessage by assertThrows. Previously assertErrorMessage didn't assert the error message that was provided. Change-Id: I30410b43ff16db448776d9f3cae817b1c0966b3d Reviewed-on: https://chromium-review.googlesource.com/c/1496973Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Cr-Commit-Position: refs/heads/master@{#59982}
-
- 06 Feb, 2019 1 commit
-
-
Clemens Hammacher authored
We often use raw assertPromiseResult with {success == assertUnreachable} for that. Having a separate helper increases readability and allows us to generate consistent (and better) error messages. R=titzer@chromium.org Bug: chromium:926311 Change-Id: I507941eacaafe6c576098d7829a76b27384a4fb6 Reviewed-on: https://chromium-review.googlesource.com/c/1456039Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59417}
-
- 30 Jan, 2019 1 commit
-
-
Sven Sauleau authored
We noticed that almost every call site were loading both files, the split isn't necessary anymore. In some message tests, removed the absolute line number to allow future changes. Bug: v8:8726 Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545 Reviewed-on: https://chromium-review.googlesource.com/c/1446452 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59220}
-
- 22 Jan, 2019 1 commit
-
-
Sven Sauleau authored
Fix WebAssembly's memory/grow js-api. The argument is a unsigned long, this change refactors most of arithmetic and bounds checks type from int64 to uint32_t, according to the spec. Bug: v8:8319 Change-Id: I662c704d1d50288ad68be70c72a3db7052a80014 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1351028 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#59008}
-
- 19 Jan, 2019 1 commit
-
-
Sven Sauleau authored
Fix WebAssembly's table/get-set js-api. The argument is a unsigned long, this change refactors most of arithmetic and bounds checks type from int64 to uint32_t, according to the spec. Bug: v8:8319 Change-Id: I088f631c6805b0e5ba29089b08ea15e78fe5852d Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1414914Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Cr-Commit-Position: refs/heads/master@{#58941}
-
- 18 Jan, 2019 1 commit
-
-
Sven Sauleau authored
Fix WebAssembly's table/grow js-api. The argument is a unsigned long, this change refactors most of arithmetic and bounds checks type from int64 to uint32_t, according to the spec. Bug: v8:8319 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Change-Id: Ia29121c930d7fb930668e54a5a769dae25234f2c Reviewed-on: https://chromium-review.googlesource.com/c/1351006 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58936}
-
- 07 Jan, 2019 1 commit
-
-
Sven Sauleau authored
Fix WebAssembly's global/constructor js-api. Globals with a value of i64 is now valid even if Wasm BigInt feature isn't activated. Bug: v8:8319 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Change-Id: Ia41ad69efa5253064ecdb8f59b149393cd672b68 Reviewed-on: https://chromium-review.googlesource.com/c/1382747 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#58603}
-
- 10 Dec, 2018 1 commit
-
-
Sven Sauleau authored
Fix and re-enable tests for WebAssembly's memory/constructor and table/constructor js-api. It introduces the '[EnforceRange] unsigned long' algorithm used to validate initial and maximum properties. The initial property is now required, by the switch to the Web IDL specification. Most of the input validations errors are now considered TypeError instead of RangeError. The WasmTableObject and WasmMemoryObject APIs use more consistently uint32_t to ensure integer range and remove the need for bounds checks. Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Bug: v8:8319 Change-Id: Iedd3ee6484ef688a5e96f93006eb6ca66d805a48 Reviewed-on: https://chromium-review.googlesource.com/c/1354043 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58138}
-
- 07 Dec, 2018 1 commit
-
-
Sven Sauleau authored
This is a reland of 0e8f20d2 Original change's description: > [wasm] fix js-api interface > > Make sure WebAssembly's js-api exposes the correct attributes: writable, > enumerable and configurable. > > Bug: v8:8319 > Change-Id: I427533159d7975a42c0c5cb1babdc8a61f8198b5 > Reviewed-on: https://chromium-review.googlesource.com/c/1351002 > Commit-Queue: Adam Klein <adamk@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ben Smith <binji@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58053} Bug: v8:8319 Change-Id: I2d0af568edab295ad8c01b64e588bbabf89bd251 Reviewed-on: https://chromium-review.googlesource.com/c/1365273Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#58078}
-
- 06 Dec, 2018 1 commit
-
-
Clemens Hammacher authored
This reverts commit 0e8f20d2. Reason for revert: Breaks layout tests, blocks roll: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux-blink-rel/3047 Original change's description: > [wasm] fix js-api interface > > Make sure WebAssembly's js-api exposes the correct attributes: writable, > enumerable and configurable. > > Bug: v8:8319 > Change-Id: I427533159d7975a42c0c5cb1babdc8a61f8198b5 > Reviewed-on: https://chromium-review.googlesource.com/c/1351002 > Commit-Queue: Adam Klein <adamk@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ben Smith <binji@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58053} TBR=binji@chromium.org,adamk@chromium.org,gdeepti@chromium.org,ssauleau@igalia.com Change-Id: I16fa44a0e79020850613751ae45a68d67602166d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8319 Reviewed-on: https://chromium-review.googlesource.com/c/1365270Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58061}
-
- 05 Dec, 2018 1 commit
-
-
Sven Sauleau authored
Make sure WebAssembly's js-api exposes the correct attributes: writable, enumerable and configurable. Bug: v8:8319 Change-Id: I427533159d7975a42c0c5cb1babdc8a61f8198b5 Reviewed-on: https://chromium-review.googlesource.com/c/1351002 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ben Smith <binji@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#58053}
-
- 10 Oct, 2018 1 commit
-
-
Ben Smith authored
Use naming similar to the spec: "table" instead of "function table", "element segment" instead of "function table init". Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff Reviewed-on: https://chromium-review.googlesource.com/c/1273612 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56545}
-
- 20 Nov, 2017 1 commit
-
-
Brad Nelson authored
BUG=chromium:786021 R=titzer@chromium.org Change-Id: I188ea4d639ef9d5ceeab5052e043ec1c9150bd77 Reviewed-on: https://chromium-review.googlesource.com/778282Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#49506}
-
- 25 Oct, 2017 1 commit
-
-
Andreas Haas authored
This reverts commit 361bb1a0. Reason for revert: See https://crbug.com/v8/6981 BUG=v8:6981 Original change's description: > [test] Refactor assertPromiseResult > > This patch introduces assertPromiseFulfills and assertPromiseFulfills as > a replacement for assertPromiseResult because it’s more JavaScript-y. > > BUG=v8:6921 > R=ahaas@chromium.org > > Also-By: ahaas@chromium.org > Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31 > Reviewed-on: https://chromium-review.googlesource.com/718746 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48578} Change-Id: Ie760d2422451f16acc616aae001fe9fd18bf5cd4 Reviewed-on: https://chromium-review.googlesource.com/738249Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48936}
-
- 23 Oct, 2017 1 commit
-
-
Ben L. Titzer authored
R=rossberg@chromium.org Bug: chromium:772636 Change-Id: I885f8657eb755953be17d7bf32aef2629092b9c2 Reviewed-on: https://chromium-review.googlesource.com/733086Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48830}
-
- 16 Oct, 2017 1 commit
-
-
Mathias Bynens authored
This patch introduces assertPromiseFulfills and assertPromiseFulfills as a replacement for assertPromiseResult because it’s more JavaScript-y. BUG=v8:6921 R=ahaas@chromium.org Also-By: ahaas@chromium.org Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31 Reviewed-on: https://chromium-review.googlesource.com/718746 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48578}
-
- 09 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
Missing arguments are identical to undefined, and are converted to the integer 0 by ECMAScript {ToInteger()}. Add more tests, and enable previously disabled tests. There is a follow-up refactoring here: https://crrev.com/c/704586 R=titzer@chromium.org, mstarzinger@chromium.org Change-Id: I89cc259aaf5975ec2f6f51ff002e7d1b32adba5e Reviewed-on: https://chromium-review.googlesource.com/704658Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48373}
-
- 05 Sep, 2017 1 commit
-
-
Deepti Gandluri authored
BUG=v8:6749 R=titzer@chromium.org Change-Id: I4ac2ac8d8ca98d71dbc5a86c3cca268cd836997c Reviewed-on: https://chromium-review.googlesource.com/645146 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47837}
-
- 03 Aug, 2017 2 commits
-
-
Andreas Rossberg authored
R=titzer@chromium.org Bug: Change-Id: I2710aa5605bf2a26b6f86db98338dd54b6b87d2a Reviewed-on: https://chromium-review.googlesource.com/600235 Commit-Queue: Andreas Rossberg <rossberg@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47140}
-
Andreas Rossberg authored
R=titzer@chromium.org Bug: v8:5815 Change-Id: Ied267a431ed294f022628169e811069f2a4851b1 Reviewed-on: https://chromium-review.googlesource.com/599875 Commit-Queue: Andreas Rossberg <rossberg@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47133}
-
- 02 Aug, 2017 1 commit
-
-
Deepti Gandluri authored
R=ahaas@chromium.org BUG=v8:6546 Change-Id: I2808b78cd047d875d4530c86cc079488a78e5ea1 Reviewed-on: https://chromium-review.googlesource.com/557355 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#47088}
-
- 02 Jun, 2017 1 commit
-
-
Adam Klein authored
TBR=ishell@chromium.org Bug: v8:6457 Change-Id: I09d7d6ff8460688b7ddf25f733aea73a620db953 Reviewed-on: https://chromium-review.googlesource.com/523037Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#45699}
-
- 18 Apr, 2017 1 commit
-
-
mtrofin authored
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: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44669}
-
- 12 Apr, 2017 2 commits
-
-
hablich authored
Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ ) 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: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb TBR=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}
-
mtrofin authored
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}
-
- 11 Apr, 2017 1 commit
-
-
mtrofin authored
This also fixes an existing discrepancy. BUG=v8:6017 Review-Url: https://codereview.chromium.org/2808403002 Cr-Commit-Position: refs/heads/master@{#44590}
-
- 06 Apr, 2017 1 commit
-
-
Andreas Haas authored
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}
-
- 03 Apr, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 7a6e6bb1. Reason for revert: breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14688 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [wasm] Make WebAssembly.compile() asynchronous > > titzer@ originally created this > CL (https://codereview.chromium.org/2757903002). I fixed crashing tests > and adressed some comments of the reviewers. > > R=bradnelson@chromium.org, clemensh@chromium.org, mtrofin@chromium.org > BUG=v8:6003 > > Change-Id: I4ab6d503909402d24043657a896200032e6d1023 > Reviewed-on: https://chromium-review.googlesource.com/464887 > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44333} TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org,titzer@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6003 Change-Id: I87dbdbba0be4624828b6b0a94e02b6681593e335 Reviewed-on: https://chromium-review.googlesource.com/465813Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44342}
-
Andreas Haas authored
titzer@ originally created this CL (https://codereview.chromium.org/2757903002). I fixed crashing tests and adressed some comments of the reviewers. R=bradnelson@chromium.org, clemensh@chromium.org, mtrofin@chromium.org BUG=v8:6003 Change-Id: I4ab6d503909402d24043657a896200032e6d1023 Reviewed-on: https://chromium-review.googlesource.com/464887Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44333}
-
- 26 Jan, 2017 1 commit
-
-
gdeepti authored
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}
-