Isolate groups without pointer compression?

[ClearScript Developers]

Greetings!

We've run into a new issue in V8 13.7 (upgrading from 13.5). In a multi-isolate application, tearing down one isolate can trigger synchronous activity in another – specifically, the posting of ReleasePooledChunksTask.

Evidently, that happens because, by default, both isolates are in the same group. Our understanding is that isolate groups are a new feature that allows isolates to share certain resources, and that, unfortunately, is a problem for us. In our case, isolates must remain... isolated.

Setting up a dedicated group for each isolate appears to be possible, but isolate groups require pointer compression, which we'd prefer to disable. Even if we enabled it, pointer compression isn't supported on 32-bit systems, which we still support.

Can someone shed some light? Why do isolate groups require pointer compression? How difficult would it be to remove that restriction?

Thanks!

[Michael Lippautz]

At this point V8 only officially supports a configuration with a single IsolateGroup.

The concept of IsolateGroup was introduced by other embedders and as you wrote it's really for sharing a bunch of resources. E.g., read-only space, page pool, and at this point also a pointer compression cage. You could imagine an IsolateGroup without pointer compression -- at this point this is just not implemented.

For maintenance and security reasons we can't accept any non-trivial patches for this area at this point as we cannot reliably test other configurations and ensure that they don't cause security problems down the line.

-Michael

[James Snell]

Hey all,

Yeah, we (Cloudflare Workers runtime folks) worked with Igalia and asked them to implement the IsolateGroups mechanism specifically for pointer compression support and would really have no intention of supporting it without pointer compression. In workers we will create thousands of isolates within a single process and can't afford to be limited by the single pointer compression cage for the entire process. We also want to start making use of the v8 sandbox. We were running a non-supported configuration with pointer compression enabled but otherwise diverging from the supported configuration in a way that was not sustainable and isolate groups allow us to have better alignment there. It *might* be possible to have a variation of isolate groups that works without pointer compression but it's not something that we'd be interested in and not something we'd ask our friends at Igalia to work on.

- James

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAH%2BmL5CWjvnpqfYPvv_rdsmH6h-x4mWOtzqDCdPjLA%2BV0c4oQA%40mail.gmail.com.

[Erik Corry]

This isn't really caused by the IsolateGroup feature.  The PagePool allows unused pages to be put in a pool so that other isolates can reuse them.  This is a new performance feature from V8. It is more efficient to reuse a page than to unmap and then remap it later, which is two syscalls and probably disrupts the TLB.

The page pool would cause the same inter-isolate interactions if IsolateGroups did not exist.

I think the following untested uncompiled patch might fix your problem:

diff --git a/src/heap/heap.cc b/src/heap/heap.cc
index 090c1f780d2..d063998a963 100644
--- a/src/heap/heap.cc
+++ b/src/heap/heap.cc
@@ -6402,6 +6402,7 @@ void Heap::TearDown() {
 
   read_only_space_ = nullptr;
 
+  memory_allocator()->pool()->ReleaseImmediately(isolate());
   memory_allocator()->pool()->ReleaseOnTearDown(isolate());
   memory_allocator()->TearDown();
 

This will just release pages immediately, instead of putting them in the shared pool where other isolates can use them.

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CACFvHWnXBZNRsFWwJtuoHnXhf4KHZgtQGYdM5z9XBcQXdWh3pA%40mail.gmail.com.

[Michael Lippautz]

On Fri, Jun 13, 2025 at 12:06 PM Erik Corry <erik...@chromium.org> wrote:

This isn't really caused by the IsolateGroup feature.  The PagePool allows unused pages to be put in a pool so that other isolates can reuse them.  This is a new performance feature from V8. It is more efficient to reuse a page than to unmap and then remap it later, which is two syscalls and probably disrupts the TLB.

The page pool would cause the same inter-isolate interactions if IsolateGroups did not exist.

I think the following untested uncompiled patch might fix your problem:

diff --git a/src/heap/heap.cc b/src/heap/heap.cc
index 090c1f780d2..d063998a963 100644
--- a/src/heap/heap.cc
+++ b/src/heap/heap.cc
@@ -6402,6 +6402,7 @@ void Heap::TearDown() {
 
   read_only_space_ = nullptr;
 
+  memory_allocator()->pool()->ReleaseImmediately(isolate());
   memory_allocator()->pool()->ReleaseOnTearDown(isolate());
   memory_allocator()->TearDown();
 

This will just release pages immediately, instead of putting them in the shared pool where other isolates can use them.

Yes, this will work. We will need to refactor the pool a bit in the near term and can add a few flags to disable it selectively.

 

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHZxHpjOTR1T35eHRE2O71t9HTbd4jX2hNv6HZHy3ed%2B-U1Acw%40mail.gmail.com.

[ClearScript Developers]

Hello V8 folks,

First, the patch works for us! Thank you very much!

Interestingly, we've confirmed that putting each isolate into its own group also works, and that seems a more robust solution. If only it didn't require pointer compression :)

Anyway, we understand that, since isolate groups were designed to improve pointer compression, no effort will be made to enable it for other scenarios.

Nevertheless, the patch only seems to sidestep the issue in the teardown case. Are there any other current or planned scenarios where this "isolate crosstalk" could occur?

Cheers!

[Michael Lippautz]

On Fri, Jun 13, 2025 at 4:12 PM ClearScript Developers <clearsc...@gmail.com> wrote:

Hello V8 folks,

First, the patch works for us! Thank you very much!

Interestingly, we've confirmed that putting each isolate into its own group also works, and that seems a more robust solution. If only it didn't require pointer compression :)

Anyway, we understand that, since isolate groups were designed to improve pointer compression, no effort will be made to enable it for other scenarios.

Nevertheless, the patch only seems to sidestep the issue in the teardown case. Are there any other current or planned scenarios where this "isolate crosstalk" could occur?

Compilers use a process-global dispatcher at this point. 

With a pointer compression cage per process there's probably already quite some crosstalk in very indirect ways without even sharing pages.

WebAssembly probably also has quite some infrastructure that is process-global. @Jakob Kummerow may have some pointers.

 

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/9417bdcc-72cc-40de-aae8-6e9adfc18bebn%40googlegroups.com.

[ClearScript Developers]

>With a pointer compression cage per process there's probably already quite some crosstalk in very indirect ways without even sharing pages.

Just to clarify: The problem for us is when the crosstalk triggers a synchronous embedder call on behalf of a different isolate – e.g., tearing down one isolate triggers a synchronous call to another isolate's task runner.

[Michael Lippautz]

On Fri, Jun 13, 2025 at 7:32 PM ClearScript Developers <clearsc...@gmail.com> wrote:

>With a pointer compression cage per process there's probably already quite some crosstalk in very indirect ways without even sharing pages.

Just to clarify: The problem for us is when the crosstalk triggers a synchronous embedder call on behalf of a different isolate – e.g., tearing down one isolate triggers a synchronous call to another isolate's task runner.

I landed a change which allows you to specify --no_memory_pool_share_memory_on_teardown to disable sharing on teardown using a different Isolate.

 

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/cd330b4d-a7a0-4313-acae-8b5b1d277887n%40googlegroups.com.

[ClearScript Developers]

On Monday, June 16, 2025 at 9:29:55 AM UTC-4 mlip...@chromium.org wrote:

I landed a change which allows you to specify --no_memory_pool_share_memory_on_teardown to disable sharing on teardown using a different Isolate.

Excellent! Thank you so much!