1106851 - [meta] Avoid explicit error returns and checks during Ion compilation

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect, P5)

Description

[Brian Hackett [Laid off!]]

IonBuilder can only fail via OOM, by disabling the script, or to indicate a retry due to bad inlining or the new script properties analysis needing to be performed.  Other stages of Ion compilation can generally only fail via OOM.  The compiler uses a variety of error reporting strategies, though: setting OOM flags or other failure fields, using a ballast and failing if it can't be refilled, and explicitly returning failure codes.

It would be nice if this was cleaned up, by removing almost all explicit error returns and error checking in the compiler, and relying on failure fields in the builder or macro assembler for propagating failure.  The ballast would be used to allow compiler things like MIR definitions to be allocated infallibly, as they are now.

Comment 1

[Nicolas B. Pierron [:nbp — off until 29-09]]

From what I understand this is already the case, we use the ballast to make most allocations infallible, except that we still have to handle the ballast reallocation in case we are in loops which bounds are large or controlled by the user, and that failures are still reported as part of the returned value instead of a field … which should not change anything given that the error status still have to be checked after an allocation failure.