905512 - Odinmonkey: consider support for dynamic code linked to an common heap buffer

Status: RESOLVED WONTFIX

(Core :: JavaScript: WebAssembly, defect)

Description

[Douglas Crosher [:dougc]]

This bug is for discussing options for dynamic asm.js code to the extent that this might be possible.

One option might be to allow multiple chunks of asm.js compiled code to use the same heap buffer, and allow new asm.js code to be linked to an existing heap buffer.  This would allow adding new exported entry points to asm.js code using a given heap.  The newly added code could call into the existing code using the FFI infrastructure, and it might be possible to optimize such calls.

Each would need their own closure 'globals' area, but it might be possible to support this. The ARM backend currently dedicates a register to point to the 'globals' area.  State stored in the closure variables, that needs to be shared between closures, might need to be written to the heap, and read back, at calls between closures.

Another option might be to optimize re-compilation upon changes.  For example, if the source code has only a minor addition of new code then try to reuse existing compiled code when building the new code chunk.  A sub-set of changes that support efficient incremental re-compilation could be developed and defined.  Switching across to a new chunk of compiled code could be problematic, so this might be achieved by allowing both the new and old code to share the heap until there are no remaining uses of the old, and then GCing it.

Input welcomed!

Comment 1

[Luke Wagner [:luke]]

I might be missing one of your constraints but, right now, we can link multiple asm.js modules to the same ArrayBuffer.  The global data is stored as part of the AsmJSModule, so what is disallowed atm is linking a single asm.js module function to multiple ArrayBuffers, but that will be fixed in bug 900669 by cloning the AsmJSModule.

The remaining problem (which doesn't have great solutions atm) is function-pointer tables: they are local to a single module so if you have a C++ program that uses shared-objects and you want to compile each shared object (and the main executable) to separate asm.js modules, there is not a good way to have a unified function-pointer table so that you can pass function-pointers (i.e., indices into the table) between modules and call them.  Complicating this is that each module needs static knowledge of the size of the table (b/c func-ptr calls are written TBL[i&M](...).  Your ideas on this are welcome since I agree that, going forward, we probably want to support dynamic linking.

Comment 2

[Alon Zakai (:azakai)]

(In reply to Luke Wagner [:luke] from comment #1)
> I might be missing one of your constraints but, right now, we can link
> multiple asm.js modules to the same ArrayBuffer.

I assume this is what pypy.js does

http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/

Comment 3

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

Wasm allows sharing of function tables and memories, and we're not extending asm.js anymore at this point.