385322 - Better scheduling of cycle collection/gc

Status: RESOLVED DUPLICATE of bug 373462

(Core :: DOM: Events, defect)

Description

[Alessandro Curci]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070615 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070615 Minefield/3.0a6pre

with both 20070615 Minefield and Gran Paradiso a5 I see a huge memory leak with this test.

Reproducible: Always

Steps to Reproduce:
just launch the test and look at memory consumption.
I'm using FF in safe mode with default theme, and MS Process Explorer to graph leaks.
Actual Results:  
memory consumption grows indefinitely at a 76MB/minute rate


Expected Results:  
Firefox 2.0.0.5 plays nice with this, freeing memory at regular intervals,
and seems also to be "JS kiddie programmers friendly", as if event handlers are not removed at all before removing elements, memory is freed up the same.


This test clearly shows an odd behaviour that needs to be fixed.

Comment 1

[Steve England [:stevee]]

Attachment: testcase from reporter's URL

Comment 2

[Steve England [:stevee]]

Attachment: Analysis from leak-gauge.pl

Leak-gauge.pl reports no leakage with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.5pre) Gecko/2007053104 BonEcho/2.0.0.5pre

But it does report leakage with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/20070620 Minefield/3.0a6pre ID:2007062013

Comment 3

[Alessandro Curci]

I can confirm the bug with Gran Paradiso a5 running on Linux, using top to monitor memory consumption.

Similary as described on #385329 I notice that closing the testcase page frees few memory, so i'm guessing if or not a page based mark is already put on memory resouces in favour of a garbage collector logic that clears relative marked memory in any case when a corresponding page is closed.

I hope not to be out of context here, as i'm guessing top-down and know nothing about garbage collector implemented strategies.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not seeing leaks reported by leak-gauge.

Comment 5

[Jo Hermans]

Alexandro, memory leaks are not measured with the "Windows Task Manager" or with "top". That only shows the total amount of memory allocated by the process. Memory that is freed, is still present in the application, and will be used the next time the application needs it. Only a small amount (if any) might be released to the OS again, if that is supported by the memory manager (not all of them do). To make matters worse, the Windows Task Manager shows by default a different number, which might is smaller than the amount of actual process memory.

You can not assume that closing a tab will automatically release all the memory back to the OS, and that it would be visible externally. That's why Mozilla developers uses different tools, which really report what's going on. You can observe a part of it (only the memory cache) by looking at about:cache. But keep in mind that there's also a cache that remembers content of pages after they're closed, so that can be quickly reopened. In particular, closing a tab won't have much effect. That's normal !

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Seeing persistent memory growth in top is a sign of a bug; that's why I confirmed it.

Comment 7

[Steve England [:stevee]]

(In reply to comment #4)
> I'm not seeing leaks reported by leak-gauge.

You're right. I was running this testcase by loading it in a new tab from the bookmarks toolbar, and closing the tab and then exiting firefox. This is what appears to be causing the leak I saw with leak-gauge.pl here; filed bug 385376.

Comment 8

[Alessandro Curci]

Attachment: same testcase + interface to play/pause and change elements/interval

Comment 9

[Alessandro Curci]

Thanks Jo, in the light of your explaination I tried myself still using the same rude tools and found the following:

closing the testcase tab under *Windows* with both FF2 & FF3 shows that more or less the whole memory increment is released immediately.

closing the testcase tab under *Linux* with both FF2 & FF3 doesn't show any immediate memory release, then if I launch the testcase again the memory usage doesn't grow anymore until the testcase uses more memory than currently allocated, and If I close the test again FF2/3 progressively release memory as other applications ask resources to the system.

Anyway, while FF2 is topping memory usage at about 45/60MB both on windows and linux, FF3 asks the system more and more memory, and in the long run the system hangs.

I wasn't able to crash FF3 (good!) when it was eating around 100% of RAM, with systems hanging and disks swapping in my boxes (P3-850, 512MB debian, P4-2.8, 1GB XP), anyway closing FF freezed the system for somewhile (about 1 minute), I guess because then working hard to release such huge piece of ram.

FF2 here never goes in such state.

If this is a case of different implemented strategies (pardon me for the continued guessing, just trying to help ;-) as ,may be, releasing memory on exit saves some CPU cycles while running, I'd evaluate if the mix of two wins, then, upon a treshold of total memory usage start to progressively release some memory to don't reach the point where the system hangs.

Sorry again for the guessing, i haven't budget in knowledge and time to curious around in FF sources, but i'm experiencing on the XUL JS side of the thing and care of it.

Thanks

Comment 10

[Johnny Stenback (:jst)]

Jonas thinks this has to do with changes in some of the event code from using dbaron's GC participant code to using strong references and relying on the cycle collector collecting the cycles. It would be interesting to know if running this testcase shows the increase in memory if another browser window is used at the same time to load random webpages in it (to trigger cycle collections). Could anyone test and report back?

Comment 11

[Alessandro Curci]

(In reply to comment #10)
> Jonas thinks this has to do with changes in some of the event code from using
> dbaron's GC participant code to using strong references and relying on the
> cycle collector collecting the cycles. It would be interesting to know if
> running this testcase shows the increase in memory if another browser window is
> used at the same time to load random webpages in it (to trigger cycle
> collections). Could anyone test and report back?

Johnny, I can confirm that while browsing other websites continuosly on other tabs or windows memory is released, running the testcase with 20070629  both on Linux and Windows platforms.

With this edge case I just can't go away for a coffee break ;-)

Seriously, this memleak could unlikely happen, I can just think this could be a problem for an unaware user writing a long blog post or email not saving drafts (on a webapp that doesn't autosave), while having a really badly wroten script running on another tab.

What about releasing memory at longer intervals (in respect to FF2) when last triggered memory release becomes too old?

 

Comment 12

[Johnny Stenback (:jst)]

Thanks for the feedback. Resummarising the bug and marking blocker.

Comment 14

[Johnny Stenback (:jst)]

Duping this against bug 373462 as this should be fixed by the work going on in that bug.