Linking

See Dynamic linking for an older discussion specifically of dynamic linking. This page replaces it.

Use cases

Static linking on the server

This lets people precompile libraries, so each build of their code does not rebuild everything. Also people can share built libraries easily.

Static linking on the client

This allows caching of libraries on the client, and linking them with code that is sent from the server that updates less frequently (and the result is then cached too).

Dynamic code loading on the client

dlopen, dlsym, etc. This is needed for things like Python loading modules are runtime, etc.

Order of importance

Open for debate, tentatively:

• Dynamic code loading
• Static linking on the server
• Static linking on the client

Approaches

Static linking

Can be done on client and server with C++ code. We should write a fast asm.js parser/unparser (and compile it to JS on the client). As a side benefit, the parser can be used in our JS optimizer passes.

The parser would ASTify the modules, then cleverly merge them together, adjusting colliding names, relocating global constants and function tables, and adjusting function table sizes.

We only merge the asm.js modules. The main file has all the JS library and shell, other code is just an asm.js module and nothing more.

This approach gives us one final merged asm.js module, which can then run at maximal speed.

Dynamic linking

We can do something similar to the old approach we had, that is still in the codebase (but deprecated - see old_shared_libs for where it still works). Basically, make shared libs slower in that they have named globals, relocation offsets in each function pointer use.

We would need to add logic to call a function pointer from another asm.js module, through trampolines.