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!
On Friday, June 13, 2025 at 6:30:13 AM UTC-4 mlippa...@chromium.org wrote:
> 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.
>
>
>>
>> On Thu, Jun 12, 2025 at 4:44 PM 'James Snell' via v8-dev <
>> v8-...@googlegroups.com> 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 <mlip...@chromium.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 12, 2025 at 3:37 PM ClearScript Developers <
>>>> clearsc...@gmail.com> 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
>>>> 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
>>>>
>>>> <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
>>> 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/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
>> 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/CAHZxHpjOTR1T35eHRE2O71t9HTbd4jX2hNv6HZHy3ed%2B-U1Acw%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/v8-dev/CAHZxHpjOTR1T35eHRE2O71t9HTbd4jX2hNv6HZHy3ed%2B-U1Acw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
--
v8-dev mailing list
v8-dev@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+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/v8-dev/9417bdcc-72cc-40de-aae8-6e9adfc18bebn%40googlegroups.com.
