Bug 178690 – WebAssembly: topEntryFrame on Wasm::Instance

• Component: WebAssembly
• Status: RESOLVED FIXED

[JF Bastien]

topEntryFrame is usually on VM, but for a no-VM WebAssembly we need to hold topEntryFrame elsewhere, and generated code cannot hard-code where topEntryFrame live. Do this at creation time of Wasm::Instance, and then generated code will just load from wherever Wasm::Instance was told topEntryFrame is. In a JavaScript embedding this is still from VM, so all of the unwinding machinery stays the same.

[JF Bastien]

Created attachment 324611 [details]
patch

[Saam Barati]

Comment on attachment 324611 [details]
patch

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

> Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h:137
> +    EntryFrame** m_topEntryFramePointer { nullptr };

Why have this in both JSWebAssemblyInstance and WasmInstance?

[JF Bastien]

(In reply to Saam Barati from comment #2)
> Comment on attachment 324611 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=324611&action=review
> 
> > Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h:137
> > +    EntryFrame** m_topEntryFramePointer { nullptr };
> 
> Why have this in both JSWebAssemblyInstance and WasmInstance?

JSWebAssemblyInstance copies a bunch of things from Wasm::Instance for now, because the goal I'm driving towards is having Wasm::Context be Wasm::Instance (not JSWebAssemblyInstance), and I want the swap to be as trivial as possible (i.e. change one line to do that swap, then delete all the copies from JSWebAssemblyInstance). If I do it right everything else will be the same.

[JF Bastien]

Created attachment 324613 [details]
patch

[WebKit Commit Bot]

Comment on attachment 324613 [details]
patch

Clearing flags on attachment: 324613

Committed r223866: <https://trac.webkit.org/changeset/223866>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Keith Miller]

I think this broke the windows build? https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/5466/steps/compile-webkit/logs/stdio

[WebKit Commit Bot]

Re-opened since this is blocked by bug 178699

[Keith Miller]

Committed r223875: <https://trac.webkit.org/changeset/223875>

[JF Bastien]

(In reply to Keith Miller from comment #7)
> I think this broke the windows build?
> https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/
> 5466/steps/compile-webkit/logs/stdio

lolwut?

[Radar WebKit Bug Importer]

<rdar://problem/35568509>