Memory cache live resources repeatedly purged during painting

• Component: Page Loading
• Status: RESOLVED FIXED

[Antti Koivisto]

On some PLT pages (like nytimes.com) we get into state where painting repeatedly purges live bitmaps. This slows down page loads significantly.

     13 WebCore::BitmapImage::draw(WebCore::GraphicsContext*, WebCore::FloatRect const&, endMode, WebCore::ImageOrientationDescription)  (in WebCore) + 447  [0x127c727]
       13 WebCore::MemoryCache::pruneLiveResourcesToSize(unsigned int, bool)  (in WebCore) + 251  
         13 WebCore::BitmapImage::destroyDecodedData(bool)  (in WebCore) + 191  [0x127acfb]
           6 WebCore::ImageSource::clear(bool, unsigned long, WebCore::SharedBuffer*, bool)  (in WebCore) + 39  
           | 6 CGImageSourceCreateIncremental  (in ImageIO) + 199  [0x250e98bb]
           |   2 _CGImageSourceCreate  (in ImageIO) + 61  [0x250abd79]
           |   + 1 CFAllocatorAllocate  (in CoreFoundation) + 95  [0x23fdea53]
           |   + 1 _CFRuntimeCreateInstance  (in CoreFoundation) + 289  [0x23fdec51]
           |   +   1 malloc_zone_malloc  (in libsystem_malloc.dylib) + 87  [0x32ae6da7]
           |   +     1 szone_malloc_should_clear  (in libsystem_malloc.dylib) + 61  [0x32ae6e19]
           |   2 _CGImageSourceCreate  (in ImageIO) + 41  [0x250abd65]
           |   1 _CGImageSourceCreate  (in ImageIO) + 157  [0x250abdd9]
           |   + 1 _pthread_mutex_init  (in libsystem_pthread.dylib) + 3  [0x32b3cadf]
           |   1 _CGImageSourceCreate  (in ImageIO) + 227  [0x250abe1f]
           |     1 CFSetCreateMutable  (in CoreFoundation) + 93  [0x23fefa75]
           |       1 CFBasicHashCreate  (in CoreFoundation) + 116  [0x23fdf594]
           |         1 _CFRuntimeCreateInstance  (in CoreFoundation) + 289  [0x23fdec51]
           |           1 malloc_zone_malloc  (in libsystem_malloc.dylib) + 87  [0x32ae6da7]
           |             1 szone_malloc_should_clear  (in libsystem_malloc.dylib) + 219  [0x32ae6eb7]
           |               1 tiny_malloc_from_free_list  (in libsystem_malloc.dylib) + 181  [0x32ae80b5]
           3 WebCore::ImageSource::clear(bool, unsigned long, WebCore::SharedBuffer*, bool)  (in WebCore) + 23  
           | 2 CFRelease  (in CoreFoundation) + 493  [0x23fe4de1]
           | + 2 _CGImageSourceFinalize  (in ImageIO) + 79  [0x250b6967]
           | +   2 CFRelease  (in CoreFoundation) + 493  [0x23fe4de1]
           | +     2 _CGImageReadFinalize  (in ImageIO) + 433  [0x250cd985]
           | +       2 CFRelease  (in CoreFoundation) + 597  [0x23fe4e49]
           | +         2 objc_object::sidetable_release(bool)  (in libobjc.A.dylib) + 163  [0x32483d5b]
           | +           1 -[WebCoreSharedBufferData dealloc]  (in WebCore) + 39  [0x1b54b3f]
           | +           ! 1 WebCoreObjCScheduleDeallocateOnMainThread(objc_class*, objc_object*)  (in WebCore) + 
           | +           !   1 _Unwind_SjLj_Register  (in libunwind.dylib) + 5  [0x32b4fae5]
           | +           1 -[WebCoreSharedBufferData dealloc]  (in WebCore) + 75  [0x1b54b63]
           | +             1 object_dispose  (in libobjc.A.dylib) + 11  [0x32472617]
           | +               1 objc_destructInstance  (in libobjc.A.dylib) + 31  [0x324725f3]
           | +                 1 object_cxxDestructFromClass(objc_object*, objc_class*)  (in libobjc.A.dylib) + 115  
           | +                   1 -[WebCoreSharedBufferData .cxx_destruct]  (in WebCore) + 37  [0x1b54c81]
           | 1 CFRelease  (in CoreFoundation) + 1253  [0x23fe50d9]
           |   1 _os_lock_handoff_lock  (in libsystem_platform.dylib) + 35  [0x32b38473]
           3 WebCore::ImageSource::clear(bool, unsigned long, WebCore::SharedBuffer*, bool)  (in WebCore) + 51  
           | 1 WebCore::SharedBuffer::createCFData()  (in WebCore) + 147  [0x1b54edf]
           | + 1 NSAllocateObject  (in Foundation) + 101  [0x24d50b55]
           | 1 WebCore::SharedBuffer::createCFData()  (in WebCore) + 203  [0x1b54f17]
           | + 1 _os_lock_handoff_trylock  (in libsystem_platform.dylib) + 35  [0x32b383cf]
           | 1 WebCore::SharedBuffer::createCFData()  (in WebCore) + 9  [0x1b54e55]
           1 WebCore::ImageSource::clear(bool, unsigned long, WebCore::SharedBuffer*, bool)  (in WebCore) + 61  
             1 CGImageSourceUpdateData  (in ImageIO) + 893  [0x250e9c59]
               1 CGImageReadCreateWithData  (in ImageIO) + 43  [0x250abb93]
                 1 CFDataGetLength  (in CoreFoundation) + 3  [0x23fdf273]

[Antti Koivisto]

<rdar://problem/20667695>

[Antti Koivisto]

Created attachment 251451 [details]
patch

[Chris Dumez]

Comment on attachment 251451 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=251451&action=review

r=me

> Source/WebCore/ChangeLog:25
> +            Decrease the pruning size targer from 0.95 to 0.8 so we don't need to prune so often.

"target"

[Antti Koivisto]

https://trac.webkit.org/r183194

[Brent Fulgham]

I'm afraid we have some new Windows crashes with this patch. I'll try to get a stack trace for you ASAP.

[Alexey Proskuryakov]

This also broke http/tests/cache/disk-cache/disk-cache-disable.html on Mac.

[Antti Koivisto]

Specifically it seems to have become flaky. 

https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK2%20(Tests)/r183196%20(3707)/results.html

I'll see what is going on.

[Alexey Proskuryakov]

Looks like this may have broken more tests, namely http/tests/ssl/referer-301.html and http/tests/ssl/referer-303.html

https://build.webkit.org/results/Apple%20Yosemite%20Release%20WK2%20(Tests)/r183202%20(4649)/results.html

Antti, are you still looking into this? I need to roll out the patch, as it's way more flakiness than we can live with.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 144121

[Alexey Proskuryakov]

Turns out that http/tests/ssl/referer-301.html and http/tests/ssl/referer-303.html failures were not caused by this.

Trying to find the culprit. It may be an issue with Xcode dependency tracking, will try a clean build.

[Alexey Proskuryakov]

The rollout did fix http/tests/cache/disk-cache/disk-cache-disable.html on Mac, and it did fix Windows crashes.

[Antti Koivisto]

Where are the crash stacks for Windows? The most likely cause is that the implementation of RunLoop::main().dispatch() is buggy (this looks like the first WebCore client for it that would run on Windows).

[Antti Koivisto]

Relanded in https://trac.webkit.org/r183261 

Fixed the test case and switched to Timer for now.

[Alexey Proskuryakov]

Everything looks good now! The referrer test failures were indeed bad code generation on incremental builds.