John Hrvatin, the Program Manager for Internet Explorer has just written up some of the perspectives that the IE team is taking on IE memory leak issues.
nternet Explorer 7 improved the situation by releasing all references to Jscript objects attached to the DOM tree when IE navigates away from that page. This allows the Jscript engine to then garbage collect those Jscript objects and recover that memory. We’ve also made the same changes in IE6 on Windows XP SP2 (shipped originally with the June Update). However, as some web developers have pointed out, those changes don’t solve the problem entirely. IE still leaves behind anything not attached to the tree when we tear down the markup. In addition, sites that users keep open for extended periods of time, such as Web-based mail, can still cause IE’s memory usage to continually grow if the site doesn’t take care to avoid the leak patterns.
This is definitely a plus on the confidence I have on IE. Just recently, the Firefox team started to investigate on the memory leaking issues. It’s a common issue amount, i’ll say, all the browsers available today. But seeing IE team has been putting up quite an effort on trying to solve the problem makes everyone feel comfortable.
But the criticism on Jscript is still high. Remember the my post earlier regarding Gmail gets a facelift on the javascript? One thing mentioned was about a Gmail programmer reverse engineered the Jscript and was horrified to see how many hard coded object references and so on. I personally think IE team is on the right direction on solving the problem
Internet Explorer 7 improved the situation by releasing all references to Jscript objects attached to the DOM tree when IE navigates away from that page.
Memory leak in some sense is a type of logical bug. Remember the old days of programming where every cycle counts? This is the same still in today’s web application design where every bit of memory, cpu usage, and of course time execution counts. I do admit when a program gets to a certain size with many objects built in, the cross references on the objects can get very overwhelming and quickly become a memory leaking problem. In my opinion, there are two different approaches to fix the problem:
1. Quick patch by looking at leak pattern
2. Dig up all the references, either fix them from the root or rewrite the entire library
Allow me to expand these two approaches with their cons and pros.
1 Quick patch by looking at leak pattern
Pros: quickly identify the issue and resolve it. The turn around on it can be extremely fast. The patch can either be a fix on the existing code, or extra code that prevents the pattern from happening.
Cons: Since the fix only solves a particular problem based on the result of the problem, it can either mask out the real problem behind or introduce other problems. (that’s why no programmers like to be the fire fighter)
2. Dig up all the references, either fix them from the root or rewrite the entire library
Pros: To solve a problem, it’s almost not arguable to say solving it from the root is the right thing to do. In a heavily OOP structured environment, drawing out the ULM diagrams to demonstrate each possible execution path a lot of times can make the root of the problem to surface. By going down this path, you usually won’t end up introducing new problems (remember, i said usually, it all depends on how much depth you are going down and how careful you are)
Cons: In many cases, this path can take heck a lot more time than the quick patch. It involves tossing away a lot of codes and rewriting stuff from scratch. It is harder to QA the result and if not careful, new critical bugs can be introduced.
I personally think the IE team should take the second approach on the Jscript if they haven’t already. I’m pretty sure the IE team is tired of never ending quick fixes and quite frankly, we, the developer, are pretty tired of sudden changes in behavior after almost every quick patch release.
1 Response to “IEBlog: Tools for detecting memory leaks”
Leave a Reply