Non-nullability in the signature of `configureAll`

[tlively]

Currently the parameters to configureAll are all nullable references, following the convention of using nullable references in the inputs to core Wasm instructions. However, passing a null value for the prototypes, methods, or data array references is currently an error. We could make these parameters non-nullable if there were any benefit. (In contrast, passing a null value for the constructors object is fine if there are no configured constructors.)

Furthermore, both the prototypes array and methods array contain nullable references. It is an error for a method in the methods array to be null, but we currently allow null values in the prototypes array. Allowing null prototypes is maximally flexible but questionably useful, so we could make the elements of either or both of these arrays non-nullable as well. This is more likely to have a performance impact because this would let us elide many more null checks.

Actually using configureAll on the intended hot path (using array.new_elem) with non-nullable array elements would be blocked on Binaryen supporting non-nullable segment types, which we should probably do anyway (WebAssembly/binaryen#5628).

[sjrd]

In general, the difficulty with arrays of non-nullable elements is how to create them in the first place. When they have a fixed number of elements, it's fine. But if you're dynamically allocating an array of an arbitrary size before initializing it, it's tough. Of course, func is still kind of fine, because you can always cheat and put a unique dummy function reference on creation, before replacing it. But overall that's the reason APIs typically only use arrays of defaultable element types.

[jakobkummerow]

Regarding the parameters themselves being nullable: since we only check them once, the performance difference is trivial. Making them non-nullable would only serve to set expectations: anyone accidentally passing null there would get an error earlier, namely at validation time, rather than later at runtime.

Regarding the array elements being nullable: since those are many null checks, their cost adds up. I don't have hard numbers; I could try to benchmark it, but won't have time for that this week. Compared to the overall effort of configuring prototypes, I'd be surprised if it was a big difference; but even small performance overheads should be avoided unless the requirement for them can be justified.

One possible path forward might be to make the array elements non-nullable now (which would be a perfect fit for the primary motivating use case), and if that turns out to be too onerous for toolchains (for supporting secondary use cases, such as dynamic creation of types), then that could be a reason for introducing a configureOne variant in the future, whose reason to exist would then be that it's designed for flexibility rather than accepting the restrictions that lead to ultimate performance.