Changes between Version 7 and Version 8 of Memory Use


Ignore:
Timestamp:
Aug 4, 2011 11:40:58 AM (13 years ago)
Author:
tony@gonk.net
Comment:

Added formatting for readability. Tweaked a few words and phrases.

Legend:

Unmodified
Added
Removed
Modified

  • Memory Use

    v7 v8  
    55Please provide numbers for the memory use you observe.
    66
    7 On Mac: Run "Activity Monitor", and record the "RPRVT" number. (You may have to enable this column manually by right-clicking on the column headers and selecting "Private Memory".)
    8 
    9 On Windows: Run "Task Manager", and record the "Private Working Set" number. (You may have to enable this column manually. See http://cybernetnews.com/2007/11/20/cybernotes-windows-memory-usage-explained/.)
     7 '''On Mac'''::
     8    Run "Activity Monitor", and record the "RPRVT" number. (You may have to enable this column manually by right-clicking on the column headers and selecting "Private Memory".)
     9 '''On Windows'''::
     10    Run "Task Manager", and record the "Private Working Set" number. (You may have to enable this column manually. See http://cybernetnews.com/2007/11/20/cybernotes-windows-memory-usage-explained/ .)
    1011
    1112'''2. "Steps to reproduce", including OS version'''
    1213
    13 Please provide an exact set of steps that an engineer can follow in order to reproduce the numbers you report, starting with, "Launch Safari."
    14 
    15 The steps should show that memory use goes up without coming back down.
    16 
    17 The steps should employ a fixed set of web content. (It's normal for memory use to go up as you load more and more content -- that's a result of caching.)
    18 
    19 If possible, provide a reduced test case that includes just the portions of web content necessary to reproduce the behavior you report, and not any surrounding or related content. This will make debugging the issue much easier.
     14 * Please provide an exact set of steps that an engineer can follow in order to reproduce the numbers you report, starting with, "Launch Safari."
     15 * The steps should show that memory use goes up without coming back down.
     16 * The steps should employ a fixed set of web content. (It's normal for memory use to go up as you load more and more content—that's a result of caching.)
     17 * If possible, provide a reduced test case that includes just the portions of web content necessary to reproduce the behavior you report, and not any surrounding or related content. This will make debugging the issue much easier.
    2018
    2119==  Examples of good Excessive Memory Use Bugs ==
    … …  
    2927
    3028Steps to reproduce:
    31 1. Launch Safari
    32 2. Load gmail.com. Memory use: 15MB
    33 3. Click the "reload" button. Memory use: 15.5MB
    34 4. Click the "reload" button. Memory use: 16.0MB
     29 1. Launch Safari
     30 2. Load gmail.com. Memory use: 15MB
     31 3. Click the "reload" button. Memory use: 15.5MB
     32 4. Click the "reload" button. Memory use: 16.0MB
    3533
    3634After 10 reloads, memory reaches 20.0MB.
    … …  
    4341
    4442Steps to reproduce:
    45 1. Launch Safari and IE7.
     43 1. Launch Safari and IE7.
    4644
    4745Safari's memory use: 16MB.
    4846IE7's memory use: 16MB.
    4947
    50 2. Load the following URLs in tabs: cnn.com, apple.com, nytimes.com, slashdot.org, digg.com
     48 2. Load the following URLs in tabs: cnn.com, apple.com, nytimes.com, slashdot.org, digg.com
    5149
    5250Safari memory use: 38MB
    … …  
    6058
    6159Steps to reproduce:
    62 1. Launch Safari.
    63 2. Load the attached reduced test case. Memory use: 17MB.
    64 3. Click the "make an XMLHttpRequest" button. Memory use: 17.165MB.
    65 4. Click the "make an XMLHttpRequest" button. Memory use: 17.330MB.
     60 1. Launch Safari.
     61 2. Load the attached reduced test case. Memory use: 17MB.
     62 3. Click the "make an XMLHttpRequest" button. Memory use: 17.165MB.
     63 4. Click the "make an XMLHttpRequest" button. Memory use: 17.330MB.
    6664
    6765After 10 clicks, memory use reaches 18.65MB.
    … …  
    7270Use a debug build of WebKit. It will give you more diagnostic information.
    7371
    74 On Windows: Launch Safari from the cygwin terminal, with standard output enabled: Tools/Scripts/run-safari --debug 2>&1 | cat
     72 '''On Mac'''::
     73    Launch Safari from the terminal: `Tools/Scripts/run-safari --debug`
     74 '''On Windows'''::
     75    Launch Safari from the cygwin terminal, with standard output enabled: `Tools/Scripts/run-safari --debug 2>&1 | cat`
    7576
    76 On Mac: Launch Safari from the terminal: Tools/Scripts/run-safari --debug
    77 
    78 Having reproduced the bug, follow these steps in order, to diagnose common causes of memory use:
     77Having reproduced the bug, follow these steps in order to diagnose common memory use culprits:
    7978
    8079'''1. Close all windows'''
    8180
    82 On Windows: Open a dummy empty window. Close all other windows. (Closing all windows would quit Safari.)
    83 
    84 On Mac: Close all windows.
     81 '''On Mac'''::
     82    Open a dummy empty window. Close all other windows. (Closing all windows would quit Safari.)
     83 '''On Windows'''::
     84    Close all windows.
    8585
    8686Record whether the memory use number returned to normal.
    8787
    88 On Mac: Record whether you saw a "World Leak" dialog.
    89 
    90 On Windows: Using the debugger, open a watch window for WebViewCount, WebFrameViewCount, and WebFrameCount. Each count should be 1 (representing your empty window). For a broader perspective, you can also watch gClassCount, which counts all classes in the WebKit API.
     88 '''On Mac'''::
     89    Record whether you saw a "World Leak" dialog.
     90 '''On Windows'''::
     91    Using the debugger, open a watch window for WebViewCount, WebFrameViewCount, and WebFrameCount. Each count should be 1 (representing your empty window). For a broader perspective, you can also watch gClassCount, which counts all classes in the WebKit API.
    9192
    9293'''2. Check the JavaScript object footprint'''
    9394
    94 Select Debug -> Show Caches Window.
    95 
    96 Click the "Garbage Collect JavaScript Objects" button.
    97 
    98 Record whether the memory use number returned to normal.
    99 
    100 Record whether the "Total Objects", "Global Objects", and "Protected Objects" counts in the "JavaScript Objects" box returned to 0.
     95 * Select Debug ▶ Show Caches Window.
     96 * Click the "Garbage Collect JavaScript Objects" button.
     97 * Record whether the memory use number returned to normal.
     98 * Record whether the "Total Objects", "Global Objects", and "Protected Objects" counts in the "JavaScript Objects" box returned to 0.
    10199
    102100'''3. Check the cache footprint'''
    103101
    104 Select Debug -> Show Caches Window.
     102 * Select Debug ▶ Show Caches Window.
     103 * Click the "Empty WebCore Cache" button. Record whether the memory use number returned to normal.
     104 * Click the "Empty NSURLCache" button. Record whether the memory use number returned to normal.
     105 * Click the "Purge Inactive Font Data" button. Record whether the memory use number returned to normal.
    105106
    106 Click the "Empty WebCore Cache" button. Record whether the memory use number returned to normal.
     107'''4. Check for leaks (I)'''
    107108
    108 Click the "Empty NSURLCache" button. Record whether the memory use number returned to normal.
     109 * Quit the application.
     110 * Record any "LEAK: " messages you see in the terminal.
     111  * '''NOTE:''' This step will yield false positives until we fix the fast teardown / GC bug.
    109112
    110 Click the "Purge Inactive Font Data" button. Record whether the memory use number returned to normal.
     113'''4.1 Check for leaks (II - Mac only)'''
    111114
    112 '''4. Check for leaks - I'''
     115 * Relaunch Safari with malloc logging enabled: `MallocStackLogging=1 ./Safari.app/Contents/MacOS/Safari`.
     116 * After reproducing the bug, run the `leaks` command-line tool, and record the "Process X: Y leaks for Z total leaked bytes" line, along with backtraces from substantial leaks.
    113117
    114 Quit the application. Record any "LEAK: " messages you see in the terminal.
    115 
    116 * This step will yield false positives until we fix the fast teardown / GC bug.
    117 
    118 '''5. Check for leaks - II (Mac only)'''
    119 
    120 Relaunch Safari with malloc logging enabled: MallocStackLogging=1 ./Safari.app/Contents/MacOS/Safari.
    121 
    122 After reproducing the bug, run the "leaks" command-line tool, and record the "Process X: Y leaks for Z total leaked bytes" line, along with backtraces from substantial leaks.
    123 
    124 '''6. Try the hard stuff'''
     118'''5. Try the hard stuff'''
    125119
    126120The steps above cover common causes of memory use. If none of them reveals the culprit, you'll need to dig deeper.
    127121
    128 On Windows: Use umdh.exe to track down who's using memory and why.
     122 '''On Mac'''::
     123    Use `malloc_history` to track down who's using memory and why.
     124 '''On Windows'''::
     125    Use `umdh.exe` to track down who's using memory and why.
    129126
    130 On Mac: Use malloc_history to track down who's using memory and why.
    131127
    132 You can google for more information about these tools. We hope to have detailed instructions for using them, along with helper tools, soon.
     128You can Google for more information about these tools. We hope to have detailed instructions for using them, along with helper tools, soon.