src: initial enablement of IsolateGroups

[jasnell]

Enable IsolateGroups!

Every isolate in V8 is created within a group. When pointer compression is enabled, all isolates within a single group are limited to a 4 GB shared pointer cage. By default, all isolates in the process share the same group, which means that when running with pointer compression, the entire process would be limited to a single 4 GB shared pointer cage. But, we can create as many IsolateGroups as we want, limited only by the amount of virtual memory available on the machine.

In the default node.js build, this is disabled. When only pointer compression is turned on, isolate groups are used.

/cc @erikcorry @nodejs/v8

[jasnell]

This is ready for review!

I'm not yet convinced that it's (pointer compression in general) is safe to enable by default as it may be too breaking for some workloads but with isolate groups at least we have the option now of using multiple worker threads and don't have the process-wide 4 GB limit. I'm going to experiment next the v8 option to allow for an 8 GB heap limit.

There should be no real noticeable difference in performance but overall apps should be using significantly less memory with pointer compression enabled. To give a rough idea, here's two comparisons of the memory just starting the node.js repl.. first is existing node 24, the second with main with pointer compression enabled:

Welcome to Node.js v24.8.0.
Type ".help" for more information.
> process.memoryUsage()
{
  rss: 59670528,
  heapTotal: 11632640,
  heapUsed: 6980872,
  external: 2465990,
  arrayBuffers: 10541
}
> .exit
jasnell@FF4V42X6YN mine % ./node   
Welcome to Node.js v25.0.0-pre.
Type ".help" for more information.
> process.memoryUsage()
{
  rss: 50642944,
  heapTotal: 5242880,
  heapUsed: 3777440,
  external: 2503911,
  arrayBuffers: 35716
}

Note that heapUsed is cut in half.

[mcollina]

I've tested and it works pretty well.

[jasnell]

Marking this author ready as it has one sign off and has passed CI... however, before landing I'd like to see if we can get signoffs from @targos and or @joyeecheung and or @addaleax .

[joyeecheung]

LGTM % nits

[mcollina]

I've tested this with an "hello world" SSR Next.js application, which reduces Total Heap by roughly 50% (400MB -> 200MB). It's amazing.

There is also some possible throughput improvement, but I'm seeing inconsistent numbers, and I need to nail it down.

[joyeecheung]

cc @nodejs/delivery-channels @nodejs/embedders - this changes the build configuration of whoever using ./configure --experimental-enable-pointer-compression to enable multiple pointer compression cages per process (so that the 4GB hard memory limit that comes from pointer compression can be worked around a bit when user code spread out memory usage to workers, each getting their own 4GB cage); it might be interesting for people who are already using pointer compression (does Electron use it?) or are thinking about distributing the pointer compression build.

[jasnell]

There's also another V8 flag that is supposed to enable an 8gb cage but initial testing is showing some compile errors in v8 that I need to figure out.

[joyeecheung]

FWIW I noticed that RAIIIsolateWithoutEntering is still used as a member of RAIIIsolate but for the use case of RAIIIsolate, updating it to assign dedicated isolate groups still won't be meaningful because it's only used to compile code cache during build steps, in that case there will only be one isolate in the entire process anyway, and it's fine to just let it as-is and use the default isolate group.

[deepak1556]

it might be interesting for people who are already using pointer compression (does Electron use it?)

Thanks for the call out, yes we run with V8 sandbox enabled which requires shared pointer compression cage so isolate groups would not be an option in the default mode, I see there is work to enable sandbox per isolate group https://issues.chromium.org/issues/342905186 which is interesting.

Looking at the current changes, any reason V8_COMPRESS_POINTERS_IN_MULTIPLE_CAGES is not defined behind a separate flag. Would allow flexibility for embedders to specify the type of pointer compression, as I understand shared pointer cage and multiple cages are exclusive ?

[jasnell]

We are running sandbox with multi-cages in workers and it works great. Might need some tweaks

Looking at the current changes, any reason V8_COMPRESS_POINTERS_IN_MULTIPLE_CAGES is not defined behind a separate flag.

We certainly can. I think maybe we'd make it as an opt out rather than an opt in since I think our default for node should really be to have multiple cages. I can add that before landing this.

[jasnell]

Added an additional compile flag to switch on shared cage.

@deepak1556 ... once this lands, you'll just need to add --experimental-pointer-compression-shared-cage to your ./configure in addition to the existing --experimental-enable-pointer-compression flag and you'll have the single cage back.

[joyeecheung]

--experimental-enable-pointer-compression: https://ci.nodejs.org/job/node-test-commit-linux-pointer-compression/952/
--experimental-enable-pointer-compression --experimental-pointer-compression-shared-cage: https://ci.nodejs.org/job/node-test-commit-linux-pointer-compression/953/

[jasnell]

Thank you for starting the additional ci jobs! Saved me a step! :-)

[Qard]

Mostly LGTM, but with a safety question.

[deepak1556]

you'll just need to add --experimental-pointer-compression-shared-cage to your ./configure in addition to the existing --experimental-enable-pointer-compression flag and you'll have the single cage back.

Perfect, thank you!

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69771/