Opinions on resizable array buffers

[gbrail]

I've been digging in to all the options for resizable array buffers, starting with our current PR from @anivar:

#2182

(FWIW, I would like to merge the work done in that PR so far with some additional fixes and tweaks.)

The intention of resizable array buffers is to make it possible for JavaScript programmers to efficiently create buffers that start small and grow as needed. Since we're on the JVM we don't have all the same options that native code has to allocate native memory.

For background, a resizable ArrayBuffer has an initial size and a maximum size, and a "resize" operation that changes the current size. And being JavaScript, all this affects the various TypedArray classes in weird and amazingly complicated ways.

There are two rough directions:

1. Implement resize by allocating a new byte array of the new size and copying the bytes. This is what the current implementation does, and it's quite straightforward. The downsize is that if an app resizes a lot then we make a lot of copies.
2. Allocate a buffer of the maximum requested size when the buffer is created, and implement resize by changing a length parameter. This makes resize much more efficient, at the expense of memory.

I am curious if anyone has experience with this newish JavaScript feature in production. Do you think we should:

1. Not really "resize", but instead reallocate and copy on every "resize" operation?
2. Allocate the maximum size up front, with a default of around 1MB for the maximum and a configuration parameter to control it (this would allow folks in memory-constrained multi-tenant environments to prevent runaway memory usage)
3. Offer a configuration option to select between 1 and 2

[aardvark179]

Not a huge amount of experience with usage patterns in JS, but in general I would not recommend allocating the max size up front. The recommendation in the spec is that size should be somewhere round 1GB, and this would make accidental resource exhaustion very easy with multiple contexts. I would suggest following a similar strategy to things like array-list resizing. I.e. expanding by some set factor to take you above the requested size. This tends to minimise copying in the all too common case where the buffer is repeatedly expanded up to some value, and then remains stable, but won't blow out the memory budget too quickly.

[rbri]

I would suggest following a similar strategy to things like array-list resizing. I.e. expanding by some set factor to take you above the requested size. This tends to minimise copying in the all too common case where the buffer is repeatedly expanded up to some value, and then remains stable, but won't blow out the memory budget too quickly.

Agree, i had something similar in mind, and i saw implementations of this strategie at various places.

And if someone likes to work on optimization, we can think about different expand stategies ;-)