VM tab UI is *re-attached* to live document DC tab UI is detached from live document
DC tab UI is created and attached to live documentĪ3. VM tab UI is detached from live document VM tab UI is created and attached to live document The answer to above question is *singleton* UI components - consider following WebAdmin use-case: The important question here is if there's any JavaScript code still referencing DOM nodes *which are not currently attached to live document*, which prevents garbage collection (memory reclamation) of such DOM nodes. DOM nodes are dynamically created and attached/detached to/from DOM document tree using JavaScript. RHEV GUI (WebAdmin/UserPortal) is dynamic web application, i.e. Below are my notes on the matter.īy definition, these are "nodes that are currently not part of a live document (reachable from a window object)". Thanks to Jan Horak and Martin Stransky for looking into this issue in relation to Firefox 24 ESR. I went through all buttons in the "Free Memory" section, but it didn't seem to make any difference.Īll memory stats from Chromium and FF are attached. > memory" section, at about:memory page). > And, is there any difference if you run GC manually? (Buttons in "Free I tried Chromium 31 and it consumes about half amount of memory than FF24 does. > Also, please test different browsers (Chrome for instance). I have sent you e-mail with access to my testing machine & RHEVM instance.
> Anyway, can you please provide us a testing instance? We don't see that on > to run garbage collection more efficiently.
So it looks like a bug in the application, but upstream Firefox seems > I see the orphan-nodes size in upstream Firefox are lower but they still are > Anyway, the orphan nodes are a bug in the WebApplication. (In reply to Martin Stransky from comment #5) RHEVM - FF24 memreport with "=false" after 4 days Memory stats from FF24 ESR (with manual GC) and Chromium 31įF24 RHEVM mem usage "" comparison
0 kommentar(er)
