At run-time, we create a lot of stubs for various purposes: entry points into wasm from C++ and JS, exits from wasm to JS, indirect call trampolines, and builtin thunks. In the future there may be more, eg for func.bind if we get around to that, and it may be that call_ref requires a stub. Some of these are bulk-created on startup or instantiation, and some are created lazily.

The lazy stubs tend to be generated one-at-a-time and this incurs both significant expense and considerable memory overhead, since one code allocation quantum (the system page size) is needed for each stub even if the stub is small.

The lazy stubs will also currently be allocated to the start of a page and so will tend to conflict in the icache.

We sometimes generate too many stubs - better heuristics or better run-time adaptation could be used to reduce the volume.

Stub upgrade (when tiering up) is a headache and complex and we would like to do better.

We have discussed several ways to optimize stub allocation, these are some sketches:

• instead of stubs being allocated singly on a page with literal values baked in, they could be allocated many to a page, with literal data stored in a side table whose address is computable from the stub address itself. We would bulk-create and bulk-protect at least a pageful of stubs, and then we would allocate a new stub by just using one that's available after storing its payload data in the appropriate slot in the accompanying data page.
• lazy stubs could be bulk-created: when a lazy stub is needed, we store metadata about what we need somewhere but return a code pointer to a generic stub that will trigger bulk creation of all pending stubs when it is invoked.
• stub code could perhaps be created with the code it is for, and copied and specialized when it is needed (eg on instantiation).