Expose non-exported instance globals for transactional embedders

[d-sonuga]

Feature

Add a public Rust API for enumerating all globals in a core Wasm instance, including globals that are not exported.

A possible API shape is:

impl Instance {
    pub fn globals<'a, T: 'static>(
        &'a self,
        store: impl Into<StoreContextMut<'a, T>>,
    ) -> impl ExactSizeIterator<Item = Global> + 'a;
}

The iterator should cover the instance's complete global index space:

• Imported and defined globals.
• Exported and non-exported globals.
• Mutable and immutable globals.

The API could be guarded by a lightweight, explicit configuration option such as:

let mut config = Config::new();
config.expose_instance_state(true);

Unlike Config::guest_debug, this option would only permit access to instance state. It would not require guest-debug instrumentation or retention of debugging information.
The names are suggestions; the important property is production access to all instance globals without enabling guest debugging.

Benefit

To enable an embedding runtime to provide transactional behavior.
Before an operation, the runtime records the current state of an instance. If the operation fails, the runtime restores the instance to its earlier state.

For example, suppose a global has the value 5 at the start of a transactional operation. The operation changes it to 77 and then fails. Correct rollback must restore the value to 5, rather than leave it at 77 or reset it to its initializer of 0.

The proposed API would allow an embedder to record and restore mutable global values using the existing Global interface.

[d-sonuga]

@alexcrichton

Would Wasmtime be open to an API like this? If yes, I wouldn't mind implementing.

[bjorn3]

This is a duplicate of #10156, right?

[alexcrichton]

Yes this is a duplicate of other issues we've had open from time-to-time about exposing internals. Wasmtime's stance hasn't changed on this in the meantime where it'll continue to be the case that, by default, internal private items in modules aren't exposed. What you can do @d-sonuga is postprocess the wasm to manually export all the globals, and then feed that wasm into Wasmtime, similar to what Wizer does.