865523 - Optimize the ARM asm.js heap access by using the Saturate instruction.

Status: RESOLVED WONTFIX

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

Description

[Douglas Crosher [:dougc]]

The ARM 'saturate' (SSAT) instruction, along with memory protection
of a region beyond the buffer, might be an alternative to the current
'shift/test and conditional instructions' used for asm.js heap access.

This could potentially reduce the heap store instruction sequence
by one instruction, and it would be interesting to know the performance
difference.

A performance comparison of this alternative instruction sequences
should be easy to obtain before even implementing the buffer
memory management.

Comment 1

[Douglas Crosher [:dougc]]

I have no plans to explore this.  The currently bounds check approach is more flexible.

Comment 2

[Luke Wagner [:luke]]

Out of curiosity, did you ever measure this?  On the one hand, it's 1 less instruction, on the other, conditional instructions might be cheaper.

Comment 3

[Douglas Crosher [:dougc]]

Reopened as there is still interest in comparing the speed of the 2 instruction store to a 3 instruction store sequence, see comment 2.  Note this bug deals with a slow path optimization, and I suggest it is low priority.

If the heap length is 2^n then a 2^n guard region would be needed after the end of the heap.  This would not consume resident memory but would double the address space used to 2^(n+1).

If the signed-saturate SSAT instruction were used then a negative 2^(n+1) sized guard would need to be placed before the start of the heap, and this is now possible thanks to bug 979480.  While this would not consume resident memory it would again double the area of address space needed for the heap.

A 2^n sized heap buffer would need a 2^(n+2) sized area of the address space, and address space is a precious resource on 32 bit builds.

The Odin implementation currently supports a range of non 2^n heap sizes and this could allow more efficient use of address space.  Only the last page in a 2^n size region needs to be protected to catch the saturated out-of-bounds heap accesses, so the heap buffer could potentially be 2^n-p where p is the page size.   However such heap sizes do not work well with index masking for which a 2^n+p sized heap is more efficient.  Further this still requires a large pre-heap guard zone.

The bug was closed as it did not seem appropriate to design Odin around the constraints of the ARM SSAT instruction, just to potentially optimize a slow path, but there appears to be lingering interest so it has been reopened, but I am not planning to explore this.

Comment 4

[Luke Wagner [:luke]]

Yes, the address-space usage problems are probably the most significant issue.  I guess when Emscripten code is emitted with explicit masking (a[b&c]) we already derive the main benefits we'd get from ssat anyway.

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.