Maybe I'm missing something, but wouldn't simply running under valgrind be a really easy way to find lots of leaks? Granted, it only works under Linux, but I'm guessing most leaks in FF are cross-platform. Sure beats the author's suggestion of "re-invent a lot of tools that already exist".
Valgrind will tell you about stuff you malloc()d but didn't free(). That's part of what their tools do, but it won't help so much with reference counted/GCed stuff. Remember there's a lot of Javascript code in the browser itself.
After finding Firefox consuming over 1.2GB of RAM after leaving my browser and a couple tabs open overnight, I for one welcome any improvement in memory management. Of course who's to say that some rogue site was to blame for the rampant memory hogginess, but still, FF should not allow something like that.
Comments
Maybe I'm missing something, but wouldn't simply running under valgrind be a really easy way to find lots of leaks? Granted, it only works under Linux, but I'm guessing most leaks in FF are cross-platform. Sure beats the author's suggestion of "re-invent a lot of tools that already exist".
Valgrind will tell you about stuff you malloc()d but didn't free(). That's part of what their tools do, but it won't help so much with reference counted/GCed stuff. Remember there's a lot of Javascript code in the browser itself.
prewett, which are the tools that you think already exist, exactly?
Many Mozilla developers make good use of valgrind. Leaks that can be found that way often are, and rarely cause problems for long.
After finding Firefox consuming over 1.2GB of RAM after leaving my browser and a couple tabs open overnight, I for one welcome any improvement in memory management. Of course who's to say that some rogue site was to blame for the rampant memory hogginess, but still, FF should not allow something like that.
Still love ya FF!!!