Performance characteristics: C++ coroutine libuv integration

Allocation profile

Single operation (e.g., fsPromises.access)

The FSReqPromise path unconditionally allocates two AliasedBufferT typed array pairs
(for stat and statfs fields) even for operations that never use them. The coroutine path
has no wasted allocations.

In steady state the coroutine frame is served from a thread-local free-list with 256-byte
size class granularity (up to 4096 bytes, 32 frames per bucket). No malloc/free calls
occur after the first coroutine of each size class completes.

Multi-step operation (open + stat + read + close)

The multi-step case is where the coroutine pattern provides the largest benefit. A single
coroutine frame serves all four libuv operations. The intermediate steps (open result
dispatches stat, stat result dispatches read, etc.) are pure C++ with no V8 involvement.

Per-operation overhead

Dispatch path (JS binding call to libuv dispatch)

The coroutine pays one extra InternalCallbackScope cycle for the initial segment (from
Start() to the first co_await). When no hooks are registered and no ticks are
scheduled, this is roughly 10 cheap operations (integer increments, pointer swaps,
branch-not-taken checks).

Completion path (libuv callback to JS notification)

The coroutine avoids the MakeCallback indirection chain (AsyncWrap::MakeCallback
string overload -> Name overload -> Function overload -> InternalMakeCallback), the V8
property lookup for the callback function, all BaseObjectPtr reference counting, weak
reference management, and the BaseObject destructor chain.

Multi-step totals

For the 4-step readFile coroutine, only the final resolve crosses the JS/C++ boundary.
The three intermediate steps are handle_.resume() -> coroutine body -> dispatch next
libuv call -> suspend. Each intermediate resume segment goes through an
InternalCallbackScope for correctness (async_hooks, context frame, draining), but the
drain finds empty queues and returns after a few comparisons.

Per-resume segment cost (intermediate steps, no hooks)

Each intermediate step (e.g., "open completed, dispatch stat") costs:

Total: roughly 20-25 cheap operations per intermediate step. No heap allocations, no JS
calls, no string operations, no object creation.

Optimization details

Four specific optimizations reduce overhead compared to a naive coroutine implementation:

1. Lazy resource object: Object::New(isolate) (the most expensive single operation
   in init_tracking) is only called when async_hooks listeners are active (kInit > 0
   or kUsesExecutionAsyncResource > 0). InternalCallbackScope was updated to accept a
   null Global<Object>* for the resource, with push_async_context already handling
   null correctly by skipping the native_execution_async_resources_ store.

2. Thread-local frame allocator: Coroutine frames are allocated from a thread-local
   free-list with 256-byte size class granularity via promise_type::operator new/delete.
   Each bucket holds up to 32 frames (bounded by kMaxCachedPerBucket). After the first
   coroutine of a given size class completes, subsequent ones have zero malloc overhead.

3. Cached type name string: The V8 string for the async resource type name is cached
   per Isolate in IsolateData::static_str_map (the same mechanism used by HTTP/2 header
   name caching). Only the first coroutine of a given type per Isolate pays the
   String::NewFromUtf8 cost. Safe with Worker threads since each Worker has its own
   IsolateData.

4. No AdjustAmountOfExternalAllocatedMemory: Removed. The inaccurate fixed estimate
   (1024 bytes) was giving V8 misleading GC pressure signals, the API is deprecated in
   favor of ExternalMemoryAccounter, and short-lived coroutine frames don't benefit from
   GC heuristic adjustments.

Node.js integration

The coroutine implementation provides the same integration as the existing ReqWrap
pattern: