Chrome fails to free memory, garbage collection doesn't occur as expected (MootoolsMochaUI library) - Stack Overflow

admin管理员组

文章数量:1339785

Background: I'm currently working on an intranet site that makes use of the MochaUI library (working from the virtual desktop demo). I'm using Mootools 1.2.4 and MochaUI 0.9.7. The windows that are opened in my "virtual desktop" implementation load their content via iframes. Some of the loaded pages are pretty hefty in terms of css and scripting, so it's important that Window objects are adequately garbage collected when the user closes a window. This is ostensibly taken care of by the library (it does do a fair job when using Firefox).

Update The originally posted question had bee overly long from subsequent edits/updates. The title wasn't accurate anymore, so I changed that as well. Also, see my answer below for a partial solution.

Here are the essential points:

1. Chrome goofs up like so:

   • Chrome fails to free up memory allocated for MochaUI window objects when they're closed. Instead, Chrome's memory usage freezes (literally) at the level reached after the window has finished loading its iframe content, setting a lower bound on memory usage until the page is refreshed.
   • Memory used by the process continues to increase with subsequent window openings/closings. Eventually, some type of cap is reached, and the memory usage stops climbing as steeply/starts to oscillate instead of jump up dramatically.
   • This problem is most apparent when the windows in question are loading fairly hefty (memory-wise) iframe content. The window I'm using for all testing purposes loads a 580 kb page (uncached) in its iframe.

2. Strangely enough, the expected garbage collection does take place, when

   • the browser is subsequently minimized
   • another tab is opened in the same browser window
   • a Memory Timeline is being recorded in Developer Tools. (edy option)
   • Does this behavior suggest any possible approaches to solving #1?

Background: I'm currently working on an intranet site that makes use of the MochaUI library (working from the virtual desktop demo). I'm using Mootools 1.2.4 and MochaUI 0.9.7. The windows that are opened in my "virtual desktop" implementation load their content via iframes. Some of the loaded pages are pretty hefty in terms of css and scripting, so it's important that Window objects are adequately garbage collected when the user closes a window. This is ostensibly taken care of by the library (it does do a fair job when using Firefox).

Update The originally posted question had bee overly long from subsequent edits/updates. The title wasn't accurate anymore, so I changed that as well. Also, see my answer below for a partial solution.

Here are the essential points:

1. Chrome goofs up like so:

   • Chrome fails to free up memory allocated for MochaUI window objects when they're closed. Instead, Chrome's memory usage freezes (literally) at the level reached after the window has finished loading its iframe content, setting a lower bound on memory usage until the page is refreshed.
   • Memory used by the process continues to increase with subsequent window openings/closings. Eventually, some type of cap is reached, and the memory usage stops climbing as steeply/starts to oscillate instead of jump up dramatically.
   • This problem is most apparent when the windows in question are loading fairly hefty (memory-wise) iframe content. The window I'm using for all testing purposes loads a 580 kb page (uncached) in its iframe.

2. Strangely enough, the expected garbage collection does take place, when

   • the browser is subsequently minimized
   • another tab is opened in the same browser window
   • a Memory Timeline is being recorded in Developer Tools. (edy option)
   • Does this behavior suggest any possible approaches to solving #1?

• google-chrome
• garbage-collection
• mootools
• javascript

Share Improve this question Follow edited Nov 2, 2010 at 17:14 freenatec asked Oct 31, 2010 at 17:12 freenatecfreenatec 57144 silver badges88 bronze badges 9

• 5 Very interesting question and good explanation. I'm not exactly sure what the culprit is, although I will warn you there's a chance that there won't be a solution. Or if there is one, not an easy one. Google takes a very lazy approach to programming. Though Chrome seems to load fastest and use least memory of every major browser, it's riddled with bugs I wouldn't dream of in Firefox or Opera. Same with Android vs. iOS. – stevendesu Commented Oct 31, 2010 at 17:16
• I posted a very detailed/lengthy version of this question on Google's Chrome Webmaster help forum and did not get a reply, so this time I decided to make it more to the point! I agree that this seems like a bug (or a quirk of how Chrome determines which objects to be garbage collected). It's as if there's a more strenuous level of garbage collection that occurs when Chrome is minimized, and my window objects aren't fully garbage by Chrome's standards, perhaps. Thanks for the ment! – freenatec Commented Oct 31, 2010 at 17:35
• 4 @steven_desu: Not only does Google take a lazy approach to programming, it also seems uttlerly apathetic towards any kind of plaints or problems its users e up with. – Will Vousden Commented Oct 31, 2010 at 19:27
• 4 It sure sounds a lot like you're trying to debug memory usage with Taskmgr.exe. Yes, the working set gets trimmed when you minimize a window. That's a measure that has nothing to do with leaks. – Hans Passant Commented Oct 31, 2010 at 20:55
• 1 you should stop right here and have a look at what's happening with mochaui first since it's been taken over by Chirs Dotty (sp?). Essentially, he has fixed and rewritten largely everything, making it in-line with mootools 1.2.5 and now 1.3. a new mochaui release is in the pipelines by the end of the year. Take a look at the threads on the google users group and check it out from github - perhaps you are fixing something that has already been addressed. – Dimitar Christoff Commented Nov 2, 2010 at 14:09

 |  Show 4 more ments

2 Answers 2

Sorted by: Reset to default 6

I'm not sure if this was tested in Windows, but if so keep in mind that whenever you minimize a window in windows it moves all data to the pagefile. When opening the window again it won't move the memory blocks back unless the program tries to access them, and thus any garbage stays in the pagefile but isn't actually collected.

If you'd automate it, it would not only slow the program down it would also not help with any memory issues.

see the following url for a bit more info

https://micksmix.wordpress./2010/01/08/why-does-task-manager-show-an-applications-memory-usage-drop-after-minimizing-it-to-the-the-taskbar/

Update
The following changes to the MochaUI closingJobs function are a big improvement over what I previously posted here. The main change is now the iframe's onunload event is manually called by changing the src property, instead of being fired when the windowEl.destroy method removes the iframe from the DOM. (got the idea from here).

If you want to use this code, just delete the existing closingJobs function and copy paste this code in its place. It should work with both 0.9.7 and 0.9.8 MochaUI, and either Mootools 1.2.4 or 1.3.

---

closingJobs: function(windowEl){        
    windowEl.setStyle('visibility', 'hidden');
    var instances = MUI.Windows.instances;
    var instance_id = windowEl.id   
    var cleanup_delay = 50;

  /*
  Reset canvases with width/height = 0.
  This pretty reliably frees a few hundred Kb of
  memory in chrome.
  */        
    instances[instance_id].canvasControlsEl.width = 0;
    instances[instance_id].canvasControlsEl.height = 0; 
    instances[instance_id].canvasEl.width = 0;
    instances[instance_id].canvasEl.height = 0;         

    if(instances[instance_id].options.loadMethod == 'iframe')
    {
 /*
 The following line determines how long to delay the execution of
 the windowEl.destroy function. The line below gives 10 milliseconds 
 per DOM element in the iframe's document.
 You could probably do just as well with a hard-coded value.
 */         
        cleanup_delay = instances[instance_id].iframeEl.contentDocument.getElementsByTagName("*").length * 10;              

 /*
 Set the Browser property in the iframe's window to Internet Explorer.
 This causes Mootools to run its purge function, which iterates over
 all the iframe document's DOM elements, removing events/attributes etc.
 Assuming you have mootools included in the iframe content.     
 */
        if(instances[instance_id].iframeEl.contentDocument.defaultView.MooTools)
        {           
            if(instances[instance_id].iframeEl.contentDocument.defaultView.MooTools.version.contains("1.3"))                
                instances[instance_id].iframeEl.contentDocument.defaultView.Browser.ie = true;
            else        
                instances[instance_id].iframeEl.contentDocument.defaultView.Browser.Engine.trident = true;
        }                   

        instances[instance_id].iframeEl.src = "javascript:false";
    }       

    MUI.cleanWindow.delay(cleanup_delay, null, windowEl);       
},  

cleanWindow: function(windowEl)
{                               
    var instances = MUI.Windows.instances;
    var instance_id = windowEl.id
    if (Browser.ie){
        windowEl.dispose();
    }
    else {
        windowEl.destroy();
    }       
    instances[instance_id].fireEvent('onCloseComplete');

 /*
 Changed - Only execute getWindowWithHighestZindex() and focusWindow() 
 functions if there will actually be open windows after the 
 current one closes.
 */
    if (instances[instance_id].options.type != 'notification' && instances.__count__ > 1){
        var newFocus = MUI.getWindowWithHighestZindex();
        MUI.focusWindow(newFocus);
    }       
    if (this.loadingWorkspace) this.windowUnload();
    if (MUI.Dock && $(MUI.options.dock) && instances[instance_id].options.type == 'window'){
        var currentButton = $(instances[instance_id].options.id + '_dockTab');
        if (currentButton != null){
            MUI.Dock.dockSortables.removeItems(currentButton).destroy();
            currentButton = null; //Is this necessary?
        }           
        MUI.Desktop.setDesktopSize();
    }

    //Changed - moved this to the end of the function.
    delete instances[instance_id];  
}

本文标签：