Open Bug 1504926 Opened 3 years ago Updated 2 years ago
Asking for memory report can cause a virtual iloop comparing strings in JS Collect
+++ This bug was initially created as a clone of Bug #1441876 +++ If you do Measure in about:memory, sometimes a Content process will virtually iloop - taking minutes or even hours in the MemoryReporter. [snip] A profile shows it's spending 100% of it's time in StatsCellCallback(), and within that 67% in js::HashStringChars<> and 33% in js::EqualStringsPure() ++++ Erahm landed a patch in bug 1441876 to make hashing ropes more efficient. Unfortunately, that's not enough: https://perfht.ml/2D3Q046 It still spends *way* too much time trying to hash strings, to the point where the content process effectively locks up for minutes at a time. Now in this profile we get ~60% of the hits directly in JSRope::hash() with another ~10% in realloc/free called from hash(), and the other 28% of the time is spent in EqualStringsPure; all in JSRope::copyCharsInternal()
See also profile https://perfht.ml/2QXLkEj
Don't we collect memory reports in the wild as part of telemetry? If so, this seems like a pretty serious bug, no?
(In reply to Randell Jesup [:jesup] from comment #2) > See also profile > https://perfht.ml/2QXLkEj This profile looks more like pathological performance on an unbalanced rope: we're spending a ton of time reallocating the node stack on our way through the rope.
(In reply to Bobby Holley (:bholley) from comment #3) > Don't we collect memory reports in the wild as part of telemetry? If so, > this seems like a pretty serious bug, no? Those aren't full reports, so they shouldn't trigger this issue.
From experience, these sort of strings occur in the wild; once example I found was multiple strings in the 10-60+K range, each consisting of single chars appended one at a time to a string (or small sets of chars), leading to a huge number of nodes. It would be interesting to investigate why the WebRTC stats strings trigger this, as that should be easily repeatable. (I suspect also that a large number of these strings were created (perhaps 1/s?) but not gotten rid of before the memory report was triggered.)
Flags: needinfo?(sdetar) → needinfo?(jdemooij)
You need to log in before you can comment on or make changes to this bug.