Per Agent/Agent Cluster/ASG BrowserInterfaceBroker

[Tal Pressman]

Hi all,

As part of MBI and other MPArch projects, we have been working to attribute renderer-wide Mojo interfaces to specific ExecutionContexts. For the most part, this is done by migrating from using the RenderThread/Platform's BIB to using the ExecutionContext's BrowserInterfaceBroker (BIB). However, this migration is not always possible, as in some cases the spec provides certain guarantees for whole Agents / AgentClusters. Some examples of that are:

• DOM storage APIs have guaranteed ordering across different frames within the same agent.
• TimeZoneMonitor (spec still WIP) will probably require that notifications are sent to all frames in an Agent "atomically".

For cases like these, using the frame's BIB would cause a spec violation. At the same time, we do want the ability to attribute those interfaces at a higher granularity than the whole process.

This leads me to think that we would probably want to add a BIB somewhere at the Agent / Agent Cluster / AgentSchedulingGroup scope. (It could also be achieved in an ad hoc manner, but that is not ideal as it would make it harder to keep track of these interfaces when making changes.)

The way BIBs currently work, content/ and content embedders may register interface implementations that would be bound for a specific context (RenderFrameHost, SharedWorkerHost, etc.). If we add a new BIB, this implies that the representation of that scope in the browser would need to be exposed in content/public.

This brings up a number of questions:

1. Should we add this new scoped BIB or not?
2. If so, what scope should we expose the new BIB on? ASG is a somewhat arbitrary boundary, whereas Agent/Agent Cluster are spec concepts. On the other hand, ASG already exists in the code, but I don't think we have a good representation for Agent ATM?
3. If not, what would be the prefered way to handle such "agent-level" interfaces?

Thanks,

Tal

[Kentaro Hara]

- The granularity is: Agent <= Agent Cluster <= Agent Scheduling Group.

- //content does not yet have the concept of Agent Cluster until PrincipalInstance is implemented. It's not clear if //content/ has any plan to implement a concept of Agent.

Then shall we add BIB to Agent Scheduling Group for now? We can consider moving it to PrincipalInstance if needed once it's implemented.

--
You received this message because you are subscribed to the Google Groups "Blink Isolation discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-isolation...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-isolation-dev/CAAKSqgV_ib3JAEaMBtn-uqwP1n0vAHvswc0AinEDszeNvrK%2BKQ%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Dave Tapuska]

Are the BiB not a per Agent concept, because the Agent owns the event loop right? 

AgentCluster doesn't make sense because it is two (or more) Agents that only share data with one another, and that would be a Worker Agent and a Window Agent.

Is it possible to implement BiB inside blink on Agent and fetch it from via a public blink API if it is needed inside content?

dave.

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzTd7UwgYwucjZFd1%3DR%2B6vRP0JcJF6Hjm0vRFeMp57MeQ%40mail.gmail.com.

[Kouhei Ueno]

My understanding on this is that we should utilize the existing frame-BIB as much as possible, and introduce/use ASG-BIB for the few cases where there frame-BIB is infeasible.

I'm a bit hesitant about Agent-BIB from the added cognitive overhead of having Agent as the unit of states, and having ASG as the unit of scheduling. This can be further complicated if we make v8::Isolate per ASG (assuming it is unlikely that we make v8::Isolate per Agent).

I think using ASG as both a unit of scheduling and the shared states makes Blink development simpler to understand, while we may want to revisit ASG naming once we actively start attaching state to it.

--
To unsubscribe from this group and stop receiving emails from it, send an email to site-isolation-...@chromium.org.

--

kouhei

[Tal Pressman]

Hi all,

Thanks for the feedback. Following the replies here and some offline chats, I'd like to clarify some things.

First, a short overview of how BIB works:

On the renderer side, the code obtains a reference to a BrowserInterfaceBrokerProxy (for ExecutionContext-scoped BIB) or ThreadSafeBrowserInterfaceBrokerProxy (for process-wide BIB), and proceeds to call GetInterface with a pending receiver.

On the browser side, BrowserInterfaceBrokerImpl<HostType> receives the GetInterface call, and checks its binder maps to see whether there is a binder for the requested interface type. For this to work, the binder maps need to be populated. This is done by the various hosts (e.g. RenderFrameHostImpl) instantiating their BIB and calling internal::PopulateBinderMap{WithContext} (implemented in browser_interface_binders.cc). There, content:: code may register its binders, and then call the ContentBrowserClient to allow the embedder to register its own binders.

For this discussion, I am mostly concerned with the public API (for now). Because of this, I am mostly interested in this last call into the ContentBrowserClient, as it would have to pass the current context/scope to the client.

From an API perspective, I think the options are (with some pros and cons):

1. Expose the ASG concept to clients (either ASGH or some sort of token/ID)

• [Pro] Easy to implement since we already have ASG/ASGH.

• [Pro] No lifetime issues, since ASG lifetime is already "managed" by content.

• [Con] The ASG boundary is somewhat arbitrary, making it harder for clients to reason about.

• [Con] Would make it harder to introduce an Agent concept in the future (basically we would be encountering all the same questions and issues we are encountering now when trying to figure out if an interface can or can't be migrated to a frame's BIB).

2. Expose the Agent concept to clients (see implementation note below)

• [Pro] Agent is a spec concept, that is clearly defined, and is the "natural" scope for some interfaces.

• [Pro] Smaller scope means shorter lifetime of mojo interfaces and more fine-grained control of who is allowed to use them.

• [Con] Introduction of new concepts to content, managing lifecycle, etc.

• [Con] Additional cognitive overhead for Blink developers. (I would argue this is actually "necessary" and not something we want to hide from developers, since it is part of the spec.)

3. Keep the new BIB "internal" and don't expose it to clients. May still be either ASG- or Agent- scoped.

• [Pro] Allows us to defer the decision of what, if anything, to expose publicly.

• + most of the above arguments, depending on binding scope.

A note about implementation:

If we wanted to introduce an Agent-scoped BIB, it doesn't necessarily mean we need an Agent/AgentHost (or something equivalent). We would, however, need a mechanism to trigger the BIB instantiation and binder registration whenever a new Agent is "created".

A possible implementation might look something like this:

• The content client API could look like RegisterAgentInterfaces(AgentToken, BinderMapWithContext<AgentToken>).

• Whenever a frame is created belonging to a new agent, call ASGH::OnNewAgent(AgentToken).

• ASGH::OnNewAgent will instantiate a BIB, save it in a map keyed by the AgentToken, and trigger the interface registration flow.

• (Optionally) When the Agent is "destroyed", clean up its BIB.

+jam@, CSA team,

I would especially like to hear your thoughts as content API owners.

More specifically, it seems likely that until we have an actual use-case of an embedder binding requiring this, we would probably choose to proceed with option 3 above, but we would still like to reach some consensus on what the right scope for the new BIB is (to avoid having to make too many changes if we do decide to expose it in the future).

Thanks,

Tal

[Kentaro Hara]

Would it be possible to list mojo interfaces that will require the per-Agent / ASG BIB and see if they require the //content/public/ APIs?

--

Kentaro Hara, Tokyo

[Tal Pressman]

AFAICT, currently there are very few interfaces registered by embedders:

• ContentSettingsManager [chrome][weblayer]
• SpellCheckHost / SpellCheckPanelHost [chrome]
• MetricsService [chrome]
• JsChannelBindingProvider [chromecast]
  

I don't know if any of them would require agent granularity, maybe CSM?

[Kouhei Ueno]

Friendly ping on the topic.

We plan on adding per-AgentSchedulingGroup BrowserInterfaceBroker for content/ internal users soon, so we'd appreciate your feedback on this and the direction talp@ outlined earlier.

We are more than happy to GVC if you have questions or need clarification.

Thanks,

kouhei

--

kouhei

[Daniel Cheng]

At a high-level, the proposed approach is fine. A few comments/questions inline.

On Wed, Jan 27, 2021 at 7:24 PM 'Kouhei Ueno' via Site Isolation Development <site-isol...@chromium.org> wrote:

Friendly ping on the topic.

We plan on adding per-AgentSchedulingGroup BrowserInterfaceBroker for content/ internal users soon, so we'd appreciate your feedback on this and the direction talp@ outlined earlier.

We are more than happy to GVC if you have questions or need clarification.

Thanks,

kouhei

On Thu, Jan 21, 2021 at 3:59 PM Tal Pressman <ta...@google.com> wrote:

AFAICT, currently there are very few interfaces registered by embedders:

• ContentSettingsManager [chrome][weblayer]
• SpellCheckHost / SpellCheckPanelHost [chrome]
• MetricsService [chrome]
• JsChannelBindingProvider [chromecast]
  

I don't know if any of them would require agent granularity, maybe CSM?

On Thu, Jan 21, 2021 at 2:29 PM Kentaro Hara <har...@chromium.org> wrote:

Would it be possible to list mojo interfaces that will require the per-Agent / ASG BIB and see if they require the //content/public/ APIs?

On Thu, Jan 21, 2021 at 12:58 PM Tal Pressman <ta...@google.com> wrote:

Hi all,

Thanks for the feedback. Following the replies here and some offline chats, I'd like to clarify some things.

First, a short overview of how BIB works:

On the renderer side, the code obtains a reference to a BrowserInterfaceBrokerProxy (for ExecutionContext-scoped BIB) or ThreadSafeBrowserInterfaceBrokerProxy (for process-wide BIB), and proceeds to call GetInterface with a pending receiver.

I want to clarify that ThreadSafeBrowserInterfaceBrokerProxy was a hack from the past that covered Mojo interfaces for workers as well. Since workers now have a per-ExecutionContext BrowserInterfaceBroker, once we no longer have per-process interfaces, we won't need the thread-safe BrowserInterfaceBroker.

 

On the browser side, BrowserInterfaceBrokerImpl<HostType> receives the GetInterface call, and checks its binder maps to see whether there is a binder for the requested interface type. For this to work, the binder maps need to be populated. This is done by the various hosts (e.g. RenderFrameHostImpl) instantiating their BIB and calling internal::PopulateBinderMap{WithContext} (implemented in browser_interface_binders.cc). There, content:: code may register its binders, and then call the ContentBrowserClient to allow the embedder to register its own binders.

For this discussion, I am mostly concerned with the public API (for now). Because of this, I am mostly interested in this last call into the ContentBrowserClient, as it would have to pass the current context/scope to the client.

From an API perspective, I think the options are (with some pros and cons):

1. Expose the ASG concept to clients (either ASGH or some sort of token/ID)

• [Pro] Easy to implement since we already have ASG/ASGH.

• [Pro] No lifetime issues, since ASG lifetime is already "managed" by content.

• [Con] The ASG boundary is somewhat arbitrary, making it harder for clients to reason about.

• [Con] Would make it harder to introduce an Agent concept in the future (basically we would be encountering all the same questions and issues we are encountering now when trying to figure out if an interface can or can't be migrated to a frame's BIB).

2. Expose the Agent concept to clients (see implementation note below)

• [Pro] Agent is a spec concept, that is clearly defined, and is the "natural" scope for some interfaces.

• [Pro] Smaller scope means shorter lifetime of mojo interfaces and more fine-grained control of who is allowed to use them.

• [Con] Introduction of new concepts to content, managing lifecycle, etc.

• [Con] Additional cognitive overhead for Blink developers. (I would argue this is actually "necessary" and not something we want to hide from developers, since it is part of the spec.)

3. Keep the new BIB "internal" and don't expose it to clients. May still be either ASG- or Agent- scoped.

• [Pro] Allows us to defer the decision of what, if anything, to expose publicly.

• + most of the above arguments, depending on binding scope.

A note about implementation:

If we wanted to introduce an Agent-scoped BIB, it doesn't necessarily mean we need an Agent/AgentHost (or something equivalent). We would, however, need a mechanism to trigger the BIB instantiation and binder registration whenever a new Agent is "created".

A possible implementation might look something like this:

• The content client API could look like RegisterAgentInterfaces(AgentToken, BinderMapWithContext<AgentToken>).

• Whenever a frame is created belonging to a new agent, call ASGH::OnNewAgent(AgentToken).

• ASGH::OnNewAgent will instantiate a BIB, save it in a map keyed by the AgentToken, and trigger the interface registration flow.

From the chat, my understanding is the reason we are using AgentToken as the per-agent key is to avoid answering the question of exactly how we'll expose the Agent concept in the //content public API. That seems fine too.

However, I have some reservations about the current naming: I wouldn't expect the renderer to use AgentToken, and it sounds like we'll need to expose a per-agent BrowserInterfaceBroker both in content (via AgentSchedulingGroup) and Blink (via AgentGroupScheduler).

I personally find these names a bit confusing and unintuitive--especially the latter. An imperfect analogy would be to imagine if we had RenderFrameSchedulingGroup/LocalFrameScheduler instead of RenderFrameImpl/LocalFrame. While I don't think this should be a blocking issue, I hope we can sort it out soon to standardize on consistent terminology in the implementation.

 

• (Optionally) When the Agent is "destroyed", clean up its BIB.

Because we currently reuse frames across navigations, we needed to ensure that interface requests on the non-associated per-frame BrowserInterfaceBroker do not race with navigation state (e.g. the origin of the frame). Even though I don't expect we'll reuse an Agent, for consistency, I would recommend resetting the message pipe endpoint and leaving it at that. This might even just happen implicitly as part of the Agent destructor?

(As an aside, I went and refreshed my memory on how this works for per-frame BrowserInterfaceBrokers. I had actually forgotten that we simply register binders once for a frame, and rely on runtime checks in each binder callback to make sure we don't bind an interface we're not supposed to for a reused frame. Hopefully RenderDocument and better browser-side computation of things like origin will help us simplify this in the future!)

Daniel

[Kentaro Hara]

AFAICT, currently there are very few interfaces registered by embedders:

• ContentSettingsManager [chrome][weblayer]

• SpellCheckHost / SpellCheckPanelHost [chrome]

• MetricsService [chrome]

• JsChannelBindingProvider [chromecast]

I don't know if any of them would require agent granularity, maybe CSM?

So, is there any interface that requires per-ASG BIB outside //content/?

If the answer is no, my preference would be not to expose the concept to //content/public/ until it becomes necessary.

--

Kentaro Hara, Tokyo

[Tal Pressman]

Thanks, Daniel!

I want to clarify that ThreadSafeBrowserInterfaceBrokerProxy was a hack from the past that covered Mojo interfaces for workers as well. Since workers now have a per-ExecutionContext BrowserInterfaceBroker, once we no longer have per-process interfaces, we won't need the thread-safe BrowserInterfaceBroker.

I don't know whether we could actually replace all the interfaces, but if we can that would definitely be a very nice cleanup :)

 I personally find these names a bit confusing and unintuitive--especially the latter

Yeah, the names are pretty confusing... One note about your analogy, though, is that AgentGroupScheduler is actually analogous to FrameSchedulerImpl, not LocalFrame. We don't currently have an equivalent for LocalFrame, but would likely want to add one as part of adding the new BIB.

[...] for consistency, I would recommend resetting the message pipe endpoint and leaving it at that

The big issue here is, since we don't actually have an Agent object, knowing when it is destroyed. We could maybe keep track of the frames associated with the ASG, but I'm not sure if that's a good design...

Thanks,

Tal

On Thu, Jan 28, 2021 at 4:28 PM Daniel Cheng <dch...@chromium.org> wrote:

[Daniel Cheng]

On Thu, Jan 28, 2021 at 1:37 AM Tal Pressman <ta...@google.com> wrote:

Thanks, Daniel!

I want to clarify that ThreadSafeBrowserInterfaceBrokerProxy was a hack from the past that covered Mojo interfaces for workers as well. Since workers now have a per-ExecutionContext BrowserInterfaceBroker, once we no longer have per-process interfaces, we won't need the thread-safe BrowserInterfaceBroker.

I don't know whether we could actually replace all the interfaces, but if we can that would definitely be a very nice cleanup :)

 I personally find these names a bit confusing and unintuitive--especially the latter

Yeah, the names are pretty confusing... One note about your analogy, though, is that AgentGroupScheduler is actually analogous to FrameSchedulerImpl, not LocalFrame. We don't currently have an equivalent for LocalFrame, but would likely want to add one as part of adding the new BIB.

[...] for consistency, I would recommend resetting the message pipe endpoint and leaving it at that

The big issue here is, since we don't actually have an Agent object, knowing when it is destroyed. We could maybe keep track of the frames associated with the ASG, but I'm not sure if that's a good design...

I see. Given that we don't currently have an agent abstraction, I'd probably just make the proposed BrowserInterfacebroker have per-AgentSchedulingGroup granularity. I feel like it'd be a bit awkward to try to maintain per-Agent associations for Mojo interfaces, when everything else is being maintained at per-AgentSchedulingGroup granularity. Unlike frames, I don't think I'd be as worried about accidental cross-context coupling between agents, as frames in different agents should never be able to reach each other via JS, so the effects should (hopefully anyway :) be unobservable.

Daniel

[Tal Pressman]

It appears there is consensus that scopting the new BIB to ASG is preferable for now, so I will start working on that. I'll probably start with a short design doc to discuss the APIs, stay tuned ^_^

Thanks everyone for the feedback!

Tal

[Kentaro Hara]

+1 to the Per-ASG BIB, but I'd prefer exposing it to //content/public/ only when there is a use case.

--

Kentaro Hara, Tokyo

[Tal Pressman]

Ah, yes, I meant to mention that but forgot. Thanks for the clarification ^_^

[Kouhei Ueno]

Thank you all for the discussion.

> +1 to the Per-ASG BIB, but I'd prefer exposing it to //content/public/ only when there is a use case.

I'm on the same page.

--

kouhei

[Charlie Reis]

Sorry for chiming in late, but this sounds reasonable to me as well.

I've been struggling a bit to see how frame/document/ExecutionContext-specific BrowserInterfaceBrokers are safe in the first place, similar to our earlier chats about IPC reordering across AgentSchedulingGroups.  It sounds an awful lot like document 1 could set up some browser-side feature state via Mojo, immediately tell same-origin document 2 to use that state, and document 2's feature-use IPC could arrive before document 1's feature-setup IPC and thus fails.  I chatted with Daniel about it just now and it seems like people are mostly crossing their fingers that this general approach in Mojo is safe enough.  I suppose the DOM storage APIs wouldn't face that problem since they're currently process-wide, but we have a ton of things in frame-level BiBs that seem like they could be flaky for closely interacting documents.

In terms of this discussion, I agree that having an ASG-specific (or Agent-specific) BiB is a good thing that avoids such problems.  The plan to move process-wide stuff to it should be safe (as safe as the IPC reordering between ASGs we've already discussed, at any rate).  I vaguely wonder if we also want to move more ExecutionContext-specific things to an Agent level to avoid the flakiness concern above (or have some way to associate the ExecutionContext-specific BiBs of an Agent with each other), but that's definitely a separate question for the future.

Charlie

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAPVAxLWvbGOH2RuFrCpARs3_3j_4ZwATycTa%3Drzq2E3hYx148Q%40mail.gmail.com.

[Kentaro Hara]

I vaguely wonder if we also want to move more ExecutionContext-specific things to an Agent level to avoid the flakiness concern above

I'm skeptical about this :)

On the Blink side, most Mojo interfaces are ExecutionContext-specific and their connections are expected to reset when the ExecutionContext is detached. This is exactly why we migrated mojo::Remote/Receiver to HeapRemote/Receiver, whose default behavior is to reset the mojo connection when the ExecutionContext is detached.

It sounds an awful lot like document 1 could set up some browser-side feature state via Mojo, immediately tell same-origin document 2 to use that state, and document 2's feature-use IPC could arrive before document 1's feature-setup IPC and thus fails.  I chatted with Daniel about it just now and it seems like people are mostly crossing their fingers that this general approach in Mojo is safe enough.  I suppose the DOM storage APIs wouldn't face that problem since they're currently process-wide, but we have a ton of things in frame-level BiBs that seem like they could be flaky for closely interacting documents.

I agree these types of features should use a per-ASG BIB.

I think that the principle is: A per-ASG thing should use a per-ASG BIB. A per-ExecutionContext thing should use a per-ExecutionContext BIB.

My impression is that the majority of features is per-ExecutionContext but I could be wrong :)

--

Kentaro Hara, Tokyo

[Daniel Cheng]

I think Charlie's concern is about the ordering of events between two same-origin execution contexts in the same agent.

With legacy IPC, this was all implicit, because all IPC was ordered.

With Mojo, we've made it unordered at several different levels:

- BrowserInterfaceBroker itself does not provide a mechanism to get an associated interface

- BrowserInterfaceBroker itself is not associated with navigation

IIRC, associated interfaces and Blink scheduling have some interesting interactions as well (in fact, there's a thread on Web Platform Kin about the interaction of background tab freezing with things like BroadcastChannel...)

On the Blink side, most Mojo interfaces are ExecutionContext-specific and their connections are expected to reset when the ExecutionContext is detached. This is exactly why we migrated mojo::Remote/Receiver to HeapRemote/Receiver, whose default behavior is to reset the mojo connection when the ExecutionContext is detached.

There is nothing that stops us from retrieving a per-AgentSchedulingGroup interface but having the message endpoint be tied to an ExecutionContext though. So I think we could consider these points separately.

vaguely wonder if we also want to move more ExecutionContext-specific things to an Agent level to avoid the flakiness concern above

I think this wouldn't be needed if BrowserInterfaceBroker was channel-associated *and* BrowserInterfaceBroker provided a mechanism for binding associated interfaces. But I would have some concerns about how this would interact with Blink scheduling, so hopefully someone can shed some light on that.

Daniel

[Tal Pressman]

Hi all,

Here is the design doc / implementation guide for the ASG-BIB, please let me know what you think (should be commentable by committers).

I think this wouldn't be needed if BrowserInterfaceBroker was channel-associated *and* BrowserInterfaceBroker provided a mechanism for binding associated interfaces. But I would have some concerns about how this would interact with Blink scheduling, so hopefully someone can shed some light on that.

Is there anything stopping us from making the BIBs (both ASG- and EC-) channel-associated? If we do that, we could easily add a GetAssociatedInterface method on them. Then, once that's done, we could convert interfaces where we have concerns about ordering to be associated and see what happens? (As a side-benefit, it might allow us to replace AssociatedInterfaceProvider with BIB, leaving "one approved way" to obtain interfaces generaically.)

WDYT?

Thanks,

Tal

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-isolation-dev/CAF3XrKrXE-yF6GWxB2c7EuSMGb1YMKK4C68VbCpLQwHzZt1RKg%40mail.gmail.com.

[Kentaro Hara]

Just to clarify, are you proposing the end state like this?

- Per-EC BIB is replaced with per-ASG BIB. Per-EC BIB is gone.

- Per-ASG BIB is channel-associated.

- Per-EC mojo interface is instantiated as an associated interface of per-ASG BIB.

(Ignoring the eng cost of doing the replacement,) conceptually this makes sense to me.

--

Kentaro Hara, Tokyo

[Tal Pressman]

Just to clarify, are you proposing the end state like this?

I was thinking we would still have per-EC BIB, but make them channel-associated as well. I don't think it makes a huge difference, but registering the implementations on the browser side would have access to RFHI, etc.

Other than that, I think that's roughly what I was asking.

[Alexander Timin]

(sorry for missing the fun here — managed to miss this somehow and catching up while reviewing crrev.com/c/2677585) 

Overall +1 to having per-ASG BrowserInterfaceBroker (however, we should be careful when migrating from per-process to per-ASG granularity and find a reason why it shouldn't go to per-ASG channel instead).

The question that Charlie raised is a really exciting one — my question would be whether you have been thinking about implications for tests / web-exposed behaviour or implementation correctness specifically, as the answers might be a bit different.

From my rough understanding (please feel correct me; also would love to learn more), this area is extremely unclear from the spec perspective, and for a good reason — drawing a boundary between documents which can reach out into each other seems to be next to impossible.

IIUC, the spec has a notion of "implied document", but I believe that it's as clear and as comprehensive as well as you can expect given the difficulty of the challenge here.

So from this perspective, it seems that moving more things to an Agent level makes sense. However, the practicality of this is the whole other question. Again, IIUC we want to clear as much stuff as possible, as the references which are accidentally left after navigating away from a document,

but having the other documents keeping the agent alive, is a source of memory and resource leaks (and I remember that we had some interventions to become more aggressive in clearing this leftover references). 

   

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAAKSqgVsp8%3DnitrUkfsEsnTPw7ZDTghL7uyxJWowYSmkGUTNNA%40mail.gmail.com.