ffi: add V8 fast-call path

[bengl]

HEADS UP: This likely isn't done yet. It's mainly here to compare approaches with @ShogunPanda.

---

Add a parallel dispatch path that uses V8 fast API calls instead of libffi for eligible native calls. At DynamicLibrary.getFunction time, generate a per-function JIT'd trampoline that strips V8's receiver argument and tail-calls the target. Signatures with callbacks, unsupported argument types, or more register-passed args than the platform ABI permits transparently fall back to libffi.

Stub emitters cover Linux/macOS/FreeBSD on x86_64 and AArch64, Windows on x86_64 and AArch64, and Linux on AArch32. JIT memory is allocated per isolate via direct mmap with MAP_JIT on macOS and W^X enforcement elsewhere. The JS wrapper validates each argument per declared type, mirroring the libffi slow callback so the contract is identical across both paths and across V8 optimization tiers.

The path is gated behind --experimental-ffi and can be disabled at build time with --without-ffi-fastcall. The previous shared-buffer JS fast path is removed, replaced by this fast-call path.

---

Some benchmarks:

                                   confidence improvement accuracy (*)     (**)    (***)
  ffi/add-f64.js n=10000000               ***    746.34 %      ±46.27%  ±64.21%  ±89.28%
  ffi/add-i32.js n=10000000               ***    807.83 %      ±44.39%  ±61.59%  ±85.62%
  ffi/getpid.js n=10000000                ***   1173.51 %     ±156.05% ±216.56% ±301.12%
  ffi/many-args.js n=10000000             ***    481.97 %       ±6.47%   ±8.96%  ±12.42%
  ffi/pointer-bigint.js n=10000000        ***    901.32 %      ±61.08%  ±84.75% ±117.82%
  ffi/sum-buffer.js n=10000000             **      9.51 %       ±5.38%   ±7.44%  ±10.28%
  

[nodejs-github-bot]

Review requested:

• @nodejs/ffi
• @nodejs/gyp
• @nodejs/startup
• @nodejs/tsc

[ronag]

With this. How does ffi compare to napi? Do we have any guidelines in regards to when to use which?

[ShogunPanda]

@ronag On my PR (which yields similar results as Bryan's) we're beating it by like 100x.

[ronag]

So ffi is 100x faster than napi?

[ShogunPanda]

So ffi is 100x faster than napi?

Sorry, I thought you meant https://github.com/node-ffi-napi/node-ffi-napi.

We probably have to measure that once we agree on the direction.

[dmazzella]

So ffi is 100x faster than napi?

Sorry, I thought you meant https://github.com/node-ffi-napi/node-ffi-napi.

We probably have to measure that once we agree on the direction.

node-ffi-napi isn't a good benchmark for performance, but koffi is. Version 3 performs even better than version 2; it's still in beta (but can already be used for testing).

[bengl]

Okay, so, new benchmark:

                                   confidence improvement accuracy (*)     (**)    (***)
  ffi/add-f64.js n=10000000               ***   2828.52 %     ±200.38% ±278.11% ±386.81%
  ffi/add-i32.js n=10000000               ***   2696.98 %     ±205.33% ±284.98% ±396.37%
  ffi/getpid.js n=10000000                ***   1353.74 %       ±7.47%  ±10.09%  ±13.43%
  ffi/many-args.js n=10000000             ***   5098.46 %      ±20.96%  ±29.08%  ±40.44%
  ffi/pointer-bigint.js n=10000000        ***   1040.00 %       ±4.04%   ±5.46%   ±7.26%
  ffi/sum-buffer.js n=10000000            ***     14.96 %       ±5.37%   ±7.42%  ±10.27%

The main reasons this improved are:

1. I minimized the the impact of the wrapper functions.
2. I took @addaleax's suggestion on @ShogunPanda's PR to see if we can get some wins from not having to do the extra trampoline on the native side. It makes things simpler (apart from the V8 change) and reduces V8 fast API calls to effectively its own FFI implementation.

The net result is that there's not a whole lot extra going on that V8 wouldn't have to do regardless, so I'd guess we're approaching limits here.

I'll hold off on making the V8 upstream patch until we also see @ShogunPanda's latest approach and decide which way we want to go. I also want to put together a benchmark repo that also tests this against existing userland FFI implementations, and also against NAPI (without and without the C++ wrapper lib), and non-NAPI addons.