Intro and background material
As a first intro to JS memory management, which covers all the background concepts if you have no qualifications in programming 1. Your basic options are a mark and sweep algorithm; or a reference counting algorithm (more notes 2 ). A second source garbage collection algorithms is more focussed on this as it affects JS 3. There is a good source that I can't reference mentioned in this, as it is for 2001 MSIE. Background reading articles are 4 5, but this is only presented for concepts; as these are too old to match current operational practice. It should be noted that all webrowsers have different implementations for memory management (each OS release of the same browser is also likely to be different).
I have some notes for a previous version of this article that I write for myself in early two thousands. The tool chain is much better than then; and there is a more mature engineering approach to JS “web hackery”. There are generally two angles that are important, a) how can you manage memory use, in a established commercial asset, b) mostly for games, where you need higher performance, as its too jaggy, or erratic.
Some notes on JS performance
There are some quite good notes on how to write JS so there are few objects being created or destroyed. The author was doing animations in JS games, but the same techniques can be applied everywhere. If you have a steady memory usage, the JS interpreter doesn't need to run the garbage collector.
This article is from 2014, but quite thorough 6. It highlights a google project called web tracing framework, as likely future work. This WTF seems to be a useful tool 7 8.
Another tool mentioned is strongloop, which seems need a IBM service contact (I didn't look at the amount). As a paying product this has good docs 9. A related piece of technology is outlined in 10 describes how to detect memory leaks.
This isn't the actual focus on my article, I'm so moving on.
The Chrome browser ships with basic memory tracking tools. Open dev tools, click “Profiles”, then use the visible options. Some details 11. There is a more complex version of that at 12. Chrome uses the v8 JS engine, articles on memory usage is 13 14. A quite useful page on memory management is 15.
Firefox as a piece of software can use alot of RAM, some generic notes to manage this are listed 20. Firefox supports a custom URL of “about:memory” to list what it is doing at present. Unlike the Chrome debug tools, unless you only have a single tab open, this is hard to correlate your code to the RAM used. If you have a leaking FF plugin, this is a useful tool. A common tool for FF is Adblock, this has massive impact on memory used, discussed 21. A per-tab memory graphing tool is 22, this is reported to slow FF startup. FF has a dbg object, outlined in 23, this seems to provide a useful breakdown.
For MSIE/ Edge
These are two separate code bases. MSIE includes a debug platform, similar to firebug. It can be loaded by pressing <f12>, the most recent version is described at 24. Dev Plugins for MSIE seem rare/ or are not advertised on the open internet. With respect to Edge, this also supports the dev tools suite 25. To the best of my knowledge, Edge doesn't support plugins yet.
My usecase on this article is for tracking JS graphing tools, and updating the content every minute. If the graphs leak, this is an issue.