5 ms·

> Leaky add-ons usually cause zombie compartments by holding references to DOM structures within a web page even after the page has been closed or navigated awa

> Leaky add-ons usually cause zombie compartments by holding references to DOM structures within a web page even after the page has been closed or navigated away from. This prevents Firefox from garbage-collecting the page’s compartment. If an add-on relies on persistent references to closed pages by design (such as a form data history plugin), is there a way to adapt it to this new feature to not let Firefox sever it's references under the assumption that it's a memory leak?

khuey 14y ago
No.
- alttab 14y ago
  Care to clarify?
  - mcpherrinm 14y ago
    References are severed. There's no way to stop it. You'd have to copy out the data you want.
    - nnethercote 14y ago
      And in practice cutting these references hasn't caused any problems, while fixing another massive problem.
Evbn 14y ago
It should make a private copy of the data it needs.
gliese1337 14y ago
Copy them. I can think of no good reason that one would ever legitimately want or need to keep references to a page that is no longer loaded. It's like returning a pointer to a local variable from a C function; you should expect it to be invalid once it's scope is gone! Copying is likely to use less total memory anyway, because it will rarely result in having to allocate new compartments for the plugins, but it will allow an entire compartment for a page to be collected, that is otherwise kept around for the sake comparatively small objects. This actually seems to me to have a lot of implications for the design of garbage collectors generally. In theory, correct garbage collectors are never supposed to collect objects that may still be used, which in practice usually means "that are reachable". But, we've already got such a thing as "weak references" to fudge that a little. This seems like kind of the opposite idea- having a sort of "superstrong" owner reference such that once it goes away, you know that the object will never be used again (or shouldn't be, anyway, with future uses constituting bugs), and can be collected despite what other references might exist. It also seems like one of those obvious-after-the-fact genius ideas to have garbage collection running independently per compartment. Do Web Workers, e.g., get their own separate garbage collection, too? Any kind of shared-nothing concurrency model ought to be able to do the same thing to improve GC pauses; are there language implementations (I'm thinking probably Erlang here) that actually do that?
- nnethercote 14y ago
  Each web worker gets its own compartment, and thus can be garbage collected individually.
mccr8 14y ago
Addons have to copy out the data they want before the page closes. It isn't acceptable to keep around all data on a page just to keep a few little bits of information.

khuey 14y ago

No.

alttab 14y ago
Care to clarify?
- mcpherrinm 14y ago
  References are severed. There's no way to stop it. You'd have to copy out the data you want.
  - nnethercote 14y ago
    And in practice cutting these references hasn't caused any problems, while fixing another massive problem.

Evbn 14y ago

It should make a private copy of the data it needs.

gliese1337 14y ago

Copy them. I can think of no good reason that one would ever legitimately want or need to keep references to a page that is no longer loaded. It's like returning a pointer to a local variable from a C function; you should expect it to be invalid once it's scope is gone! Copying is likely to use less total memory anyway, because it will rarely result in having to allocate new compartments for the plugins, but it will allow an entire compartment for a page to be collected, that is otherwise kept around for the sake comparatively small objects. This actually seems to me to have a lot of implications for the design of garbage collectors generally. In theory, correct garbage collectors are never supposed to collect objects that may still be used, which in practice usually means "that are reachable". But, we've already got such a thing as "weak references" to fudge that a little. This seems like kind of the opposite idea- having a sort of "superstrong" owner reference such that once it goes away, you know that the object will never be used again (or shouldn't be, anyway, with future uses constituting bugs), and can be collected despite what other references might exist. It also seems like one of those obvious-after-the-fact genius ideas to have garbage collection running independently per compartment. Do Web Workers, e.g., get their own separate garbage collection, too? Any kind of shared-nothing concurrency model ought to be able to do the same thing to improve GC pauses; are there language implementations (I'm thinking probably Erlang here) that actually do that?

nnethercote 14y ago
Each web worker gets its own compartment, and thus can be garbage collected individually.

mccr8 14y ago

Addons have to copy out the data they want before the page closes. It isn't acceptable to keep around all data on a page just to keep a few little bits of information.