[runtime] Setup context data before instantiation or support closures

[evgenykuzyakov]

Currently, instance calls start_func automatically when created here https://github.com/wasmerio/wasmer/blob/master/lib/runtime-core/src/instance.rs#L69

Before calling start_func, I want to be able to modify Ctx by modifying .data first. Would be nice to move it out of Instance::new().

Context:
We are using gas meter injector that adds some runtime callback after every operation in wasm. I assume it also modifies start_func and inserts some gas meter calls there as well. Since ctx.data is null at this moment it fails with the following error: CallError(Runtime(Unknown { msg: "trap at 0x40 - segmentation violation" }))

[lachlansneff]

Hmm. I believe we'd be breaking the WebAssembly specification if we didn't automatically run the $start func. I'll think more about the upsides and downsides. We may be able to supply a way of setting the data before instantiation, or allow users to import closures that contain references to the outside state.

Would it be useful for your usecase if the runtime had explicit support for metering? It would likely have much less performance-impact than what you're doing now.

[evgenykuzyakov]

We may be able to supply a way of setting the data before instantiation, or allow users to import closures that contain references to the outside state.

Either way works for us. Supporting closures is cleaner, but as long as it doesn't affect performance.

Would it be useful for your usecase if the runtime had explicit support for metering? It would likely have much less performance-impact than what you're doing now.

That would be great. I think compute metering is the biggest overhead, because it requires context switching. Having it done by the runtime with some configuration that we can use would be huge perf boost. We can even receive it after entire execution if we could setup the limit beforehand.

[syrusakbary]

We are triaging stale issues now.

It seems, as commented in #219 we closed the PR in favor of the Import State changes from #299: 7b0992e.

So that should be the path forward. Let us know if you have other ideas.

Closing issue for now :)