Open Bug 1769767 Opened 3 years ago Updated 4 months ago

Stack results area is not re-used for wasm calls with Ion

Categories

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

defect

Tracking

()

People

(Reporter: rhunt, Unassigned)

References

(Blocks 1 open bug)

Details

A wasm call with more than one result will have extra results placed in a stack area owned by the caller. This space is allocated with LStackArea in Ion. From chatting with Julian and running a simple test case, it doesn't look like this space is reused between multiple calls with Ion.

Example:

(module
	(func (import "" "") (result i32 i32 i32 i32 i32 i32 i32 i32 i32 i32))
	(func
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
		call 0
		drop drop drop drop drop drop drop drop drop drop
	)
)

Adding a new call increases the stack size used with Ion, while baseline is able to re-use it.

This is not a correctness issue, we'll catch any stack overflow from excessive stack usage. But this may cause a stack overflow more frequently with very large functions.

The severity field is not set for this bug.
:sdetar, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)
Severity: N/A → S3
Flags: needinfo?(sdetar)

I noticed this issue while working on bug 1958280.

It's not trivial to fix because the LStackArea is a container for individual stack results with arbitrary lifetimes after the call, so we can't easily free the stack area.

To fix this I think we would change multi-value calls to load from the stack area into a register or stack slot after the call, so that the stack area is only live around that call. We could then track the largest stack area we need for the function, reserve just that size, and pass a pointer to that area for every multi-value call.

You need to log in before you can comment on or make changes to this bug.