Summary: | REGRESSION: Rapid memory growth calling DOM APIs with large strings | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Elliott Sprehn <esprehn> | ||||||||||
Component: | DOM | Assignee: | Andreas Kling <kling> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | abarth, ap, dglazkov, ggaren, haraken, kling, mjs, morrita, rafael.lobo, rniwa, slewis, webkit.review.bot | ||||||||||
Priority: | P2 | Keywords: | HasReduction, InRadar, Regression | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | All | ||||||||||||
OS: | All | ||||||||||||
Attachments: |
|
Description
Elliott Sprehn
2012-10-05 01:50:56 PDT
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. 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> |