Retention Conditions in IE10
In IE10 (Trident), memory retention occurs primarily when a circular reference crosses the boundary between the JScript engine's mark-and-sweep garbage collector and the DOM's COM-based reference counting system. Because neither collector can independently resolve a cycle that spans both environments, the objects remain allocated until the page is unloaded.
Likely Triggers for Retention
- Closure Capture: Using
attachEvent or similar handlers where the closure captures a reference to the DOM node it is attached to. The node holds the handler, and the handler's scope holds the node.
- Detached DOM Trees: Removing a node from the document does not trigger collection if a JavaScript variable or closure still references any part of that node's subtree. The entire detached tree is retained.
- Event Handlers: Long-lived event listeners that reference DOM elements within their scope, preventing the COM reference count from reaching zero.
ActiveX and Plugin Bridge Release
Objects created via ActiveX or plugin bridges are pure COM objects. While JScript will release its own reference to the object during garbage collection, the underlying COM component may maintain its own internal references or event loops.
Explicit release is recommended under the following circumstances:
- The component provides a
close(), dispose(), or unload() method.
- The object is created frequently in a long-lived single-page application (SPA) context.
- The component is known to cache references to the window or document.
To maximize the chance of release, nullify all JavaScript references to the ActiveX object immediately after calling its disposal method.
Impact of Document Mode
Document mode (controlled via X-UA-Compatible or HTTP headers) determines which version of the JScript engine and DOM implementation is used. Running in IE10 Standards Mode provides the most advanced generational garbage collection and cycle-breaking heuristics available to the Trident engine.
Switching to legacy modes (e.g., IE7 or IE8 compatibility view) reverts the engine to older JScript behaviors with significantly weaker cross-boundary cycle handling, typically increasing the frequency and severity of memory leaks.
Verification Steps
- Heap Analysis: Use a memory profiler to monitor DOM node counts. If the count grows monotonically after repeated operations (e.g., adding/removing a UI component), a circular reference is likely.
- Isolation Test: Create a minimal reproduction using
attachEvent with a closure capturing the target node; remove the node and observe if process memory stabilizes.
- Mode Comparison: Force the page into IE10 standards mode and compare the retention rate against a legacy document mode.
Note: To provide a more specific recommendation, please clarify if the retained objects are standard HTML elements or custom ActiveX components.
ie10