Fixed-length untyped arrays

Isiah Meadows isiahmeadows at
Sat Dec 22 02:52:45 UTC 2018

Usually, the native resizable array is good enough. But sometimes, you
don't want to resize it, just allocate a slab of memory for objects.
Typed arrays already implement this for integers, but I find it quite
often in certain applications that I want to do this for arbitrary
objects, too. So how about a `FixedArray` analogue to `TypedArray`
that implements most the same stuff `TypedArray` does, just without
the binary data integration or numeric coercion?

There's a few other benefits to having a native fixed-size untyped array:

1. Engines can make major assumptions about allocation and use that to
improve performance and minimize allocations - notably, they can
choose to allocate the array's entries in the object itself, since it
can't change for the lifetime of that object. This is the norm in some
languages, like Rust.
2. Engines can optimize things like `.map`, `.filter`, `.concat`, and
similar far more easily. Those don't have to be generic, and since
they can assume everything's contiguous, it's much easier to
3. Engines can make guarantees about allocation size, and that's the
whole point of this proposal. These objects only require a minimum of
type info, GC info, its length, and `length` number of machine

Of course, yes, normal arrays *could* provide most of these, but
consider how V8 internally uses an `InternalArray` extensively to
implement many JS built-ins in JS and its CodeStubAssembler DSL. It's
also worth noting V8 didn't start inlining `` and
friends for dense arrays until it figured out how to bail out of a
JIT-compiled loop from within that loop with negligible overhead (it
took an internal redesign), and no other engine I'm aware of performs
this optimization, either - it's all because JS's resizable arrays can
also be sparse.


Isiah Meadows
contact at

More information about the es-discuss mailing list