src: allocate Buffer memory using ArrayBuffer allocator

[addaleax]

This PR allows using an ArrayBuffer allocator that was not provided by Node.js itself, and may not be malloc()-compatible.
The target use case are embedders like Electron, which is currently floating patches on top of Node and V8 in order to achieve this (fyi @codebytere).

---

[The first commit is #26201 in order to avoid conflicts]

deps: V8: cherry-pick d3308d0

Original commit message:

[api] Add Isolate::GetArrayBufferAllocator()

This allows non-monolithic embedders to always allocate memory
for ArrayBuffer instances using the right allocation method.

This is based on a patch that Electron is currently using.

Refs: https://github.com/electron/electron/blob/1898f9162073910c05958295c612deec6121a892/patches/common/v8/array_buffer.patch

Refs: v8/v8@d3308d0

src: make IsolateData store ArrayBufferAllocator

This enables us to identify whether we are using an
allocator that we know more about than what the generic
ArrayBuffer::Allocator API provides, in particular
whether it is malloc()-compatible.

worker: copy transferList ArrayBuffers on unknown allocator

If the ArrayBuffer::Allocator used to create ArrayBuffers
in the current Isolate is not a Node.js ArrayBufferAllocator,
we cannot know that it is malloc()-based, an in particular it might
not be compatible with the ArrayBuffer::Allocator on the receiving
end of the connection.

src: add debugging array allocator

Add a subclass of ArrayBufferAllocator that performs additional
debug checking, which in particular verifies that:

• All ArrayBuffer backing stores have been allocated with this
  allocator, or have been explicitly marked as coming from a
  compatible source.
• All memory allocated by the allocator has been freed once it is
  destroyed.

src: add allocation utils to env

Add a RAII utility for managing blocks of memory that have
been allocated with the ArrayBuffer::Allocator for a given
Isolate.

src: allocate Buffer memory using ArrayBuffer allocator

Always use the right allocator for memory that is turned into
an ArrayBuffer at a later point.

This enables embedders to use their own ArrayBuffer::Allocators,
and is inspired by Electron’s electron/node@f61bae3440e. It should
render their downstream patch unnecessary.

Refs: electron/node@f61bae3

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

@addaleax build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2667/pipeline

[addaleax]

CI: https://ci.nodejs.org/job/node-test-pull-request/20894/
Resume CI: https://ci.nodejs.org/job/node-test-pull-request/20925/ (:heavy_check_mark:)

[joyeecheung]

LGTM with a nit

[joyeecheung]

AllocatedLibuvBuffer? Or instead of storing a uv_buf_t as member, store the fields that can be used to wrap/unwrap uv_buf_t?

[addaleax]

AllocatedLibuvBuffer?

So, I’m not super happy with the name either. I wouldn’t want to include a reference to libuv, because uv_but_t was just chosen here as a nicer variant of std::pair<char*,size_t> that happens to work nicely with some pieces in our code base that already use it the same way.

Ideally, the name would be something that refers to the fact that this memory is usable for ArrayBuffers, but that would make any name even longer … ArrayBufferBuffer sounds weird, ArrayBufferStorage or ArrayBufferMemory is long but maybe okay, …?

Or instead of storing a uv_buf_t as member, store the fields that can be used to wrap/unwrap uv_buf_t?

I don’t really have strong feelings about that… I can make that change after/while rebasing (later today, after #26201 lands).

[joyeecheung]

because uv_but_t was just chosen here as a nicer variant of std::pair<char*,size_t> that happens to work nicely with some pieces in our code base that already use it the same way.

That was what I guessed as well, thanks for the explanation. I don't have strong feelings about using uv_buf_t underneath, but it would be nice to mention why it is chosen in the comments as one may think that AllocatedBuffer depends on libuv for a more sophisticated reason.

[addaleax]

@joyeecheung Does 1e17828 sound good to you?

(& to be clear, I’m still happy about suggestions for another name for this class if that fits better.)

[joyeecheung]

BTW: if we are refactoring the allocation methods used across the code base, is it possible to create allocation methods that take an Isolate* to do the optional LowMemoryNotification(), instead of doing Isolate::GetCurrent() for that in UncheckedRealloc?

[addaleax]

BTW: if we are refactoring the allocation methods used across the code base, is it possible to create allocation methods that take an Isolate* to do the optional LowMemoryNotification(), instead of doing Isolate::GetCurrent() for that in UncheckedRealloc?

I think so, but this PR doesn’t change a lot of other code that still uses our Malloc() family or MallocedBuffer, which doesn’t later get converted to ArrayBuffers… I guess we could go on in this direction, though, and do as much with env->AllocateManaged() (side note: also not an ideal name) as we can?

[addaleax]

CI: https://ci.nodejs.org/job/node-test-pull-request/20951/
Resume CI: https://ci.nodejs.org/job/node-test-pull-request/20990/ (✔️)

[addaleax]

Landed in b0869c6...84e02b1, thanks for the reviews!