781767 - analysis-temporary is not temporary, and there's a lot of it

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Katelyn Gadd (:kael)]

Attachment: Screenshot of about:memory after GC/CC

As before, demo in URL is not officially released, so please keep it quiet :)

I see a *lot* of memory being used by analysis-temporary. It never goes away, even if I manually trigger GC/CC. Is this a bug, or is it just a poorly labelled bucket for things that are not temporary?

Comment 1

[Luke Wagner [:luke]]

Normally, analysis-temporary gets wiped out by a GC (as does all jit code in the compartment).  During animations (when requestAnimationFrame is set), though, we don't want to wipe out jit code (which depends on the analysis temporary), which is why it doesn't go away.

It seems like bug 778724 should really help here.  What do you see Brian?

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We could change the ShouldCleanUpEverything() function to return true for MEMORY_PRESSURE GCs. I think that would cause us to purge this stuff when manually triggering a GC. That doesn't fix the actual problem, of course.

Comment 3

[Andrew McCreight [:mccr8]]

Bug 775994 is in the same ballpark, at least in terms of "there's a lot of it".

Comment 4

[Brian Hackett [Laid off!]]

I don't see the high analysis-temporary usage after triggering a GC, but that may be because the heuristics were inactive at that point (e.g. we'll generally be collecting code from background tabs).  But luke's explanation is probably the right one.  After bug 778724 is in it will be pretty simple to purge analysis-temporary whenever we want.  That bug is currently set up to purge when a given threshold is hit, (default is 100MB, which this page doesn't come close to), but we could also do it on GC.

A separate thing is that even when a GC clears analysis-temporary data, usage will not go to zero; the bucket describes an allocator that is cleared on each GC but is then immediately refilled with certain data that has to live across collections.  Bug 778724 also improves this, by splitting the allocator in two, and memory reporting could be improved as a followup to distinguish the two allocators (the current patch gloms them together).

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

It would appear that the memory reporters already distinguish the temporary from the non-temporary stuff. So this number actually should go to zero when gcPreserveCode is false.

Comment 6

[Katelyn Gadd (:kael)]

Re #4, the tab wasn't backgrounded since I had about:memory open in another window.