Memory management in features implemented in JS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory management in features implemented in JS

Kyle Huey-2
Followup to dev-platform please.

We are discovering a lot of leaks in JS implemented DOM objects.  The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong references to the
listener.  In C++ we would split the object into two separate
refcounted objects, one for the DOM side and another that interfaces
with these global singletons (which I'll call the proxy).  Between
this pair of objects at least one direction would be weak, allowing
the DOM object's lifetime to be managed appropriately by the garbage
and cycle collectors and in its destructor it could tell the proxy to
unregister itself and die.  But this isn't possible because of the
lack of weak references in JS.

Instead we end up running a bunch of manual cleanup code at
inner-window-destroyed.  This is already bad for many things because
it means that our object now lives for the lifetime of the window
(which might be forever, in the case of the system app window on B2G).
 Also in some cases we forget to remove our inner-window-destroyed
observer so we live forever.  For objects not intended to live for the
lifetime of the window we need to manually perform the same cleanup
when we figure out that we can go away (which can be quite difficult
since we can't usefully answer the question "is something in the
content page holding me alive?").  All of this requires a lot of
careful manual memory management which is very easy to get wrong and
is foreign to many JS authors.

Short of not implementing things in JS, what ideas do people have for
fixing these issues?  We have some ideas of how to add helpers to
scope these things to the lifetime of the window (perhaps by adding an
API that returns a promise that is resolved at inner-window-destroyed
to provide a good cleanup hook that is not global) but that doesn't
help with objects intended to have shorter lifetimes.  Is it possible
for us to implement some sort of useful weak reference in JS?

- Kyle
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Memory management in features implemented in JS

David Rajchenbach-Teller-2
Couldn't we insist that any reference to a DOM element in JS (or at
least in JS-implemented components) must be a weak pointer-style
wrapper? I seem to remember that we have introduced something along
these lines a few years ago as a way to fight against leaks of
references to DOM by add-ons.

On 3/20/14 12:39 AM, Kyle Huey wrote:
> Followup to dev-platform please.


--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Memory management in features implemented in JS

Kyle Huey-2
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
<[hidden email]> wrote:

> Couldn't we insist that any reference to a DOM element in JS (or at
> least in JS-implemented components) must be a weak pointer-style
> wrapper? I seem to remember that we have introduced something along
> these lines a few years ago as a way to fight against leaks of
> references to DOM by add-ons.
>
> On 3/20/14 12:39 AM, Kyle Huey wrote:
>> Followup to dev-platform please.
>
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla

The issue is not leaking the DOM elements, it's leaking the (chrome)
JS implementations themselves.  Wrapper cutting actually masks these
leaks by stopping them from entraining entire windows past the tests
of these features.

- Kyle
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Memory management in features implemented in JS

Ehsan Akhgari
On 2014-03-19, 7:58 PM, Kyle Huey wrote:

> On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
> <[hidden email]> wrote:
>> Couldn't we insist that any reference to a DOM element in JS (or at
>> least in JS-implemented components) must be a weak pointer-style
>> wrapper? I seem to remember that we have introduced something along
>> these lines a few years ago as a way to fight against leaks of
>> references to DOM by add-ons.
>>
>> On 3/20/14 12:39 AM, Kyle Huey wrote:
>>> Followup to dev-platform please.
>>
>>
>> --
>> David Rajchenbach-Teller, PhD
>>   Performance Team, Mozilla
>
> The issue is not leaking the DOM elements, it's leaking the (chrome)
> JS implementations themselves.  Wrapper cutting actually masks these
> leaks by stopping them from entraining entire windows past the tests
> of these features.

Does it make sense to disable wrapper cutting in (let's say) debug
builds, so that at least we catch some of these badness?

Cheers,
Ehsan

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Memory management in features implemented in JS

Steve Fink-4
In reply to this post by Kyle Huey-2
On 03/19/2014 04:39 PM, Kyle Huey wrote:
> Followup to dev-platform please.
>
> We are discovering a lot of leaks in JS implemented DOM objects.  The
> general pattern seems to be that we have a DOM object that also needs
> to listen to events from the message manager or notifications from the
> observer service, which usually hold strong references to the
> listener.

Can you give a specific example or two to chew on? Preferably something
whose lifetime would optimally be shorter than the containing window's?
Jim Blandy has been giving ideas for certain classes of problems, but I
can't tell how many realistic situations those ideas might address.
Sure, weak refs could solve them all these problems in one fell swoop,
but weak refs (or other observable GC) would also paint us into a corner
and prevent many tuning optimizations.

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine