Semantics for non-mutable globals

[kg]

From reading over the spec, it's not clear to me whether runtimes would be permitted to turn 'global.get' on a readonly global into an 'i32.const'. It doesn't seem like v8 applies this optimization either, so importing readonly globals as a way to approximate relocations/reconfiguration seems to come with a performance tax. Is this something the spec is meant to allow, or is it intended that a readonly global can change?

[rossberg]

The spec only defines observational behaviour, an engine can do whatever pleases it, as long as it does not change that behaviour.

The reason why engines cannot generally replace global.get with const for imports is the compilation/instantiation model: it simply doesn't know the value at compilation time, it's a parameter only supplied later by instantiations (and it can vary across instantiations). So yes, there's a cost to parameterisation.

[kg]

Right, but is the spec intended to specify that it shouldn't be possible to observe changes to the value? It seems to only specify that the wasm module is prohibited from modifying it. Whether or not the value is allowed to be changed by the host/engine would change which optimizations are valid around readonly globals.

[rossberg]

The spec imposes constraints on what the host can do:

• The host is expected to only interact with Wasm and its store through the embedder interface.
• In particular, the host must use a valid store for all operations.
• A host function call can only modify the store in certain ways. Concretely, the store must remain valid and it must be an extension of the existing store. The latter definition forbids mutation of immutable globals.

Of course, when a host bypasses the embedder interface and messes with the store directly, then all bets about transition consistency are off. In particular, there is nothing preventing it from using a valid store that it just made up, i.e., one that is not an extension of a previous store. Strictly speaking, it could "mutate" immutable globals between calls into Wasm that way. But of course, the spec cannot say anything about implementations not following the spec. :)

[kg]

• A host function call can only modify the store in certain ways. Concretely, the store must remain valid and it must be an extension of the existing store. The latter definition forbids mutation of immutable globals.

Thanks, that's the bit I was missing about the definition of a valid store! This at least means it would be possible to ask individual vendors for these optimizations, even if it turns out they can't provide them for other reasons.

[sunfishcode]

The question here seems answered; please file new issues if there are any further questions!