936128 - Synchronously neuter large ArrayBuffers in WindowDestroyedEvent::Run

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Andrew McCreight [:mccr8]]

When a window goes away, we want to immediately free any large ArrayBuffers it contains, as these may account for a large percentage of all system memory.

I wrote a prototype patch in bug 865959 that does this by iterating over all objects in the window's compartment and freeing all ArrayBuffers.  At a minimum, this could be improved by adding a dirty bit to the compartment that indicates if we have a live large ArrayBuffer in the compartment (increment a count when one is created, decrement when one is destroyed), to avoid paying the cost when we don't have any.  Depending on how long the scan actually takes, it might be worth keeping a list of those buffers, too.

Another problem I noticed is that the actual js_free call for the ArrayBuffer is really slow, on the order of a second for a 1gb buffer, which seems bad.  Maybe there's something bad about the way I'm neutering the array?  Another thing we could do is shove this off to the sweeping thread of something like that, though doing it somewhat asynchronously risks OOMing the browser.

Comment 1

[Luke Wagner [:luke]]

What do you think about maintaining a per-Zone, lazily-created WeakMap of large ArrayBuffers?

The slow js_free is weird... I know doing many frees can be slow (esp. on mac), but I wouldn't think a single js_free would have to do that much work.

Comment 2

[Andrew McCreight [:mccr8]]

khuey pointed out that this may not really be okay to do in general, because another content window could have a reference to the ArrayBuffer.  We can probably carve out enough for the asm.js use case.

Comment 3

[Luke Wagner [:luke]]

The resolution of our discussion yesterday was that, if we do bug 936218 and bug 936236, then we won't need to do this.  This avoids the concern in comment 2 and also ensures the release of non-ArrayBuffer resources (WebGL resources, etc).  Given that, does it make sense to resolve this one WONTFIX?

Comment 4

[Nicholas Nethercote [inactive]]

WONTFIXing sounds fine to me.