Owns every long-lived ETS table, and does nothing else.

The tables outlive the processes that use them. wasm_keeper's registry decides whether pages ever come back, wasm_engine's store holds every table's contents and every shared global's value, and wasm_code_slots' tables say which generated module names are in use. A server that created its own would take that state down with it on every restart and come back believing the node held nothing.

They used to belong to wasm_sup, which gave them the right lifetime against a child crash and the wrong one against anything else: the root supervisor is also the process every subsystem hangs off, so it is the process most likely to be restarted, and it took the registry with it. This module is the owner instead, so the tables survive any subsystem's supervisor being restarted, and wasm_sup goes back to supervising.

Why the heir is the supervisor

wasm_store_sup is named as each table's heir. It is found by name rather than passed in, because a supervisor registers its name before it starts any child, so it is already resolvable from here and there is nothing to thread through wasm_sup's child specs.

Naming it as heir means this process crashing hands the tables over rather than destroying them. The supervisor then owns them, which is exactly the arrangement that worked before, and the replacement wasm_store finds them already there: every ensure_* function it calls is a no-op on an existing table, so it simply leaves them where they are. There is no give-away dance and nothing to get wrong on the way back.

The cost is one "Supervisor received unexpected message" error report per transfer, because an OTP supervisor has no handle_info for ETS-TRANSFER. That is the right trade: this process holds tables and runs no logic, so it does not crash on its own, and one noisy report beats losing the node's resource accounting.

What it deliberately does not cover

Nothing inside a supervision tree survives the root of that tree dying. If wasm_sup goes, the heir goes with it and the tables go too. That case is made harmless rather than impossible, by wasm_keeper reconciling the page counter against the registry when it starts: a lost registry then reads as a clean reset instead of a permanent leak. See wasm_keeper:init/1.