Open Bug 781767 Opened 7 years ago Updated 5 years ago

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


(Core :: JavaScript Engine, defect)

16 Branch
Windows 7
Not set




(Reporter: kael, Unassigned)


(Blocks 1 open bug, )


(Whiteboard: [js:p3])


(1 file)

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?
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?
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.
Bug 775994 is in the same ballpark, at least in terms of "there's a lot of it".
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).
Depends on: 781849
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.
Depends on: 778724
Re #4, the tab wasn't backgrounded since I had about:memory open in another window.
Whiteboard: [js:p3]
Blocks: JSIL
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.