957690 - Make small typed array creation blindingly fast

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Luke Wagner [:luke]]

We've made typed array element access really fast, but their creation is atrociously expensive in speed and memory.  A simple Float32Array(3) will have 7 reserved slots in addition to the 4 word header.  Even worse, creating a typed array view also immediately creates an ArrayBuffer which itself has a 4-word header followed by 16 reserved slots (meant to store small payloads).  So that's 260 bytes and 2 GC allocations, per Float32Array(3)!  As a final affront, the complexity of typed array construction makes it hard to inline creation from JIT code, so we have to call out to C++.

We've gotten lucky so far that typed arrays are primarily used in conjunction with Emscripten and WebGL which means big payloads (that amortize the header cost) and infrequent allocation.  However, it sounds like both V8 and JSC have already optimized heavily for the small-typed-array use case (see, e.g., [1]) so I expect it won't be long until we start hitting apps/benchmarks that pound on this because 'it ran great in Chrome' or Google added it to Octane.  Furthermore, small-object allocation is a primary, intended use of Typed Objects.

Broadly, I think we need to optimize for the case where a small typed array view is created and it's 'buffer' is never accessed.  This would allow us to:
 - lazily create the whole ArrayBuffer object (when .buffer is accessed)
 - avoid most of the reserved slots since they only apply to situations where there is a buffer
 - give ArrayBuffer objects 0 reserved slots since it's no longer the expected case for small arrays

With a bit more work it seems like we should also be able to squeeze out the remaining reserved slots and perhaps even reuse the 'elements' and 'slots' words of the object header by putting more of this information into the shape/type.  (I haven't really thought through all this, so I'm sure there be dragons.)

Lastly, given that bug 695438 will need to be fixed sooner or later, it might be good to include that in whatever refactoring plan we have here.

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-August/033023.html

Comment 1

[Jan de Mooij [:jandem]]

We also do a cx->currentScript(&pc) lookup when we create a typed array, and that's very slow for Ion callers. Ion could specialize this and not take that makeTypedInstance/UseNewTypeForInitializer path at all.

Comment 2

[Sander Mathijs van Veen]

Given https://dxr.mozilla.org/mozilla-central/rev/c2256ee8ae9a8ee0bf7ab49a8b1924720d846cc7/js/src/vm/TypedArrayObject.cpp#638, shouldn't this bug be marked as resolved/fixed?

Comment 3

[Luke Wagner [:luke]]

Definitely.