On Fri, Jun 13, 2025 at 7:32 PM ClearScript Developers < [email protected]> 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 <http://crrev.com/c/6641943> which allows you to specify --no_memory_pool_share_memory_on_teardown to disable sharing on teardown using a different Isolate. > > On Friday, June 13, 2025 at 12:42:14 PM UTC-4 [email protected] > wrote: > >> On Fri, Jun 13, 2025 at 4:12 PM ClearScript Developers < >> [email protected]> 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. >> >> >> >> >>> Cheers! >>> >>> On Friday, June 13, 2025 at 6:30:13 AM UTC-4 [email protected] wrote: >>> >>>> On Fri, Jun 13, 2025 at 12:06 PM Erik Corry <[email protected]> >>>> 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 < >>>>> [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 >>>>> <https://groups.google.com/d/msgid/v8-dev/CAHZxHpjOTR1T35eHRE2O71t9HTbd4jX2hNv6HZHy3ed%2B-U1Acw%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/9417bdcc-72cc-40de-aae8-6e9adfc18bebn%40googlegroups.com >>> <https://groups.google.com/d/msgid/v8-dev/9417bdcc-72cc-40de-aae8-6e9adfc18bebn%40googlegroups.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/cd330b4d-a7a0-4313-acae-8b5b1d277887n%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/cd330b4d-a7a0-4313-acae-8b5b1d277887n%40googlegroups.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/CAH%2BmL5B%2BU%3Da_T6ftdkv9LBYTz%2BjyK21k%2BsELc4Xzg5u2O8sYSA%40mail.gmail.com.
