Closed yurydelendik closed 4 months ago
Optimizations aren't supposed to be observable, so in V8 we make sure not to optimize out instructions that could trap. A sufficiently advanced compiler might replace the allocation with an IR construct that only (conditionally) traps and doesn't attempt to allocate; it's unclear to me how relevant such an optimization is in practice: presumably AOT optimizers like Binaryen will eliminate most unused allocations -- which they can do at least in traps-never-happen mode, which specifically allows application developers to tell their toolchain that situations like causing a trap via an unused allocation aren't load-bearing for the correctness of their app.
Since OOM is non-deterministic anyway it is always okay to not trap, i.e., to optimise an allocation away.
What if array.new_default
has platform/system dependent (deterministic) check in its implementation, e.g. check the size before the allocation. Do we need preserve the check in this case?
No, not from the point of view of the Wasm spec. The spec says:
If the runtime limits of an implementation are exceeded during execution of a computation, then it may terminate that computation and report an embedder-specific error to the invoking code.
Concrete limits are usually not fixed but may be dependent on specifics, interdependent, vary over time, or depend on other implementation- or embedder-specific situations or events.
OOMs are exceeded implementation limits, not part of the specified instruction semantics, so they fall into this catch-all bucket where the engine may or may not trap and whether it traps can depend on arbitrary implementation details, including optimizations.
If you want your engine to additionally provide the guarantee that optimizations will not affect OOM traps, then that's fine, but that goes beyond the guarantees made by the spec.
That pretty much answers the question. Thank you.
What will be a preferable way to optimize the execution from Wasm point of view: try to allocate/OOM; or just remove the instruction? I have the feeling it is the former, but I cannot find the clear confirmation in context of GC spec.