Calling DOM APIs like querySelector, querySelectorAll or getElementsByTagName cause rapid memory growth when called with ever increasingly large strings. getElementsByTagName: Reproduces in Chrome Canary and all the way back to Chrome 22, but not in Chrome 20. I don't have Chrome 21. Does *not* reproduce in WebKit nightly (r130451 ) or Safari (6.0.1 (8536.26.14)). querySelectorAll: Reproduces in Chrome Canary all the way back to Chrome 22, but not Chrome 20 *and* WebKit Nightly r130451. I don't know why WebKit nightly sees this on QSA but not getElementsByTagName. Reproduction: 1) Open Activity Monitor.app 2) Load the test case. 3) Watch the memory grow really fast. Chrome's render process crashes rather quickly with: Google Chrome Helper(26560,0xacca1a28) malloc: *** mmap(size=8388608) failed (error code=12) *** error: can't allocate region securely *** set a breakpoint in malloc_error_break to debug WebKit nightly seems to flatten out around 2.3GB for me and doesn't crash??
Created attachment 167284 [details] Baseline memory growth This just tests memory growth of strings being appended. There's some kind of V8 or Chrome badness here, but it shows a big difference compared to the other test cases.
Created attachment 167285 [details] Webkit and Chrome This test consumes memory rapidly in both Chrome and Webkit nightly.
Created attachment 167286 [details] Chrome only This test consumes memory rapidly in Chrome but not in Webkit nightly. I'm not sure what's different here.
This is on OS X 10.8.2 non-retina.
<rdar://problem/12443926>
Is it possible that this is caused by our use of AtomicString?
(In reply to comment #6) > Is it possible that this is caused by our use of AtomicString? That seems plausible. It's also interesting because doing just regular string appends grows memory normally in shipping Safari, but as soon as you do querySelectorAll(selector) the memory growth slows way down. Is there some kind of rope compaction?
(In reply to comment #7) > (In reply to comment #6) > > Is it possible that this is caused by our use of AtomicString? > > That seems plausible. It's also interesting because doing just regular string appends grows memory normally in shipping Safari, but as soon as you do querySelectorAll(selector) the memory growth slows way down. Is there some kind of rope compaction? I don't really understand what you mean by this. Could you elaborate a little?
(In reply to comment #6) > Is it possible that this is caused by our use of AtomicString? Yes indeed. Bytes Used Count Symbol Name 1000.25 MB 50.0% 227039 WTF::fastMalloc(unsigned long) 993.27 MB 49.6% 45393 WTF::StringImpl::create(unsigned char const*, unsigned int) 993.27 MB 49.6% 45358 WTF::HashTableAddResult<WTF::HashTableIterator<WTF::StringImpl*, WTF::StringImpl*, WTF::IdentityExtractor, WTF::StringHash, WTF::HashTraits<WTF::StringImpl*>, WTF::HashTraits<WTF::StringImpl*> > > WTF::HashTable<WTF::StringImpl*, WTF::StringImpl*, WTF::IdentityExtractor, WTF::StringHash, WTF::HashTraits<WTF::StringImpl*>, WTF::HashTraits<WTF::StringImpl*> >::addPassingHashCode<WTF::HashSetTranslatorAdapter<WTF::LCharBufferTranslator>, WTF::HashTranslatorCharBuffer<unsigned char>, WTF::HashTranslatorCharBuffer<unsigned char> >(WTF::HashTranslatorCharBuffer<unsigned char> const&, WTF::HashTranslatorCharBuffer<unsigned char> const&) 993.27 MB 49.6% 45358 WTF::AtomicString::add(unsigned char const*, unsigned int) 993.27 MB 49.6% 45358 cssyyparse(WebCore::CSSParser*) 993.27 MB 49.6% 45358 WebCore::CSSParser::parseSelector(WTF::String const&, WebCore::CSSSelectorList&) 993.27 MB 49.6% 45358 WebCore::SelectorQueryCache::add(WTF::AtomicString const&, WebCore::Document*, int&) 993.27 MB 49.6% 45358 WebCore::Node::querySelector(WTF::AtomicString const&, int&) 993.27 MB 49.6% 45358 WebCore::jsDocumentPrototypeFunctionQuerySelector(JSC::ExecState*)
(In reply to comment #9) > (In reply to comment #6) > > Is it possible that this is caused by our use of AtomicString? > > Yes indeed. That, and the fact that SelectorQueryCache appears to grow without bounds.
Created attachment 168458 [details] Patch
Comment on attachment 168458 [details] Patch is bad bogs, gud poch. r=gooby.
Comment on attachment 168458 [details] Patch Attachment 168458 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14283016
Comment on attachment 168458 [details] Patch Weak sauce. Random eviction for the win: m_entries.remove(m_entries.begin());
See subimage() in GraphicsContextCG.cpp for a similar use of this idiom.
Comment on attachment 168458 [details] Patch Attachment 168458 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14260940
Committed r131209: <http://trac.webkit.org/changeset/131209>