WebAssembly / gc

Branch of the spec repo scoped to discussion of GC integration in WebAssembly
https://webassembly.github.io/gc/
Other
982 stars 70 forks source link

Effects of optimized out instructions #540

Closed yurydelendik closed 4 months ago

yurydelendik commented 4 months ago
local.get $loc
array.new_default $ar1
drop

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.

jakobkummerow commented 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.

rossberg commented 4 months ago

Since OOM is non-deterministic anyway it is always okay to not trap, i.e., to optimise an allocation away.

yurydelendik commented 4 months ago

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?

tlively commented 4 months ago

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.

yurydelendik commented 4 months ago

That pretty much answers the question. Thank you.