Safari hangs during test262 run in CodeCache::pruneSlowCase
https://bugs.webkit.org/show_bug.cgi?id=113469

Reviewed by Geoffrey Garen.

We can end up hanging for quite some time if we add a lot of small keys to the CodeCache.
By the time we get around to pruning the cache, we have a potentially tens or hundreds of 
thousands of small entries, which can cause a noticeable hang when pruning them.

To fix this issue we added a hard cap to the number of entries in the cache because we 
could potentially have to remove every element in the map.

* runtime/CodeCache.cpp:
(JSC::CodeCacheMap::pruneSlowCase): We need to prune until we're both under the hard cap and the
capacity in bytes.
* runtime/CodeCache.h:
(CodeCacheMap):
(JSC::CodeCacheMap::numberOfEntries): Convenience accessor function to the number of entries in 
the map that does the cast to size_t of m_map.size() for us. 
(JSC::CodeCacheMap::canPruneQuickly): Checks that the total number is under the hard cap. We put this 
check inside a function to more accurately describe why we're doing the check and to abstract out 
the actual calculation in case we want to coalesce calls to pruneSlowCase in the future.
(JSC::CodeCacheMap::prune): Check the number of entries against our hard cap. If it's greater than
the cap then we need to drop down to pruneSlowCase.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147150 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin: shouldUsePDFPlugin can't use pdfLayerControllerClass() because it asserts if it's not available
https://bugs.webkit.org/show_bug.cgi?id=113533
<rdar://problem/13528720>

Reviewed by Simon Fraser.

* WebProcess/WebPage/WebPage.cpp:
* WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::shouldUsePDFPlugin):
Move shouldUsePDFPlugin to WebPageMac, where it belongs, and explicitly look up PDFLayerController
instead of using pdfLayerControllerClass(), which ASSERT()s if it isn't available.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147151 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[wk2] REGRESSION (r125500): WebFrameLoaderClient's active m_pluginView can be zeroed by PluginDocuments leaving the page cache
https://bugs.webkit.org/show_bug.cgi?id=113430
<rdar://problem/12729564>

Reviewed by Brady Eidson.

Ignore redirectDataToPlugin(0), which is only called from PluginDocument::detach(),
and only after r125500. Otherwise, PluginDocuments that are put into the page cache
but leave later can clear a totally different and legitimate PluginView from the
WebFrameLoaderClient, causing data to be lost and PluginDocument loads to stall.

This restores our behavior to the pre-r125500 state, which should be fine, as we
clear WebFrameLoaderClient's m_pluginView when the load fails or finishes. This
matches the changes made in r125500 for every platform other than Chromium and WebKit2.

* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::redirectDataToPlugin):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147152 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed.  Rolled Chromium DEPS to r191172.  Requested by
pdr2 via sheriffbot.

Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2013-03-28

* DEPS:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147153 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed rebaseline.
Adding missing baseline for new test compositing/contents-opaque/control-layer.html

* platform/chromium-mac/platform/chromium/virtual/softwarecompositing/contents-opaque/control-layer-expected.txt: Copied from LayoutTests/platform/chromium/compositing/contents-opaque/control-layer-expected.txt.
* platform/chromium-win/compositing/contents-opaque/control-layer-expected.txt: Renamed from LayoutTests/platform/chromium/compositing/contents-opaque/control-layer-expected.txt.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147154 268f45cc-cd09-0410-ab3c-d52691b4dbfc