Assumptions for public types under --closed-world

[stevenfontanella]

I spoke with @tlively following a discussion here and we're not sure about the assumptions we can make about references of public types under --closed-world. We came up with this table describing when references may originate from outside of the module and be passed into it:

Can a reference originate from outside our module?

	Public Type	Private Type
Open World	Yes	No
Closed World	?	No

For private types, open or closed world doesn't matter because even if the hosting environment creates a reference, there's no way for them to pass it to us. For closed world, the CLI help says this:

Assume code outside of the module does not inspect or interact with GC and function references, even if they are passed out. The outside may hold on to them and pass them back in, but not inspect their contents or call them.

Based on this, it sounds like a host environment would have no way of producing any kind of reference, even to a public type. If it did produce such a reference, it would be able to pass it to the module but it can't create one to begin with. It could instantiate an unrelated Wasm module that creates references, but it sounds like that would violate the assumptions of closed world. My thought based on this is that the answer is 'no' for public types in a closed world. Is that correct, or is it possible for references to originate outside of our module for public types in a closed world?

---

This is relevant for the indirect call support in GlobalEffects (#8609). We currently do analysis on indirect called types when --closed-world is enabled. But if we can't assume that references to public types must originate from our module in --closed-world, then it would be possible for the hosting environment to create their own function that then becomes a target of an indirect call of a public type, in which case we should give up and conservatively assume all effects for that type (meaning the analysis would be overly-optimistic and wrong today).

(Semi-related: in either case, there are some improvements that can be made for private types, since these can be reasoned about even in an open world)

[tlively]

My position is that we should answer "Yes" and assume that references with public types can be created and passed in from the outside, even in closed-world mode. That would mean that passes can have the same logic for open- and closed-world modes, and the difference between the modes will be fully encapsulated in the type visibility classification logic.

...but I'm not sure what the delta is between that vision for the future and our current state.

[kripken]

The current docs and code assume "no".

binaryen/src/pass.h

Lines 199 to 209 in 58e27a2

	// Assume code outside of the module does not inspect or interact with GC and
	// function references, with the goal of being able to aggressively optimize
	// all user-defined types. The outside may hold on to references and pass them
	// back in, but may not inspect their contents, call them, or reflect on their
	// types in any way.
	//
	// By default we do not make this assumption, and assume anything that escapes
	// to the outside may be inspected in detail, which prevents us from e.g.
	// changing the type of any value that may escape except by refining it (so we
	// can't remove or refine fields on an escaping struct type, for example,
	// unless the new type declares the original type as a supertype).

The goal, as mentioned there, is to allow aggressive optimization of our types. We don't list "produce" alongside "reflect", "inspect", and "call", but that is the idea.

In closed world, a type might be public because we pass it out, but as mentioned in the docs, that is only so the outside can "hold on to references and pass them back in".

With that said, if we have use cases, we might consider changing this?

[stevenfontanella]

I would think that 'no' is the better answer for us because it allows us to optimize more. I would worry that it might be common for a funcref to be public (e.g. via a table export), which would then hinder all optimizations that rely on private types (e.g. it would totally prevent us from analyzing effects for indirect calls in GlobalEffects).

So I think my preference is 'no' as long as it fits how our users are using --closed-world. If our users are on the same page, then it seems like the right way to go? It also seems like a common enough situation that users do not create references from outside of a given Wasm module.

[tlively]

I would worry that it might be common for a funcref to be public (e.g. via a table export), which would then hinder all optimizations that rely on private types (e.g. it would totally prevent us from analyzing effects for indirect calls in GlobalEffects).

But subtypes of types on the boundary are only considered public in open-world (after my current WIP fix), so this would not inhibit optimizations in closed-world.

If we encode all our assumptions into type visibility classifications, we can give users much more fine-grained control, especially if we add type visibility annotations and new visibility classifications in the future. When passes have to make decisions based on the open-world or closed-world modes configured via the command line, there's no space for nuance or control.