[Webkit-unassigned] [Bug 6438] Google Reader creates AJAX-related memory leak

Tue Mar 13 23:50:46 PDT 2007

http://bugs.webkit.org/show_bug.cgi?id=6438

ggaren at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|JavaScriptCore              |WebCore JavaScript
         Resolution|                            |FIXED

------- Comment #9 from ggaren at apple.com  2007-03-13 23:50 PDT -------
Because of the sheer number of page loads, many different factors are in play
here. Let me try to break things down.

First, a gotcha: The original bug was filed using an older version of Safari
*and* an older version of Google Reader. I tested Safari 2.0.4 (419.3), TOT
Debug, and Firefox 1.5 with the latest Google Reader, then checked for
discrepancies using the older Google Reader and TOT Release.

The only significant discrepancy to report is that it's impossible to scroll
all the way to 1500 messages using the new Google Reader -- it's just too slow
to load. However, I couldn't get anything interesting to happen simply by
scrolling to 1500.

Factor 1: JavaScript objects.

        Tested by swapping between 2 text-only feeds (Reuters: Business,
Reuters: Oddly Enough).

        10.4.8 Stock Safari:
                - live JS object count grew by 1000s of objects per load
                - RPRVT grew ~1100K per load
                - ~7K JS objects remained uncollectible after closing the
window

        TOT:
                - live JS object count grew by 1000s of objects per load
                  (notably, the only objects explicitly protected from GC were
Functions)
                - RPRVT grew ~850K per load
                - 0 JS objects remained uncollectible after closing the window

        FF:
                - RPRVT grew ~700K per load

        Conclusions:
                (1) Safari 2.0 suffered from a JavaScript GC memory cycle,
fixed in TOT. 
                (2) JS objects are more memory efficient in TOT than in Safari
2.0.
                (3) Google Reader creates an unbounded set of event listeners.
This seems 
                    like a Google Reader bug.
                (4) Firefox is more memory efficient than TOT executing Google
Reader JS.
                    Without more specific data, I'm not going to read much into
that, since 
                    we know that Google often serves Safari and FF different
content, and you
                    could write a whole web browser in the time it would take
to plow through
                    their obfuscated JS.

Factor 2: WebCore object cache.

        Tested with cache size set to 4 MB (WebKitObjectCacheSizePreferenceKey
set to 
        1048576 on a 2GB system).
        Test 1: Scroll through aggregate of cars, tech, photo, and video
subscriptions.
        Test 2: Inside news subscription, open, load, scroll all around in,
then close each 
                page as you come to it, up until the China tech page.

        10.4.8 Stock Safari:
                Test 1: RPRVT grew > 150 MB
                Test 2: RPRVT grew to 58 MB*

        TOT Debug:
                Test 1: RPRVT grew > 150 MB
                Test 2: RPRVT grew to 41 MB*

        FF:
                Test 1: RPRVT grew > 150 MB

        * I don't think this number was very accurate, because many per-page
allocations
          depend on timing -- how long an animation runs, what JS executes,
etc.

        Conclusions:
                (1) Google Reader loads an infinite stream of resources into a
single document.
                    This is pathological behavior, but real, so we probably
want to work out a 
                    way to throw off-screen resources away in extreme
situations. I've filed 
                    <rdar://problem/5061904> about that.
                (2) We know that Safari 2.0 had a bug with unbounded growth in
the memory cache.
                    With so many page loads, it was probably a factor, but I
can't prove that
                    conclusively.

Factor 3: Other leaks.

        Because of its custom allocator, Safari 2.0 doesn't lend itself to leak
checking
        with the 'leaks' tool. I didn't see any significant leaks with TOT
Debug.

Factor 4: External fragmentation.
        For the most part, an application's RPRVT number does not shrink from a
high water mark.
        Your process's heap takes memory from the system but doesn't give it
back. We're considering
        ways to improve that (<rdar://problem/4990356>).

Factor X: VSIZE
        The original report shows 3.3 GB VSIZE. First, that's insane! You're
moments away from
        running out of address space completely. Second, you show only 256 MB
RPRVT, which makes
        me wonder what's taking up all that VSIZE.

        I was never able to reproduce the huge VSIZE with low RPRVT result. We
believe that 
        Safari 2.0 leaked plug-in streams. If you were playing lots of video,
that may
        have been a factor. FWIW, I see more RPRVT and VSIZE growth in Safari
2.0 than in
        TOT when playing a single YouTube video in the RSS view. It's tough to
say if that's
        a leak or just fragmentation. Also, you may have been seeing a Safari
2.0 bug that 
        was fixed as of 2.0.4.

So, to recap: This bug is a mixture of unreproducible issues, reproducible
issues that have been fixed, and reproducible issues that are tracked through
independent bug reports.

I'd be happy to field another Google Reader bug report with a very specific set
of steps to reproduce a very specific leak. Otherwise, I think I've done is as
much as I can do with this general report, so let's close it.

-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.