[spec] Should function instances point to the funcidx?

[littledan]

I'm trying to specify the WebAssembly/JS binding. Here, it would be useful to be able to get the funcidx from a function instance. However, the spec representation of a function instance short-circuits the lookup through the module and points straight to the func.

From an implementation perspective, jumping straight through doesn't present any problems since it will clearly be done with a pointer indirection either way. However, it's a little harder with the JS embedding. In particular, according to JS.md's instantiate algorithm, WebAssembly functions with the same "closure" should have a single, cached JS representation.

[[Closure]] is defined in JS.md as a (instance, funcidx) pair. However, I don't see how to get at that from the runtime structures.

If the funcidx isn't present, the JS binding would have to compare func values by identity. But the Wasm spec currently seems to take pains to make everything mathematical objects, where identity wouldn't mean anything. So I'd rather avoid that.

Any thoughts, or suggestions for doing things another way? @rossberg-chromium

[rossberg]

Sorry, JS.md is a bit incoherent right now, because it predates the spec. The part about [[Closure]] being a pair is outdated, it simply is a plain function instance now. I think all other uses of it are correct.

So you shouldn't need a funcidx. It never made much sense in the first place, since indices are local references to something, not identities.

[rossberg]

Actually, sorry, it should be a funcaddr, pointing to a function instance. That provides the global identity you need.

[littledan]

@rossberg-chromium

Sorry, JS.md is a bit incoherent right now, because it predates the spec.

No worries, rewriting JS.md to fix these issues is what I'm working on.

Actually, sorry, it should be a funcaddr, pointing to a function instance. That provides the global identity you need.

How should I refer to the store? funcaddr alone doesn't seem like enough, but from JS, it seems a little undefined to just say S or "the current store". The store is associated with a module instance? Should it be an internal slot in WebAssembly.Instance instances?

[rossberg]

The store is global to the engine, and represents its complete state. It's probably best to briefly explain and establish a suitable convention for referring to the WebAssembly store in some preliminary section in the API spec. The prose rules for Wasm execution do something similar. For the API, it's probably good enough to just say "the WebAssembly store", and linking that to the structurual definition in the core spec.

[rossberg]

PS: You'll likely need to refer to the store for other purposes as well, e.g., to allocate modules, host functions, memories, and tables, which all will have to be referenced by addresses.

[littledan]

Would different agent clusters have different stores?

[rossberg]

That could be modelled either way, but the trade-offs need investigating. I'd rather defer this question until we add them. For now it shouldn't matter.

[littledan]

@rossberg-chromium I'm not sure what you mean by for now. With the MVP shipped, you can already have different windows, for different origins, which many browsers will put in different processes. Should this be modelled in JS.md as all being the same global store?

[lukewagner]

The central point of an agent cluster is that it is the unit of host-environment-triggered killing (tab closing, oom-killer, slow-script-killing, etc) so that, within a single agent cluster, you don't have to worry about one thread getting killed (outside of your programmatic control) while another lives on. Thus, if we don't want to model host-environment-triggered killing in the core wasm spec--and I think we don't--I think we should associate the wasm universe (the store) with an agent cluster.

[binji]

I believe this is also important for being able to share linear memory between instances in separate agents; I'm not certain how this would work if they weren't in the same store.

[littledan]

OK, thanks for the clarification everybody. I'll write the JS.bs spec to use funcaddr for the value of [[Closure]]. For the store, I'll say something like "Each agent cluster is associated with a Wasm Store, referred to as S". No changes to the Wasm spec are needed.