[Webkit-unassigned] [Bug 149093] Implement calls to JavaScript functions in WebAssembly

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 14 22:54:32 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=149093

--- Comment #3 from Yusuke Suzuki <utatane.tea at gmail.com> ---
Comment on attachment 261064
  --> https://bugs.webkit.org/attachment.cgi?id=261064
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=261064&action=review

>> Source/JavaScriptCore/wasm/WASMModuleParser.cpp:53
>> +    : m_exec(exec)
> 
> We should avoid doing this.  ExecState* really means a frame pointer, so it's only valid during execution, and using it here can cause three other problems:
> 1) Impossible to make this code run concurrently.
> 2) Too easy to introduce user-observable effects.  We usually only pass around ExecState* when we're in a context where it's OK to have user-observed effects.
> 3) Too easy to make the parser impure - i.e. somehow dependent on the current state of the world.

Currently, in asm.js[1] and our WebAssembly implementation, we use the simple object as the set of the exported names.
So to look up the property from it, we need ExecState*... (I don't think adding new method getOwnPropertySlot(VM& ... ) to a lot of JSCell's derived class is good.)
But seeing the asm.js spec, it says that "all property access must resolve to data properties;".
So getOwnPropertySlot does not cause any observable effect if we check the slot with `slot.isValue()` and retrieve the value.
What do you think of

1. Not storing ExecState* to the member field. It's transient value, so storing to the member is not good. Passing it as the parameter is better.
2. Using getOwnPropertySlot and ExecState* and writing the comment about "The imported binding should be data property. We only retrieve the data property. So it does not cause any observable effect".
3. We should not use ExecState* except for getImportedValue.

And I believe this code will be replaced with the other one in the future, because

1. I believe that WebAssembly will be integrated into ES6 module loader. At that time, we don't use the object to link the functions. (currently, nothing about WebAssembly + Module is defined yet)
2. When the proxy is introduced, even `getOwnPropertySlot` becomes observable (Even [[HasProperty]] operation can throw errors!). So asm.js' linking semantics will be recasted. Or WebAssembly will replace  this semantics.

[1]: http://asmjs.org/spec/latest/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150915/c1db2889/attachment-0001.html>


More information about the webkit-unassigned mailing list