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.
On Thu, Jun 12, 2025 at 4:44 PM 'James Snell' via v8-dev <
[email protected]> wrote:
> 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
>
>
> On Thu, Jun 12, 2025 at 7:10 AM Michael Lippautz <[email protected]>
> wrote:
>
>>
>>
>> On Thu, Jun 12, 2025 at 3:37 PM ClearScript Developers <
>> [email protected]> wrote:
>>
>>> 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?
>>>
>>>
>> 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
>>
>>
>> --
>> --
>> v8-dev mailing list
>> [email protected]
>> 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 [email protected].
>> To view this discussion visit
>> https://groups.google.com/d/msgid/v8-dev/CAH%2BmL5CWjvnpqfYPvv_rdsmH6h-x4mWOtzqDCdPjLA%2BV0c4oQA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/v8-dev/CAH%2BmL5CWjvnpqfYPvv_rdsmH6h-x4mWOtzqDCdPjLA%2BV0c4oQA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> --
> v8-dev mailing list
> [email protected]
> 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 [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/v8-dev/CACFvHWnXBZNRsFWwJtuoHnXhf4KHZgtQGYdM5z9XBcQXdWh3pA%40mail.gmail.com
> <https://groups.google.com/d/msgid/v8-dev/CACFvHWnXBZNRsFWwJtuoHnXhf4KHZgtQGYdM5z9XBcQXdWh3pA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
--
v8-dev mailing list
[email protected]
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/v8-dev/CAHZxHpjOTR1T35eHRE2O71t9HTbd4jX2hNv6HZHy3ed%2B-U1Acw%40mail.gmail.com.
