Read-only tables (and memories)

[lars-t-hansen]

Some of us were discussing alias analysis for a wasm compiler yesterday and it was observed that writing to a mutable global should not kill a value loaded from an immutable global.

This made me realize: we have multiple tables (introduced by the bulk memory proposal or reftypes, I'm not actually sure which) and table.fill and table.copy and table.get and table.set (introduced by the reftypes proposal), but so far as I can tell we have no immutable tables. If tables really are "generalized global variables", then perhaps we should, for symmetry. More importantly it would make it possible to export a table without fear of the table being tampered with.

Immutable tables must probably be initialized by an active element segment or from an imported immutable table, in the fashion of globals; this adds another wrinkle to our table initialization semantics puzzle.

(And once we have multiple memories, read-only memories will be attractive for some applications.)

[binji]

@sbc100 and I had discussed the value of having immutable tables before too.

[sbc100]

I believe @fgmccabe was interested in this too.

From the emscripten/llvm producer side tables have generally been considered read-only, but now that we are doing more dynamic linking we are adding table entries on the fly. Mostly this is done by the dynamic linker during startup before any user code runs, but we also do it in "dysym".

[sffc]

A read-only Memory would be desirable in order to first set up state in your Memory (initially read-write), and then create multiple Instances which all point to the same Memory (now read-only).

[harpocrates]

Immutable tables may also lead to more efficient call_indirect in the context of multiple threads. This is going to be more interesting with the threads proposal, but it is even sort of an issue today depending on your embedding decisions (since the host might mutate an exported table while the module is executing).

I ran into this in a WASM to JVM classfile compiler, where it is possible to further optimize call_indirect if the table is immutable. I may end up writing a pass over the module to identify tables that are definitely immutable (un-exported and never the target of table.set), but it would be much cleaner if this is the sort of thing that could be declared with the table and then validated.