Bug 98498 – REGRESSION: Rapid memory growth calling DOM APIs with large strings

• Component: DOM
• Status: RESOLVED FIXED

[Elliott Sprehn]

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??

[Elliott Sprehn]

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.

[Elliott Sprehn]

Created attachment 167285 [details]
Webkit and Chrome

This test consumes memory rapidly in both Chrome and Webkit nightly.

[Elliott Sprehn]

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.

[Elliott Sprehn]

This is on OS X 10.8.2 non-retina.

[Alexey Proskuryakov]

<rdar://problem/12443926>

[Ryosuke Niwa]

Is it possible that this is caused by our use of AtomicString?

[Elliott Sprehn]

(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?

[Ryosuke Niwa]

(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?

[Andreas Kling]

(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*)

[Andreas Kling]

(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.

[Andreas Kling]

Created attachment 168458 [details]
Patch

[Anders Carlsson]

Comment on attachment 168458 [details]
Patch

is bad bogs, gud poch. r=gooby.

[Build Bot]

Comment on attachment 168458 [details]
Patch

Attachment 168458 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/14283016

[Geoffrey Garen]

Comment on attachment 168458 [details]
Patch

Weak sauce. Random eviction for the win:

m_entries.remove(m_entries.begin());

[Geoffrey Garen]

See subimage() in GraphicsContextCG.cpp for a similar use of this idiom.

[WebKit Review Bot]

Comment on attachment 168458 [details]
Patch

Attachment 168458 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14260940

[Andreas Kling]

Committed r131209: <http://trac.webkit.org/changeset/131209>