- 18 May, 2018 2 commits
-
-
Clemens Hammacher authored
When processing imports of an instance, we were storing pointers to exported (and re-imported) wasm functions in the code table of the importing module. This is dangerous since imports are instance specific. Avoid ever storing call targets for imports in the NativeModule. Instead, read the call targets from the imports table of the instance. R=mstarzinger@chromium.org Bug: chromium:843563 Change-Id: Id9f43a6c127025a5feaa81b2be75c001bc0bea81 Reviewed-on: https://chromium-review.googlesource.com/1065774 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53256}
-
Clemens Hammacher authored
The js-to-wasm wrappers are shared across instances, so we cannot directly call the instance-specific wasm-to-js wrappers. Instead, we need to call via the import table. R=titzer@chromium.org Bug: chromium:843563 Change-Id: Ia882604f6769472fe2eb69176cbed728215ced29 Reviewed-on: https://chromium-review.googlesource.com/1064610Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53254}
-
- 17 May, 2018 1 commit
-
-
Clemens Hammacher authored
We need to change WasmExportedFunction to call imported functions via the import table, so there will be no embedded call target. This also removes the necessity to generate an unreachable call after the runtime call for js-incompatible signatures. R=titzer@chromium.org Bug: chromium:843563,v8:6668 Change-Id: I82cb31930f6b61ad59fde63a8c5ae631da3d1a14 Reviewed-on: https://chromium-review.googlesource.com/1063771 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53239}
-
- 15 May, 2018 3 commits
-
-
Clemens Hammacher authored
With the introduction of a jump table, call targets will not be {WasmCode} objects any more. Instead, we just call any {Address}. This CL does not change anything yet, but changes interfaces to accept an {Address} instead of {WasmCode*}. R=titzer@chromium.org Bug: v8:7758 Change-Id: Id299738bb7cc6a1891e4a03d7f67c24cde6d1699 Reviewed-on: https://chromium-review.googlesource.com/1058793 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53191}
-
Clemens Hammacher authored
We were always using the instance we were currently building. If the start function is an exported wasm function of another instance, use the exporting instance instead. R=titzer@chromium.org Bug: chromium:843120 Change-Id: I141d272b947bef8e903be7208ddf6ce344e754c4 Reviewed-on: https://chromium-review.googlesource.com/1059620 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53190}
-
Clemens Hammacher authored
{ImportedFunctionEntry} offers two {set} methods: One takes a {JSReceiver*}, the other one a {WasmInstanceObject*}. Since {WasmInstanceObject} inherits from {JSReceiver}, it's quite easy to confuse the two if the instance is hold as e.g. {JSObject}. Hence, rename the methods to remove this ambiguity. R=titzer@chromium.org Bug: v8:7758 Change-Id: I06617a565faa561d3afc70085e0df3b528c715bb Reviewed-on: https://chromium-review.googlesource.com/1059147Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53185}
-
- 14 May, 2018 2 commits
-
-
Michael Starzinger authored
This makes the fact that {WasmSharedModuleData} is shared across instances explicit by hanging this {shared} reference off the module object instead of the instance-specific {WasmCompiledModule} object. R=titzer@chromium.org Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I99bf3d855d6283bdc48373f0f8e2df1990905d3f Reviewed-on: https://chromium-review.googlesource.com/1051909 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53163}
-
Clemens Hammacher authored
Liftoff currently does not support all asm.js code, and tier-up does not work with lazy compilation. Hence, disable Liftoff for asm.js in general. We will look at this later, when we have better tier-up. R=titzer@chromium.org Bug: v8:6600 Change-Id: I00d9e27d861067b22c0738ade7070538ee8c919c Reviewed-on: https://chromium-review.googlesource.com/1047245Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53158}
-
- 11 May, 2018 1 commit
-
-
Michael Starzinger authored
This makes the fact that export wrapper code is shared across instances explicit by hanging the {export_wrappers} array off the module object instead of the instance-specific {WasmCompiledModule} object. R=titzer@chromium.org Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ic5c73bcc17f759e520c105317361e5654628b99e Reviewed-on: https://chromium-review.googlesource.com/1051987 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53131}
-
- 09 May, 2018 2 commits
-
-
Andreas Haas authored
The CompilationManager was introduced to manage the memory of AsyncCompileJobs. However, by now this can be done better by the new WasmEngine. This CL just moves the code to wasm-engine.[h,cc] and adjusts the callsites. R=titzer@chromium.org Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Icd2c1f19feeaa854c74e020b41e314b8ad00cea5 Reviewed-on: https://chromium-review.googlesource.com/1052109Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#53112}
-
Michael Starzinger authored
This makes sure that the {WasmModuleObject} has been allocated before any debug events are fired. Since {WasmScript} objects reference the module object, it needs to be allocated earlier by now. R=ahaas@chromium.org TEST=debugger/regress/regress-crbug-840288 BUG=chromium:840288 Change-Id: I02783ce126c463ac953eb2192acb65f3a5d420a1 Reviewed-on: https://chromium-review.googlesource.com/1050246Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53084}
-
- 08 May, 2018 3 commits
-
-
Michael Starzinger authored
This shares JS-to-Wasm wrapper code across instances belonging to the same module object. We no longer need to copy the wrappers since they are by now independent of the concrete instance. R=titzer@chromium.org BUG=v8:7424 Change-Id: I54188eae6378e53cc274cd19f8e652ffdba72ee5 Reviewed-on: https://chromium-review.googlesource.com/1049607 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53058}
-
Michael Starzinger authored
This changes JS-to-Wasm wrappers to no longer embed a WeakCell with the associated instance into the code, but load the instance object from the passed {WasmExportedFunction} object instead. R=titzer@chromium.org BUG=v8:7424 Change-Id: I5403f882912eb23e760fabe70207440648754a69 Reviewed-on: https://chromium-review.googlesource.com/1028053 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53057}
-
Clemens Hammacher authored
R=ahaas@chromium.org Bug: v8:7733 Change-Id: Ib3133e882c0a798f76478492a6663356267a1578 Reviewed-on: https://chromium-review.googlesource.com/1049546 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#53049}
-
- 07 May, 2018 2 commits
-
-
jgruber authored
Stubs and builtins are very similar. The main differences are that stubs can be parameterized and may be generated at runtime, whereas builtins are generated at mksnapshot-time and shipped with the snapshot (or embedded into the binary). My main motivation for these conversions is that we can generate faster calls and jumps to (embedded) builtins callees from (embedded) builtin callers. Instead of going through the builtins constants table indirection, we can simply do a pc-relative call/jump. This also unlocks other refactorings, e.g. removal of CallRuntimeDelayed. TBR=mlippautz@chromium.org Bug: v8:6666 Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53027}
-
Clemens Hammacher authored
Define simple accessors in the header and give them lower case names. R=mstarzinger@chromium.org Bug: v8:7570 Change-Id: I2914013fdea2218189275bbaa9f98ea5de0ccd7c Reviewed-on: https://chromium-review.googlesource.com/1046546 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53024}
-
- 04 May, 2018 3 commits
-
-
Michael Starzinger authored
This makes {Script} objects created for WebAssembly no longer reference a concrete instance object, but a module object instead. All uses of the field in question only require module-wide information and the script is meant to represent the set of all instances, not just one concrete instance. R=clemensh@chromium.org Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I751d4b75c8a970cffcb1a37b6c22ff69e9ee5489 Reviewed-on: https://chromium-review.googlesource.com/1043871Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53002}
-
Clemens Hammacher authored
The {baseline_compilation_units_} and {tiering_compilation_units_} fields should only be accessed if the {mutex_} is held. Also, the number of compilation units is already taken care of inside of {RestartBackgroundTasks}, so no need to explicitly pass it. R=ahaas@chromium.org Change-Id: I8f36ed141b587ee1bea41291545f39546d8cf24e Reviewed-on: https://chromium-review.googlesource.com/1044213Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52994}
-
Michael Starzinger authored
This is a reland of a0c57368 Original change's description: > [wasm] Maintain link from Instance to Module. > > This moves the link from a {WasmInstanceObject} to its corresponding > {WasmModuleObject} into the right place and also makes it strong. This > ensures that an instance always keeps the underlying module alive and > hence removes the situation of an "orphaned instance". > > R=clemensh@chromium.org > > Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944 > Reviewed-on: https://chromium-review.googlesource.com/1041691 > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52942} Change-Id: I9854400bfc1d22bd258f17118fcb7460cdc3acd5 Reviewed-on: https://chromium-review.googlesource.com/1043786Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52985}
-
- 03 May, 2018 3 commits
-
-
Michael Achenbach authored
This reverts commit a0c57368. Reason for revert: Speculative revert due to failures with custom snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/19061 Local bisect also points to this change: http://shortn/_IhVxU2FKLu Original change's description: > [wasm] Maintain link from Instance to Module. > > This moves the link from a {WasmInstanceObject} to its corresponding > {WasmModuleObject} into the right place and also makes it strong. This > ensures that an instance always keeps the underlying module alive and > hence removes the situation of an "orphaned instance". > > R=clemensh@chromium.org > > Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944 > Reviewed-on: https://chromium-review.googlesource.com/1041691 > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52942} TBR=mstarzinger@chromium.org,clemensh@chromium.org Change-Id: I1830e6ce14314f06f918a0c428182bfd68354ad9 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/1041968Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52949}
-
Michael Starzinger authored
This moves the link from a {WasmInstanceObject} to its corresponding {WasmModuleObject} into the right place and also makes it strong. This ensures that an instance always keeps the underlying module alive and hence removes the situation of an "orphaned instance". R=clemensh@chromium.org Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944 Reviewed-on: https://chromium-review.googlesource.com/1041691Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52942}
-
Ben L. Titzer authored
R=mstarzinger@chromium.org Change-Id: I57ff09601a9e84cc5b53ff06a446b7dfc3c026b2 Reviewed-on: https://chromium-review.googlesource.com/1032742Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52940}
-
- 02 May, 2018 1 commit
-
-
Eric Holk authored
This is a reland of ad221d14 Original change's description: > [wasm] Always enable guard regions on 64-bit platforms > > This change makes full 8 GiB guard regions always enabled on 64-bit > platforms. > > Additionally, since all Wasm memory allocation paths have some form of > guard regions, this removes and simplifies most of the logic around > whether to enable guard regions. > > This is a reland of https://crrev.com/c/985142. > > Bug: v8:7619 > Change-Id: I8bf1f86d6f89fd0bb2144431c7628f15a6b00ba0 > Reviewed-on: https://chromium-review.googlesource.com/996466 > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > Commit-Queue: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52412} Bug: v8:7619 Change-Id: I0f311305472ca2305ad2fa9163560ff54c1422c2 Reviewed-on: https://chromium-review.googlesource.com/999872 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#52921}
-
- 30 Apr, 2018 5 commits
-
-
Gabriel Charette authored
As discussed @ https://chromium-review.googlesource.com/c/chromium/src/+/957761#message-4ba6c1bf637f91507544efc89a31e3e4dd407715 and again @ https://chromium-review.googlesource.com/c/chromium/src/+/957761#message-6d0430e640c82f2d5463259fecdc7fabf945b958 Get rid of task runners for WorkerThreads API (use case is always a one-off task in which case a static call is fine -- just like in Chromium's base/task_scheduler/post_task.h) Calling into V8Platform* from any worker thread is safe, what was previously unsafe was using an Isolate* from worker threads but Isolate* was dropped from the new worker threads APIs so this is now irrelevant. Bug: chromium:817421 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Idd2dbc081edfbcb8985eeb45eb64ffb2555fcf7c Reviewed-on: https://chromium-review.googlesource.com/978443 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52893}
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:7424 Change-Id: I334d0521982e173650da7dd5da0627197dff171b Reviewed-on: https://chromium-review.googlesource.com/1035124 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52890}
-
Michael Starzinger authored
The predicate in question is specific to the code generated for a given module, hence specific to the {NativeModule} and independent of the instance. R=ahaas@chromium.org Change-Id: I108ee8126897ed732e8c52b549de170339a125a8 Reviewed-on: https://chromium-review.googlesource.com/1033741 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52886}
-
Michael Starzinger authored
This shares {NativeModule} and associated {WasmCode} objects across multiple WebAssembly instances in the same Isolate. It also removes support for cloning the aforementioned objects. R=clemensh@chromium.org BUG=v8:7424 Change-Id: I35334bd68f87e5871c244ee33dfcecb9da326b9f Reviewed-on: https://chromium-review.googlesource.com/1032780 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52877}
-
Marja Hölttä authored
BUG=v8:7490,v8:7570 Change-Id: I74fa43a747b0d399c700acc43eb82e15ea90ba16 Reviewed-on: https://chromium-review.googlesource.com/1032736Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52876}
-
- 27 Apr, 2018 7 commits
-
-
Ben Smith authored
* If the mutability of the global object doesn't match the module, then it should throw a LinkError. * There was a missing `return` when importing a Number as a mutable global. * All globals were being exported as immutable. * Attempting to set the value of an immutable global should throw a TypeError. * The length of the setter function should be 1. Bug: v8:7625 Change-Id: I08d6a428506a18db15eecadf4cbcee89e0658924 Reviewed-on: https://chromium-review.googlesource.com/1031626Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#52865}
-
Eric Holk authored
Bug: v8:7570 Change-Id: I90d9cb6c22c34017df2fd1613f3c94bb6a9afb52 Reviewed-on: https://chromium-review.googlesource.com/1033452Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52863}
-
Michael Starzinger authored
This removes the last reference from {NativeModule} that made it specific to a concrete WebAssembly instance, by only referencing the {WasmSharedModuleData} instead of a {WasmCompiledModule}. Note that eventually we want to remove this reference completely to become even independent of the underlying Isolate soon. R=clemensh@chromium.org BUG=v8:7424 Change-Id: I29b8cde8beadeef75c90e90fbff1830f2bf4e636 Reviewed-on: https://chromium-review.googlesource.com/1032433 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52853}
-
Ben L. Titzer authored
R=clemensh@chromium.org Change-Id: Iade16b07a24dca8ac542e68becad734d977b673a Reviewed-on: https://chromium-review.googlesource.com/1032778Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52852}
-
Clemens Hammacher authored
Linkage-related methods were declared in wasm-compiler.h and implemented in wasm-linkage.cc. This required all users of e.g. wasm call descriptors to include the whole wasm compiler header. Also, some wasm linkage information is independent of turbofan and also used outside of the compiler directory. This CL splits off wasm-linkage.h (with minimal includes) and puts it in src/wasm. This allows to use that information without including compiler headers (will clean up several uses in follow-up CLs). R=mstarzinger@chromium.org, titzer@chromium.org Bug: v8:7570 Change-Id: Ifcae70b4ea7932cda30953b325c2b87c4176c598 Reviewed-on: https://chromium-review.googlesource.com/1013701Reviewed-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@{#52849}
-
Ben L. Titzer authored
R=ahaas@chromium.org Bug: v8:7570 Change-Id: I5327d1b8e2f2bf4c1538f565442305a0e1f05b65 Reviewed-on: https://chromium-review.googlesource.com/1032550Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52835}
-
Ben L. Titzer authored
In the case of an indirect call to an imported function, the target instance stored in the IFT was actually wrong. Bug: chromium:834619 Change-Id: Id2ac4158335ecf2b58e1983ce37df852a9ebd1b2 Reviewed-on: https://chromium-review.googlesource.com/1030174 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52831}
-
- 26 Apr, 2018 3 commits
-
-
Kim-Anh Tran authored
Top-tier code needs to be explicitly logged after compilation. Change-Id: Ic3c54ff4b7bddd44516a611398b7373fe0acc8d4 Reviewed-on: https://chromium-review.googlesource.com/1030391Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@google.com> Cr-Commit-Position: refs/heads/master@{#52821}
-
Ben L. Titzer authored
This CL simplifies and extends the implementation of Managed<T> and now uses a std::shared_ptr<T> underneath in order to offer cross-isolate management of C++ allocated memory. R=mstarzinger@chromium.org CC=ulan@chromium.org Bug: v8:7424 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id43a26f565677e8c9cdfd73810568d4f2b1871fe Reviewed-on: https://chromium-review.googlesource.com/1028190Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52820}
-
Stephan Herhut authored
For wasm memory buffers, we normally require the memory to be allocated via WebAssembly.Memory, which will set a is_wasm_memory flag and register the memory with the wasm allocation tracker. This CL weakens that requirement in a DCHECK to allow for running experimental threaded applications even though the is_wasm_memory flag is not currently propagated via postMessage. Bug: chromium:836800 Change-Id: I4613b8651423307ce4cd466c0df28fc43244ec4f Reviewed-on: https://chromium-review.googlesource.com/1027813 Commit-Queue: Stephan Herhut <herhut@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#52801}
-
- 25 Apr, 2018 2 commits
-
-
Ben Smith authored
The WasmInstanceObject stores two new arrays: - imported_mutable_globals_buffers_: a FixedArray of all the imported globals' array buffers. - imported_mutable_globals: a calloc'd array of Addresses pointing to the mutable global in its array buffer. When accessing the global, the generated code looks up the address in imported_mutable_globals to find where to load/store. Bug: v8:7625 Change-Id: I60844c21a788fce28f346455f10f2283d1c152e9 Reviewed-on: https://chromium-review.googlesource.com/1020602 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52794}
-
Ben Smith authored
The mutable-globals proposal spec allows importing as Numbers or WebAssembly.Global values, but always exports as WebAssembly.Global. Since the value is always boxed, we can also import/export i64 values. This CL also includes support for export of mutable globals. Since the underlying ArrayBuffer that stores the global's value is shared between the module and the WebAssembly.Global object, all that needs to be done is remove the validation check. Bug: v8:7625 Change-Id: I24d763e3bc193d229a7cc33b2f2690a473c6f2bc Reviewed-on: https://chromium-review.googlesource.com/1018406 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52789}
-