Title: [221464] trunk/Source/WebCore
Revision 221464
Author akl...@apple.com
Date 2017-08-31 18:17:16 -0700 (Thu, 31 Aug 2017)
Log Message
Element focus appearance update should be either immediate or a post-layout task
https://bugs.webkit.org/show_bug.cgi?id=176193
Reviewed by Antti Koivisto.
This change removes an old mechanism for avoiding element focus appearance updates
while we might be in the middle of attaching a renderer.
Focus appearance updates depend on a clean layout, since they want to be able to
scroll the element into the visible viewport if needed.
We now simply do the updates either immediately after layout in Element::focus(),
or as a post-layout callback when needed for HTMLInputElement::didAttachRenderers().
* dom/Document.cpp:
(WebCore::Document::Document):
(WebCore::Document::updateFocusAppearanceSoon): Deleted.
(WebCore::Document::cancelFocusAppearanceUpdate): Deleted.
(WebCore::Document::updateFocusAppearanceTimerFired): Deleted.
* dom/Document.h:
* dom/Element.cpp:
(WebCore::Element::focus):
(WebCore::Element::blur):
(WebCore::Element::clearStyleDerivedDataBeforeDetachingRenderer):
(WebCore::Element::updateFocusAppearanceAfterAttachIfNeeded): Deleted.
(WebCore::Element::cancelFocusAppearanceUpdate): Deleted.
* dom/Element.h:
* dom/ElementRareData.h:
(WebCore::ElementRareData::ElementRareData):
(WebCore::ElementRareData::needsFocusAppearanceUpdateSoonAfterAttach const): Deleted.
(WebCore::ElementRareData::setNeedsFocusAppearanceUpdateSoonAfterAttach): Deleted.
* html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::didAttachRenderers):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
trunk/Source/WebCore/dom/Document.h
trunk/Source/WebCore/dom/Element.cpp
trunk/Source/WebCore/dom/Element.h
trunk/Source/WebCore/dom/ElementRareData.h
trunk/Source/WebCore/html/HTMLInputElement.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (221463 => 221464)
--- trunk/Source/WebCore/ChangeLog 2017-09-01 00:36:53 UTC (rev 221463)
+++ trunk/Source/WebCore/ChangeLog 2017-09-01 01:17:16 UTC (rev 221464)
@@ -1,3 +1,38 @@
+2017-08-31 Andreas Kling
+
+Element focus appearance update should be either immediate or a post-layout task
+https://bugs.webkit.org/show_bug.cgi?id=176193
+
+Reviewed by Antti Koivisto.
+
+This change removes an old mechanism for avoiding element focus appearance updates
+while we might be in the middle of attaching a renderer.
+
+Focus appearance updates depend on a clean layout, since they want to be able to
+scroll the element into the visible viewport if needed.
+We now simply do the updates either immediately after layout in Element::focus(),
+or as a post-layout callback when needed for HTMLInputElement::didAttachRenderers().
+
+* dom/Document.cpp:
+(WebCore::Document::Document):
+(WebCore::Document::updateFocusAppearanceSoon): Deleted.
+(WebCore::Document::cancelFocusAppearanceUpdate): Deleted.
+(WebCore::Document::updateFocusAppearanceTimerFired): Deleted.
+* dom/Document.h:
+* dom/Element.cpp:
+(WebCore::Element::focus):
+(WebCore::Element::blur):
+(WebCore::Element::clearStyleDerivedDataBeforeDetachingRenderer):
+(WebCore::Element::updateFocusAppearanceAfterAttachIfNeeded): Deleted.
+(WebCore::Element::cancelFocusAppearanceUpdate): Deleted.
+* dom/Element.h:
+* dom/ElementRareData.h:
+(WebCore::ElementRareData::ElementRareData):
+(WebCore::ElementRareData::needsFocusAppearanceUpdateSoonAfterAttach const): Deleted.
+(WebCore::ElementRareData::setNeedsFocusAppearanceUpdateSoonAfterAttach): Deleted.
+* html/HTMLInputElement.cpp:
+(WebCore::HTMLInputElement::didAttachRenderers):
+
2017-08-31 Don Olmstead
[CMake] Make USE_CF conditional within Windows
Modified: trunk/Source/WebCore/dom/Document.cpp (221463 => 221464)
--- trunk/Source/WebCore/dom/Document.cpp 2017-09-01 00:36:53 UTC (rev 221463)
+++ trunk/Source/WebCore/dom/Document.cpp 2017-09-01 01:17:16 UTC (rev 221464)
@@ -461,7 +461,6 @@
, m_visitedLinkState(std::make_unique(*this))
, m_markers(std::make_unique(*this))
, m_styleRecalcTimer([this] { updateStyleIfNeeded(); })
-, m_updateFocusAppearanceTimer(*this, ::updateFocusAppearanceTimerFired)
, m_documentCreationTime(MonotonicTime::now())
, m_scriptRunner(std::make_unique(*this))
, m_moduleLoader(std::make_unique(*this))
@@ -5480,29 +5479,6 @@
m_pendingStateObject = WTFMove(stateObject);
}
-void Document::updateFocusAppearanceSoon(SelectionRestorationMode mode)
-{
-m_updateFocusAppearanceRestoresSelection = mode;
-if (!m_updateFocusAppearanceTimer.isActive())
-m_updateFocusAppearanceTimer.startOneShot(0_s);
-}
-
-void Document::cancelFocusAppearanceUpdate()
-{
-
Title: [219296] trunk
Revision 219296
Author akl...@apple.com
Date 2017-07-10 10:03:14 -0700 (Mon, 10 Jul 2017)
Log Message
REGRESSION(r210226): Keyboard-focused element not preserved when navigating back through page cache, causing multiple elements to have focus
https://bugs.webkit.org/show_bug.cgi?id=174302
Reviewed by Antti Koivisto.
Source/WebCore:
Don't clear the active/hovered/focused elements when destroying the render tree,
since we might need to reconstruct it later, and would like to remember which
elements those were.
Only the focused state actually stuck when going in and out of the page cache,
but this patch removes all the element pointer clearing for consistency.
Test: fast/history/page-cache-element-state-focused.html
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree):
LayoutTests:
* fast/history/page-cache-element-state-focused-expected.html: Added.
* fast/history/page-cache-element-state-focused.html: Added.
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
Added Paths
trunk/LayoutTests/fast/history/page-cache-element-state-focused-expected.html
trunk/LayoutTests/fast/history/page-cache-element-state-focused.html
Diff
Modified: trunk/LayoutTests/ChangeLog (219295 => 219296)
--- trunk/LayoutTests/ChangeLog 2017-07-10 16:23:19 UTC (rev 219295)
+++ trunk/LayoutTests/ChangeLog 2017-07-10 17:03:14 UTC (rev 219296)
@@ -1,3 +1,14 @@
+2017-07-10 Andreas Kling
+
+REGRESSION(r210226): Keyboard-focused element not preserved when navigating back through page cache, causing multiple elements to have focus
+https://bugs.webkit.org/show_bug.cgi?id=174302
+
+
+Reviewed by Antti Koivisto.
+
+* fast/history/page-cache-element-state-focused-expected.html: Added.
+* fast/history/page-cache-element-state-focused.html: Added.
+
2017-07-10 Zalan Bujtas
Block of text is missing in iBooks sample books.
Added: trunk/LayoutTests/fast/history/page-cache-element-state-focused-expected.html (0 => 219296)
--- trunk/LayoutTests/fast/history/page-cache-element-state-focused-expected.html (rev 0)
+++ trunk/LayoutTests/fast/history/page-cache-element-state-focused-expected.html 2017-07-10 17:03:14 UTC (rev 219296)
@@ -0,0 +1,20 @@
+
+
+
+
+a:focus {
+background: yellow;
+}
+
+
+function runTest() {
+document.getElementById("a3").focus();
+}
+
+
+
+
+
Added: trunk/LayoutTests/fast/history/page-cache-element-state-focused.html (0 => 219296)
--- trunk/LayoutTests/fast/history/page-cache-element-state-focused.html (rev 0)
+++ trunk/LayoutTests/fast/history/page-cache-element-state-focused.html 2017-07-10 17:03:14 UTC (rev 219296)
@@ -0,0 +1,37 @@
+
+
+
+
+a:focus {
+background: yellow;
+}
+
+
+function runTest() {
+if (window.testRunner) {
+testRunner.overridePreference("WebKitUsesPageCachePreferenceKey", 1);
+testRunner.waitUntilDone();
+}
+
+window._onpageshow_ = function(e) {
+if (e.persisted) {
+document.getElementById("a3").focus();
+if (window.testRunner)
+testRunner.notifyDone();
+} else {
+document.getElementById("a2").focus();
+}
+};
+
+setTimeout(function() {
+window.location.href = "" _onload_='history.back()'>
";
+}, 0);
+}
+
+
+
+
+
Modified: trunk/Source/WebCore/ChangeLog (219295 => 219296)
--- trunk/Source/WebCore/ChangeLog 2017-07-10 16:23:19 UTC (rev 219295)
+++ trunk/Source/WebCore/ChangeLog 2017-07-10 17:03:14 UTC (rev 219296)
@@ -1,3 +1,23 @@
+2017-07-10 Andreas Kling
+
+REGRESSION(r210226): Keyboard-focused element not preserved when navigating back through page cache, causing multiple elements to have focus
+https://bugs.webkit.org/show_bug.cgi?id=174302
+
+
+Reviewed by Antti Koivisto.
+
+Don't clear the active/hovered/focused elements when destroying the render tree,
+since we might need to reconstruct it later, and would like to remember which
+elements those were.
+
+Only the focused state actually stuck when going in and out of the page cache,
+but this patch removes all the element pointer clearing for consistency.
+
+Test: fast/history/page-cache-element-state-focused.html
+
+* dom/Document.cpp:
+(WebCore::Document::destroyRenderTree):
+
2017-07-10 Daniel Bates
REGRESSION (r218616): Cannot build WebCore for macOS 10.12 with macOS 10.13 SDK
Modified: trunk/Source/WebCore/dom/Document.cpp (219295 => 219296)
--- trunk/Source/WebCore/dom/Document.cpp 2017-07-10 16:23:19 UTC (rev 219295)
+++ trunk/Source/WebCore/dom/Document.cpp 2017-07-10 17:03:14 UTC
Title: [219108] trunk/Source/WebCore
Revision 219108
Author akl...@apple.com
Date 2017-07-03 16:44:39 -0700 (Mon, 03 Jul 2017)
Log Message
Null RenderLayer* deref in FrameView::adjustTiledBackingCoverage()
https://bugs.webkit.org/show_bug.cgi?id=174106
Reviewed by Tim Horton.
I haven't been able to reproduce this crash locally, but I have seen
video of someone who can, so here's a null check for the RenderView::layer()
which could be null if we're called between RenderView construction
and the first callback to RenderLayerModelObject::styleDidChange().
* page/FrameView.cpp:
(WebCore::FrameView::adjustTiledBackingCoverage):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/FrameView.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (219107 => 219108)
--- trunk/Source/WebCore/ChangeLog 2017-07-03 23:34:46 UTC (rev 219107)
+++ trunk/Source/WebCore/ChangeLog 2017-07-03 23:44:39 UTC (rev 219108)
@@ -1,3 +1,19 @@
+2017-07-03 Andreas Kling
+
+Null RenderLayer* deref in FrameView::adjustTiledBackingCoverage()
+https://bugs.webkit.org/show_bug.cgi?id=174106
+
+
+Reviewed by Tim Horton.
+
+I haven't been able to reproduce this crash locally, but I have seen
+video of someone who can, so here's a null check for the RenderView::layer()
+which could be null if we're called between RenderView construction
+and the first callback to RenderLayerModelObject::styleDidChange().
+
+* page/FrameView.cpp:
+(WebCore::FrameView::adjustTiledBackingCoverage):
+
2017-07-03 Matt Rajca
Add/remove appropriate media element behavior restrictions when updateWebsitePolicies is called
Modified: trunk/Source/WebCore/page/FrameView.cpp (219107 => 219108)
--- trunk/Source/WebCore/page/FrameView.cpp 2017-07-03 23:34:46 UTC (rev 219107)
+++ trunk/Source/WebCore/page/FrameView.cpp 2017-07-03 23:44:39 UTC (rev 219108)
@@ -2937,7 +2937,7 @@
enableSpeculativeTilingIfNeeded();
RenderView* renderView = this->renderView();
-if (renderView && renderView->layer()->backing())
+if (renderView && renderView->layer() && renderView->layer()->backing())
renderView->layer()->backing()->adjustTiledBackingCoverage();
#if PLATFORM(IOS)
if (LegacyTileCache* tileCache = legacyTileCache())
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [218669] trunk/Source
Revision 218669
Author akl...@apple.com
Date 2017-06-21 18:09:26 -0700 (Wed, 21 Jun 2017)
Log Message
Increase memory kill limits for WebContent processes that manage multiple tabs.
https://bugs.webkit.org/show_bug.cgi?id=173674
Reviewed by Geoffrey Garen.
Source/WebCore:
Plumb the non-utility Page count down to WTF::MemoryPressureHandler.
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::~Page):
Source/WTF:
When opening links, we currently have to use the same WebContent
process for the new tab, to support scripting the window.opener object.
This means that some WebContent processes end up hosting multiple tabs, making it
more likely that those processes will hit the memory limits.
Address this by adding some additional allowance for multi-tab processes:
For each additional tab, up to 4 tabs, add 1GB to the memory kill limit.
* wtf/MemoryPressureHandler.cpp:
(WTF::thresholdForMemoryKillWithProcessState):
(WTF::MemoryPressureHandler::setTabCount):
(WTF::MemoryPressureHandler::thresholdForMemoryKill):
(WTF::MemoryPressureHandler::measurementTimerFired):
* wtf/MemoryPressureHandler.h:
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/MemoryPressureHandler.cpp
trunk/Source/WTF/wtf/MemoryPressureHandler.h
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/Page.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (218668 => 218669)
--- trunk/Source/WTF/ChangeLog 2017-06-22 00:56:02 UTC (rev 218668)
+++ trunk/Source/WTF/ChangeLog 2017-06-22 01:09:26 UTC (rev 218669)
@@ -1,3 +1,26 @@
+2017-06-21 Andreas Kling
+
+Increase memory kill limits for WebContent processes that manage multiple tabs.
+https://bugs.webkit.org/show_bug.cgi?id=173674
+
+Reviewed by Geoffrey Garen.
+
+When opening links, we currently have to use the same WebContent
+process for the new tab, to support scripting the window.opener object.
+This means that some WebContent processes end up hosting multiple tabs, making it
+more likely that those processes will hit the memory limits.
+
+Address this by adding some additional allowance for multi-tab processes:
+
+For each additional tab, up to 4 tabs, add 1GB to the memory kill limit.
+
+* wtf/MemoryPressureHandler.cpp:
+(WTF::thresholdForMemoryKillWithProcessState):
+(WTF::MemoryPressureHandler::setTabCount):
+(WTF::MemoryPressureHandler::thresholdForMemoryKill):
+(WTF::MemoryPressureHandler::measurementTimerFired):
+* wtf/MemoryPressureHandler.h:
+
2017-06-21 Chris Dumez
Allow constructing a WTF:Function from a function pointer
Modified: trunk/Source/WTF/wtf/MemoryPressureHandler.cpp (218668 => 218669)
--- trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-06-22 00:56:02 UTC (rev 218668)
+++ trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-06-22 01:09:26 UTC (rev 218669)
@@ -81,21 +81,34 @@
}
#endif
-static size_t thresholdForMemoryKillWithProcessState(WebsamProcessState processState)
+static size_t thresholdForMemoryKillWithProcessState(WebsamProcessState processState, unsigned tabCount)
{
#if CPU(X86_64) || CPU(ARM64)
+size_t baseThreshold;
if (processState == WebsamProcessState::Active)
-return 4 * GB;
-return 2 * GB;
+baseThreshold = 4 * GB;
+else
+baseThreshold = 2 * GB;
+if (tabCount <= 1)
+return baseThreshold;
+return baseThreshold + (std::min(tabCount - 1, 4u) * 1 * GB);
#else
UNUSED_PARAM(processState);
+UNUSED_PARAM(tabCount);
return 3 * GB;
#endif
}
+void MemoryPressureHandler::setTabCount(unsigned tabCount)
+{
+if (singleton().m_tabCount == tabCount)
+return;
+singleton().m_tabCount = tabCount;
+}
+
size_t MemoryPressureHandler::thresholdForMemoryKill()
{
-return thresholdForMemoryKillWithProcessState(m_processState);
+return thresholdForMemoryKillWithProcessState(m_processState, m_tabCount);
}
static size_t thresholdForPolicy(MemoryUsagePolicy policy)
@@ -176,7 +189,7 @@
break;
}
-if (processState() == WebsamProcessState::Active && footprint.value() > thresholdForMemoryKillWithProcessState(WebsamProcessState::Inactive))
+if (processState() == WebsamProcessState::Active && footprint.value() > thresholdForMemoryKillWithProcessState(WebsamProcessState::Inactive, m_tabCount))
doesExceedInactiveLimitWhileActive();
else
doesNotExceedInactiveLimitWhileActive();
Modified: trunk/Source/WTF/wtf/MemoryPressureHandler.h (218668 => 218669)
--- trunk/Source/WTF/wtf/MemoryPressureHandler.h 2017-06-22 00:56:02 UTC (rev 218668)
+++ trunk/Source/WTF/wtf/MemoryPressureHandler.h 2017-06-22 01:09:26 UTC (rev 218669)
@@ -147,6 +147,8 @@
WTF_EXPORT_PRIVATE void setProcessState(WebsamProcessState);
WebsamProcessState processState() const { return m_processState; }
+
Title: [218643] trunk
Revision 218643
Author akl...@apple.com
Date 2017-06-21 12:49:11 -0700 (Wed, 21 Jun 2017)
Log Message
[iOS] Ensure that GraphicsServices is initialized before calling GSFontPurgeFontCache().
https://bugs.webkit.org/show_bug.cgi?id=173616
Reviewed by Chris Dumez.
Source/WebCore:
Fix for crash in GSFontPurgeFontCache() seen in apps embedding WebKit.
Ensure GSFontInitialize() has been called first, since the former depends on state
set up by this function.
* page/cocoa/MemoryReleaseCocoa.mm:
(WebCore::platformReleaseMemory):
* platform/spi/ios/GraphicsServicesSPI.h:
WebKitLibraries:
* WebKitPrivateFrameworkStubs/iOS/10/GraphicsServices.framework/GraphicsServices.tbd:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm
trunk/Source/WebCore/platform/spi/ios/GraphicsServicesSPI.h
trunk/WebKitLibraries/ChangeLog
trunk/WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/10/GraphicsServices.framework/GraphicsServices.tbd
Diff
Modified: trunk/Source/WebCore/ChangeLog (218642 => 218643)
--- trunk/Source/WebCore/ChangeLog 2017-06-21 18:54:45 UTC (rev 218642)
+++ trunk/Source/WebCore/ChangeLog 2017-06-21 19:49:11 UTC (rev 218643)
@@ -1,3 +1,19 @@
+2017-06-21 Andreas Kling
+
+[iOS] Ensure that GraphicsServices is initialized before calling GSFontPurgeFontCache().
+https://bugs.webkit.org/show_bug.cgi?id=173616
+
+
+Reviewed by Chris Dumez.
+
+Fix for crash in GSFontPurgeFontCache() seen in apps embedding WebKit.
+Ensure GSFontInitialize() has been called first, since the former depends on state
+set up by this function.
+
+* page/cocoa/MemoryReleaseCocoa.mm:
+(WebCore::platformReleaseMemory):
+* platform/spi/ios/GraphicsServicesSPI.h:
+
2017-06-21 Antoine Quint
Add logging to identify when the Page suspends scripted animations
Modified: trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm (218642 => 218643)
--- trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm 2017-06-21 18:54:45 UTC (rev 218642)
+++ trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm 2017-06-21 19:49:11 UTC (rev 218643)
@@ -43,6 +43,8 @@
void platformReleaseMemory(Critical)
{
#if PLATFORM(IOS) && !PLATFORM(IOS_SIMULATOR)
+// FIXME: Remove this call to GSFontInitialize() once is fixed.
+GSFontInitialize();
GSFontPurgeFontCache();
#endif
Modified: trunk/Source/WebCore/platform/spi/ios/GraphicsServicesSPI.h (218642 => 218643)
--- trunk/Source/WebCore/platform/spi/ios/GraphicsServicesSPI.h 2017-06-21 18:54:45 UTC (rev 218642)
+++ trunk/Source/WebCore/platform/spi/ios/GraphicsServicesSPI.h 2017-06-21 19:49:11 UTC (rev 218643)
@@ -41,6 +41,7 @@
void GSInitialize(void);
uint64_t GSCurrentEventTimestamp(void);
CFStringRef GSSystemRootDirectory(void);
+void GSFontInitialize(void);
void GSFontPurgeFontCache(void);
WTF_EXTERN_C_END
Modified: trunk/WebKitLibraries/ChangeLog (218642 => 218643)
--- trunk/WebKitLibraries/ChangeLog 2017-06-21 18:54:45 UTC (rev 218642)
+++ trunk/WebKitLibraries/ChangeLog 2017-06-21 19:49:11 UTC (rev 218643)
@@ -1,3 +1,13 @@
+2017-06-21 Andreas Kling
+
+[iOS] Ensure that GraphicsServices is initialized before calling GSFontPurgeFontCache().
+https://bugs.webkit.org/show_bug.cgi?id=173616
+
+
+Reviewed by Chris Dumez.
+
+* WebKitPrivateFrameworkStubs/iOS/10/GraphicsServices.framework/GraphicsServices.tbd:
+
2017-06-09 Lucas Forschler
Modified: trunk/WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/10/GraphicsServices.framework/GraphicsServices.tbd (218642 => 218643)
--- trunk/WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/10/GraphicsServices.framework/GraphicsServices.tbd 2017-06-21 18:54:45 UTC (rev 218642)
+++ trunk/WebKitLibraries/WebKitPrivateFrameworkStubs/iOS/10/GraphicsServices.framework/GraphicsServices.tbd 2017-06-21 19:49:11 UTC (rev 218643)
@@ -11,6 +11,7 @@
- arm64
symbols:
- _GSCurrentEventTimestamp
+ - _GSFontInitialize
- _GSFontPurgeFontCache
- _GSInitialize
- _GSSystemRootDirectory
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [217696] trunk
Revision 217696
Author akl...@apple.com
Date 2017-06-01 22:04:14 -0700 (Thu, 01 Jun 2017)
Log Message
[Mac] Remove backing store for layers that are outside the viewport
https://bugs.webkit.org/show_bug.cgi?id=170082
Reviewed by Simon Fraser.
Source/WebCore:
Implement the backingStoreAttached flag in PlatformCALayerCocoa. This means that
compositing layers outside the tiling coverage rect will no longer have backing
stores, saving large amounts of memory.
Also added a canDetachBackingStore flag that is set to false for scroll control
layers, to avoid complicating coverage rect computations.
Test: compositing/backing-store-attachment-1.html
* page/Frame.h:
* platform/graphics/GraphicsLayer.cpp:
(WebCore::GraphicsLayer::GraphicsLayer):
(WebCore::GraphicsLayer::dumpProperties):
* platform/graphics/GraphicsLayer.h:
(WebCore::GraphicsLayer::backingStoreAttached):
(WebCore::GraphicsLayer::setCanDetachBackingStore):
(WebCore::GraphicsLayer::canDetachBackingStore):
* platform/graphics/GraphicsLayerClient.h:
* platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::backingStoreAttached):
(WebCore::GraphicsLayerCA::setNeedsDisplay):
(WebCore::GraphicsLayerCA::updateCoverage):
* platform/graphics/ca/GraphicsLayerCA.h:
* platform/graphics/ca/PlatformCALayer.h:
* platform/graphics/ca/cocoa/PlatformCALayerCocoa.h:
* platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(PlatformCALayerCocoa::setBackingStoreAttached):
(PlatformCALayerCocoa::backingStoreAttached):
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateOverflowControlsLayers):
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::layerTreeAsText):
(WebCore::RenderLayerCompositor::updateOverflowControlsLayers):
* testing/Internals.cpp:
(WebCore::toLayerTreeFlags):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit2:
* WebProcess/WebPage/mac/PlatformCALayerRemote.h:
LayoutTests:
Add a simple test with two compositing layers far apart vertically. Only one of them
should have its backing store attached.
* compositing/backing-store-attachment-1-expected.txt: Added.
* compositing/backing-store-attachment-1.html: Added.
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/Frame.h
trunk/Source/WebCore/platform/graphics/GraphicsLayer.cpp
trunk/Source/WebCore/platform/graphics/GraphicsLayer.h
trunk/Source/WebCore/platform/graphics/GraphicsLayerClient.h
trunk/Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
trunk/Source/WebCore/platform/graphics/ca/GraphicsLayerCA.h
trunk/Source/WebCore/platform/graphics/ca/PlatformCALayer.h
trunk/Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h
trunk/Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
trunk/Source/WebCore/rendering/RenderLayerBacking.cpp
trunk/Source/WebCore/rendering/RenderLayerCompositor.cpp
trunk/Source/WebCore/testing/Internals.cpp
trunk/Source/WebCore/testing/Internals.h
trunk/Source/WebCore/testing/Internals.idl
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebPage/mac/PlatformCALayerRemote.h
Added Paths
trunk/LayoutTests/compositing/backing-store-attachment-1-expected.txt
trunk/LayoutTests/compositing/backing-store-attachment-1.html
trunk/LayoutTests/platform/ios/compositing/backing-store-attachment-1-expected.txt
Diff
Modified: trunk/LayoutTests/ChangeLog (217695 => 217696)
--- trunk/LayoutTests/ChangeLog 2017-06-02 04:35:25 UTC (rev 217695)
+++ trunk/LayoutTests/ChangeLog 2017-06-02 05:04:14 UTC (rev 217696)
@@ -1,3 +1,17 @@
+2017-06-01 Andreas Kling
+
+[Mac] Remove backing store for layers that are outside the viewport
+https://bugs.webkit.org/show_bug.cgi?id=170082
+
+
+Reviewed by Simon Fraser.
+
+Add a simple test with two compositing layers far apart vertically. Only one of them
+should have its backing store attached.
+
+* compositing/backing-store-attachment-1-expected.txt: Added.
+* compositing/backing-store-attachment-1.html: Added.
+
2017-06-01 Ryan Haddad
Unreviewed, rolling out r217691.
Added: trunk/LayoutTests/compositing/backing-store-attachment-1-expected.txt (0 => 217696)
--- trunk/LayoutTests/compositing/backing-store-attachment-1-expected.txt (rev 0)
+++ trunk/LayoutTests/compositing/backing-store-attachment-1-expected.txt 2017-06-02 05:04:14 UTC (rev 217696)
@@ -0,0 +1,28 @@
+(GraphicsLayer
+ (anchor 0.00 0.00)
+ (bounds 785.00 2221.00)
+ (backingStoreAttached 1)
+ (children 1
+(GraphicsLayer
+ (bounds 785.00 2221.00)
+ (contentsOpaque 1)
+ (backingStoreAttached 1)
+ (children 2
+(GraphicsLayer
+ (position 8.00 13.00)
+ (bounds 600.00 600.00)
+ (drawsContent 1)
+ (backingStoreAttached 1)
+)
+(GraphicsLayer
+ (position 8.00 1613.00)
+
Title: [217384] trunk/Source/WTF
Revision 217384
Author akl...@apple.com
Date 2017-05-24 12:32:26 -0700 (Wed, 24 May 2017)
Log Message
Disable memory kill mechanisms when running with FastMalloc disabled.
https://bugs.webkit.org/show_bug.cgi?id=172550
Reviewed by Antti Koivisto.
If someone is using WebKit with a non-standard allocator, they are likely trying to debug
or test something, and suddenly getting killed is not gonna help with that.
* wtf/MemoryPressureHandler.cpp:
(WTF::MemoryPressureHandler::setShouldUsePeriodicMemoryMonitor):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/MemoryPressureHandler.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (217383 => 217384)
--- trunk/Source/WTF/ChangeLog 2017-05-24 19:25:55 UTC (rev 217383)
+++ trunk/Source/WTF/ChangeLog 2017-05-24 19:32:26 UTC (rev 217384)
@@ -1,3 +1,17 @@
+2017-05-24 Andreas Kling
+
+Disable memory kill mechanisms when running with FastMalloc disabled.
+https://bugs.webkit.org/show_bug.cgi?id=172550
+
+
+Reviewed by Antti Koivisto.
+
+If someone is using WebKit with a non-standard allocator, they are likely trying to debug
+or test something, and suddenly getting killed is not gonna help with that.
+
+* wtf/MemoryPressureHandler.cpp:
+(WTF::MemoryPressureHandler::setShouldUsePeriodicMemoryMonitor):
+
2017-05-22 Jiewen Tan
[WebCrypto] Support RSA-PSS
Modified: trunk/Source/WTF/wtf/MemoryPressureHandler.cpp (217383 => 217384)
--- trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-05-24 19:25:55 UTC (rev 217383)
+++ trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-05-24 19:32:26 UTC (rev 217384)
@@ -57,6 +57,12 @@
void MemoryPressureHandler::setShouldUsePeriodicMemoryMonitor(bool use)
{
+if (!isFastMallocEnabled()) {
+// If we're running with FastMalloc disabled, some kind of testing or debugging is probably happening.
+// Let's be nice and not enable the memory kill mechanism.
+return;
+}
+
if (use) {
m_measurementTimer = std::make_unique(RunLoop::main(), this, ::measurementTimerFired);
m_measurementTimer->startRepeating(30);
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [217101] trunk/Source
Revision 217101
Author akl...@apple.com
Date 2017-05-18 23:54:28 -0700 (Thu, 18 May 2017)
Log Message
[WK2] Notify WebPageProxy client when an active process goes over the inactive memory limit
https://bugs.webkit.org/show_bug.cgi?id=172244
Reviewed by Geoffrey Garen.
Source/WebKit2:
Add a WKPageUIClient callback that is invoked when an active process exceeds the inactive memory limit.
With the current state of the implementation, this means that a UI client can learn that backgrounding
a non-audible, non-capturing tab may cause it to get killed once the active/inactive hysteresis time
is over (8 minutes.)
The callback can be invoked multiple times if we exceed the limit, and then go under, and exceed again.
This is the callback:
didExceedBackgroundResourceLimitWhileInForeground(WKPageRef, WKResourceLimit)
Where WKResourceLimit is one of { kWKResourceLimitMemory, kWKResourceLimitCPU }
The CPU enum value is a placeholder pending implementation soon.
* UIProcess/API/APIUIClient.h:
(API::UIClient::didExceedBackgroundResourceLimitWhileInForeground):
* UIProcess/API/C/WKPage.cpp:
(WKPageSetPageUIClient):
* UIProcess/API/C/WKPageUIClient.h:
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didExceedInactiveMemoryLimitWhileActive):
* UIProcess/WebPageProxy.h:
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::didExceedInactiveMemoryLimitWhileActive):
* UIProcess/WebProcessProxy.h:
* UIProcess/WebProcessProxy.messages.in:
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
Source/WTF:
Add an installable callback to MemoryPressureHandler that gets invoked when an active process
exceeds the kill limit for an inactive process.
This allows a UI client to become aware that backgrounding a tab may cause it to get killed.
* wtf/MemoryPressureHandler.cpp:
(WTF::thresholdForMemoryKillWithProcessState):
(WTF::MemoryPressureHandler::thresholdForMemoryKill):
(WTF::MemoryPressureHandler::measurementTimerFired):
(WTF::MemoryPressureHandler::doesExceedInactiveLimitWhileActive):
(WTF::MemoryPressureHandler::doesNotExceedInactiveLimitWhileActive):
* wtf/MemoryPressureHandler.h:
(WTF::MemoryPressureHandler::setDidExceedInactiveLimitWhileActiveCallback):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/MemoryPressureHandler.cpp
trunk/Source/WTF/wtf/MemoryPressureHandler.h
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/UIProcess/API/APIUIClient.h
trunk/Source/WebKit2/UIProcess/API/C/WKPage.cpp
trunk/Source/WebKit2/UIProcess/API/C/WKPageUIClient.h
trunk/Source/WebKit2/UIProcess/WebPageProxy.cpp
trunk/Source/WebKit2/UIProcess/WebPageProxy.h
trunk/Source/WebKit2/UIProcess/WebProcessProxy.cpp
trunk/Source/WebKit2/UIProcess/WebProcessProxy.h
trunk/Source/WebKit2/UIProcess/WebProcessProxy.messages.in
trunk/Source/WebKit2/WebProcess/WebProcess.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (217100 => 217101)
--- trunk/Source/WTF/ChangeLog 2017-05-19 06:25:34 UTC (rev 217100)
+++ trunk/Source/WTF/ChangeLog 2017-05-19 06:54:28 UTC (rev 217101)
@@ -1,3 +1,25 @@
+2017-05-18 Andreas Kling
+
+[WK2] Notify WebPageProxy client when an active process goes over the inactive memory limit
+https://bugs.webkit.org/show_bug.cgi?id=172244
+
+
+Reviewed by Geoffrey Garen.
+
+Add an installable callback to MemoryPressureHandler that gets invoked when an active process
+exceeds the kill limit for an inactive process.
+
+This allows a UI client to become aware that backgrounding a tab may cause it to get killed.
+
+* wtf/MemoryPressureHandler.cpp:
+(WTF::thresholdForMemoryKillWithProcessState):
+(WTF::MemoryPressureHandler::thresholdForMemoryKill):
+(WTF::MemoryPressureHandler::measurementTimerFired):
+(WTF::MemoryPressureHandler::doesExceedInactiveLimitWhileActive):
+(WTF::MemoryPressureHandler::doesNotExceedInactiveLimitWhileActive):
+* wtf/MemoryPressureHandler.h:
+(WTF::MemoryPressureHandler::setDidExceedInactiveLimitWhileActiveCallback):
+
2017-05-18 Geoffrey Garen
AutomaticThread should wait longer before timing out
Modified: trunk/Source/WTF/wtf/MemoryPressureHandler.cpp (217100 => 217101)
--- trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-05-19 06:25:34 UTC (rev 217100)
+++ trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-05-19 06:54:28 UTC (rev 217101)
@@ -75,17 +75,23 @@
}
#endif
-size_t MemoryPressureHandler::thresholdForMemoryKill()
+static size_t thresholdForMemoryKillWithProcessState(WebsamProcessState processState)
{
#if CPU(X86_64) || CPU(ARM64)
-if (m_processState == WebsamProcessState::Active)
+if (processState == WebsamProcessState::Active)
return 4 * GB;
return 2 * GB;
#else
+UNUSED_PARAM(processState);
return 3 * GB;
#endif
}
+size_t MemoryPressureHandler::thresholdForMemoryKill()
+{
+return
Title: [216847] trunk/Source/WebKit2
Revision 216847
Author akl...@apple.com
Date 2017-05-14 12:27:45 -0700 (Sun, 14 May 2017)
Log Message
Always reset the assisted node when the main frame commits a new load.
https://bugs.webkit.org/show_bug.cgi?id=172088
Reviewed by Antti Koivisto.
WebPage::m_assistedNode could extend the lifetime of the document it pointed into
if the main frame was navigated while the assisted node was in one of its subframes.
The life-supported document wouldn't be reachable from _javascript_ but nevertheless
would consume memory and other resources.
This patch fixes the issue by always clearing WebPage::m_assistedNode when the main
frame commits a new load.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::resetAssistedNodeForFrame):
Modified Paths
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp
Diff
Modified: trunk/Source/WebKit2/ChangeLog (216846 => 216847)
--- trunk/Source/WebKit2/ChangeLog 2017-05-14 17:43:39 UTC (rev 216846)
+++ trunk/Source/WebKit2/ChangeLog 2017-05-14 19:27:45 UTC (rev 216847)
@@ -1,3 +1,21 @@
+2017-05-14 Andreas Kling
+
+Always reset the assisted node when the main frame commits a new load.
+https://bugs.webkit.org/show_bug.cgi?id=172088
+
+Reviewed by Antti Koivisto.
+
+WebPage::m_assistedNode could extend the lifetime of the document it pointed into
+if the main frame was navigated while the assisted node was in one of its subframes.
+The life-supported document wouldn't be reachable from _javascript_ but nevertheless
+would consume memory and other resources.
+
+This patch fixes the issue by always clearing WebPage::m_assistedNode when the main
+frame commits a new load.
+
+* WebProcess/WebPage/WebPage.cpp:
+(WebKit::WebPage::resetAssistedNodeForFrame):
+
2017-05-14 Csaba Osztrogonác
Unreviewed Mac cmake buildfix after r216690, just for fun.
Modified: trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp (216846 => 216847)
--- trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp 2017-05-14 17:43:39 UTC (rev 216846)
+++ trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp 2017-05-14 19:27:45 UTC (rev 216847)
@@ -5100,7 +5100,7 @@
{
if (!m_assistedNode)
return;
-if (m_assistedNode->document().frame() == frame->coreFrame()) {
+if (frame->isMainFrame() || m_assistedNode->document().frame() == frame->coreFrame()) {
#if PLATFORM(IOS)
send(Messages::WebPageProxy::StopAssistingNode());
#elif PLATFORM(MAC)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [216770] trunk/Source/WebCore
Revision 216770
Author akl...@apple.com
Date 2017-05-12 11:21:45 -0700 (Fri, 12 May 2017)
Log Message
Memory pressure response should only do sync bmalloc scavenge in sync mode.
https://bugs.webkit.org/show_bug.cgi?id=172035
Reviewed by Michael Saboff.
Only call WTF::releaseFastMallocFreeMemory() and his threading-related friends
when releaseMemory() is invoked with Synchronous::Yes, or if it's a critical
pressure response (maintaining the behavior added in r215775.)
* page/MemoryRelease.cpp:
(WebCore::releaseMemory):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/MemoryRelease.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (216769 => 216770)
--- trunk/Source/WebCore/ChangeLog 2017-05-12 17:54:11 UTC (rev 216769)
+++ trunk/Source/WebCore/ChangeLog 2017-05-12 18:21:45 UTC (rev 216770)
@@ -1,3 +1,17 @@
+2017-05-12 Andreas Kling
+
+Memory pressure response should only do sync bmalloc scavenge in sync mode.
+https://bugs.webkit.org/show_bug.cgi?id=172035
+
+Reviewed by Michael Saboff.
+
+Only call WTF::releaseFastMallocFreeMemory() and his threading-related friends
+when releaseMemory() is invoked with Synchronous::Yes, or if it's a critical
+pressure response (maintaining the behavior added in r215775.)
+
+* page/MemoryRelease.cpp:
+(WebCore::releaseMemory):
+
2017-05-12 Daniel Bates
Cleanup: Use Ref instead of RefPtr to hold DOMWrapperWorld
Modified: trunk/Source/WebCore/page/MemoryRelease.cpp (216769 => 216770)
--- trunk/Source/WebCore/page/MemoryRelease.cpp 2017-05-12 17:54:11 UTC (rev 216769)
+++ trunk/Source/WebCore/page/MemoryRelease.cpp 2017-05-12 18:21:45 UTC (rev 216770)
@@ -110,24 +110,26 @@
{
TraceScope scope(MemoryPressureHandlerStart, MemoryPressureHandlerEnd, static_cast(critical), static_cast(synchronous));
-// Return unused pages back to the OS now as this will likely give us a little memory to work with.
-WTF::releaseFastMallocFreeMemory();
-
-if (critical == Critical::Yes)
+if (critical == Critical::Yes) {
+// Return unused pages back to the OS now as this will likely give us a little memory to work with.
+WTF::releaseFastMallocFreeMemory();
releaseCriticalMemory(synchronous);
+}
releaseNoncriticalMemory();
platformReleaseMemory(critical);
-// FastMalloc has lock-free thread specific caches that can only be cleared from the thread itself.
-WorkerThread::releaseFastMallocFreeMemoryInAllThreads();
+if (synchronous == Synchronous::Yes) {
+// FastMalloc has lock-free thread specific caches that can only be cleared from the thread itself.
+WorkerThread::releaseFastMallocFreeMemoryInAllThreads();
#if ENABLE(ASYNC_SCROLLING) && !PLATFORM(IOS)
-ScrollingThread::dispatch([]() {
+ScrollingThread::dispatch([]() {
+WTF::releaseFastMallocFreeMemory();
+});
+#endif
WTF::releaseFastMallocFreeMemory();
-});
-#endif
-WTF::releaseFastMallocFreeMemory();
+}
#if ENABLE(RESOURCE_USAGE)
Page::forEachPage([&](Page& page) {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [215465] trunk/Source/WebCore
Revision 215465
Author akl...@apple.com
Date 2017-04-18 09:34:11 -0700 (Tue, 18 Apr 2017)
Log Message
Break Document::m_associatedFormControls reference cycle.
Reviewed by Antti Koivisto.
There was a race between didAssociateFormControls() and didAssociateFormControlsTimerFired()
where detaching Document from its frame between the two would lead to an unbreakable reference
cycle between Document and its form elements.
Solve this by clearing the set of associated form elements in removedLastRef(), where we clear
all the other strong smart pointers to elements.
* dom/Document.cpp:
(WebCore::Document::removedLastRef):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (215464 => 215465)
--- trunk/Source/WebCore/ChangeLog 2017-04-18 16:33:13 UTC (rev 215464)
+++ trunk/Source/WebCore/ChangeLog 2017-04-18 16:34:11 UTC (rev 215465)
@@ -1,3 +1,20 @@
+2017-04-18 Andreas Kling
+
+Break Document::m_associatedFormControls reference cycle.
+
+
+Reviewed by Antti Koivisto.
+
+There was a race between didAssociateFormControls() and didAssociateFormControlsTimerFired()
+where detaching Document from its frame between the two would lead to an unbreakable reference
+cycle between Document and its form elements.
+
+Solve this by clearing the set of associated form elements in removedLastRef(), where we clear
+all the other strong smart pointers to elements.
+
+* dom/Document.cpp:
+(WebCore::Document::removedLastRef):
+
2017-04-18 Manuel Rego Casasnovas
[css-grid] Add support for percentage gaps
Modified: trunk/Source/WebCore/dom/Document.cpp (215464 => 215465)
--- trunk/Source/WebCore/dom/Document.cpp 2017-04-18 16:33:13 UTC (rev 215464)
+++ trunk/Source/WebCore/dom/Document.cpp 2017-04-18 16:34:11 UTC (rev 215465)
@@ -625,6 +625,7 @@
m_fullScreenElement = nullptr;
m_fullScreenElementStack.clear();
#endif
+m_associatedFormControls.clear();
detachParser();
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [215077] trunk/Source/WebCore
Revision 215077
Author akl...@apple.com
Date 2017-04-06 17:39:24 -0700 (Thu, 06 Apr 2017)
Log Message
Inaudible background tabs should become eligible for memory kill after 8 minutes
https://bugs.webkit.org/show_bug.cgi?id=170574
Reviewed by Gavin Barraclough.
Lower the delay for potentially marking background tabs as inactive from 60 minutes to 8 minutes.
Letting a tab misbehave in the background for an entire hour was overly charitable.
* page/PerformanceMonitor.cpp:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/PerformanceMonitor.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (215076 => 215077)
--- trunk/Source/WebCore/ChangeLog 2017-04-07 00:39:22 UTC (rev 215076)
+++ trunk/Source/WebCore/ChangeLog 2017-04-07 00:39:24 UTC (rev 215077)
@@ -1,3 +1,16 @@
+2017-04-06 Andreas Kling
+
+Inaudible background tabs should become eligible for memory kill after 8 minutes
+https://bugs.webkit.org/show_bug.cgi?id=170574
+
+
+Reviewed by Gavin Barraclough.
+
+Lower the delay for potentially marking background tabs as inactive from 60 minutes to 8 minutes.
+Letting a tab misbehave in the background for an entire hour was overly charitable.
+
+* page/PerformanceMonitor.cpp:
+
2017-04-06 Wenson Hsieh
Scroll offset jumps after a programmatic scroll in an overflow container with scroll snapping
Modified: trunk/Source/WebCore/page/PerformanceMonitor.cpp (215076 => 215077)
--- trunk/Source/WebCore/page/PerformanceMonitor.cpp 2017-04-07 00:39:22 UTC (rev 215076)
+++ trunk/Source/WebCore/page/PerformanceMonitor.cpp 2017-04-07 00:39:24 UTC (rev 215077)
@@ -48,7 +48,7 @@
static const std::chrono::seconds memoryUsageMeasurementDelay { 10 };
-static const std::chrono::minutes delayBeforeProcessMayBecomeInactive { 60 };
+static const std::chrono::minutes delayBeforeProcessMayBecomeInactive { 8 };
static const double postPageLoadCPUUsageDomainReportingThreshold { 20.0 }; // Reporting pages using over 20% CPU is roughly equivalent to reporting the 10% worst pages.
#if !PLATFORM(IOS)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [215055] trunk/Source/WTF
Revision 215055
Author akl...@apple.com
Date 2017-04-06 13:18:52 -0700 (Thu, 06 Apr 2017)
Log Message
Kill any WebContent process using over 16 GB of memory.
https://bugs.webkit.org/show_bug.cgi?id=170515
Reviewed by Antti Koivisto.
Restructure the code since it was getting out of sync with the intended behavior.
Now there's a thresholdForMemoryKill() which returns the current memory limit based
on the process status.
The memory usage policy is separated from the killing, and now only drives the
asynchronous invocations of pressure relief that occur when we pass over one of
the policy edges (now 1GB for Conservative, 2GB for Strict.)
Removed the "Panic" policy and moved the memory kill logic to shrinkOrDie().
Behavior as of this patch:
- Everyone gets killed over 16 GB.
- Inactive processes get killed over 4 GB.
- Strict memory usage policy kicks in at 2 GB.
- Conservative memory usage policy at 1 GB.
Like before, we make a best-effort attempt to free up memory before killing the process.
* wtf/MemoryPressureHandler.cpp:
(WTF::toString):
(WTF::MemoryPressureHandler::thresholdForMemoryKill):
(WTF::thresholdForPolicy):
(WTF::policyForFootprint):
(WTF::MemoryPressureHandler::shrinkOrDie):
(WTF::MemoryPressureHandler::setMemoryUsagePolicyBasedOnFootprint):
(WTF::MemoryPressureHandler::measurementTimerFired):
* wtf/MemoryPressureHandler.h:
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/MemoryPressureHandler.cpp
trunk/Source/WTF/wtf/MemoryPressureHandler.h
Diff
Modified: trunk/Source/WTF/ChangeLog (215054 => 215055)
--- trunk/Source/WTF/ChangeLog 2017-04-06 20:03:55 UTC (rev 215054)
+++ trunk/Source/WTF/ChangeLog 2017-04-06 20:18:52 UTC (rev 215055)
@@ -1,3 +1,40 @@
+2017-04-06 Andreas Kling
+
+Kill any WebContent process using over 16 GB of memory.
+https://bugs.webkit.org/show_bug.cgi?id=170515
+
+
+Reviewed by Antti Koivisto.
+
+Restructure the code since it was getting out of sync with the intended behavior.
+Now there's a thresholdForMemoryKill() which returns the current memory limit based
+on the process status.
+
+The memory usage policy is separated from the killing, and now only drives the
+asynchronous invocations of pressure relief that occur when we pass over one of
+the policy edges (now 1GB for Conservative, 2GB for Strict.)
+
+Removed the "Panic" policy and moved the memory kill logic to shrinkOrDie().
+
+Behavior as of this patch:
+
+- Everyone gets killed over 16 GB.
+- Inactive processes get killed over 4 GB.
+- Strict memory usage policy kicks in at 2 GB.
+- Conservative memory usage policy at 1 GB.
+
+Like before, we make a best-effort attempt to free up memory before killing the process.
+
+* wtf/MemoryPressureHandler.cpp:
+(WTF::toString):
+(WTF::MemoryPressureHandler::thresholdForMemoryKill):
+(WTF::thresholdForPolicy):
+(WTF::policyForFootprint):
+(WTF::MemoryPressureHandler::shrinkOrDie):
+(WTF::MemoryPressureHandler::setMemoryUsagePolicyBasedOnFootprint):
+(WTF::MemoryPressureHandler::measurementTimerFired):
+* wtf/MemoryPressureHandler.h:
+
2017-04-05 Andreas Kling
Make inactive web processes behave as though under memory pressure.
Modified: trunk/Source/WTF/wtf/MemoryPressureHandler.cpp (215054 => 215055)
--- trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-04-06 20:03:55 UTC (rev 215054)
+++ trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-04-06 20:18:52 UTC (rev 215055)
@@ -71,11 +71,21 @@
case MemoryUsagePolicy::Unrestricted: return "Unrestricted";
case MemoryUsagePolicy::Conservative: return "Conservative";
case MemoryUsagePolicy::Strict: return "Strict";
-case MemoryUsagePolicy::Panic: return "Panic";
}
}
#endif
+size_t MemoryPressureHandler::thresholdForMemoryKill()
+{
+#if CPU(X86_64) || CPU(ARM64)
+if (m_processState == WebsamProcessState::Active)
+return 16 * GB;
+return 4 * GB;
+#else
+return 3 * GB;
+#endif
+}
+
static size_t thresholdForPolicy(MemoryUsagePolicy policy)
{
switch (policy) {
@@ -83,12 +93,6 @@
return 1 * GB;
case MemoryUsagePolicy::Strict:
return 2 * GB;
-case MemoryUsagePolicy::Panic:
-#if CPU(X86_64) || CPU(ARM64)
-return 4 * GB;
-#else
-return 3 * GB;
-#endif
case MemoryUsagePolicy::Unrestricted:
default:
ASSERT_NOT_REACHED();
@@ -98,8 +102,6 @@
static MemoryUsagePolicy policyForFootprint(size_t footprint)
{
-if (footprint >= thresholdForPolicy(MemoryUsagePolicy::Panic))
-return MemoryUsagePolicy::Panic;
if (footprint >= thresholdForPolicy(MemoryUsagePolicy::Strict))
return MemoryUsagePolicy::Strict;
if (footprint >=
Title: [215045] trunk/Source/WebCore
Revision 215045
Author akl...@apple.com
Date 2017-04-06 11:35:47 -0700 (Thu, 06 Apr 2017)
Log Message
Stop forcing CA commit when memory pressure changes.
https://bugs.webkit.org/show_bug.cgi?id=170522
Reviewed by Antti Koivisto.
Don't force a CA commit when reaching critical memory pressure. We're already doing a ton
of work in response to the pressure, and this was really a hack to try to react quickly on
512 MB devices which we don't support anymore.
* page/MemoryRelease.cpp:
(WebCore::releaseCriticalMemory):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/MemoryRelease.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (215044 => 215045)
--- trunk/Source/WebCore/ChangeLog 2017-04-06 18:32:47 UTC (rev 215044)
+++ trunk/Source/WebCore/ChangeLog 2017-04-06 18:35:47 UTC (rev 215045)
@@ -1,3 +1,18 @@
+2017-04-06 Andreas Kling
+
+Stop forcing CA commit when memory pressure changes.
+https://bugs.webkit.org/show_bug.cgi?id=170522
+
+
+Reviewed by Antti Koivisto.
+
+Don't force a CA commit when reaching critical memory pressure. We're already doing a ton
+of work in response to the pressure, and this was really a hack to try to react quickly on
+512 MB devices which we don't support anymore.
+
+* page/MemoryRelease.cpp:
+(WebCore::releaseCriticalMemory):
+
2017-04-06 Romain Bellessort
[Readable Streams API] Implement ReadableStreamBYOBRequest respondWithNewView()
Modified: trunk/Source/WebCore/page/MemoryRelease.cpp (215044 => 215045)
--- trunk/Source/WebCore/page/MemoryRelease.cpp 2017-04-06 18:32:47 UTC (rev 215044)
+++ trunk/Source/WebCore/page/MemoryRelease.cpp 2017-04-06 18:35:47 UTC (rev 215045)
@@ -104,11 +104,6 @@
GCController::singleton().garbageCollectSoon();
#endif
}
-
-// We reduce tiling coverage while under memory pressure, so make sure to drop excess tiles ASAP.
-Page::forEachPage([](Page& page) {
-page.chrome().client().scheduleCompositingLayerFlush();
-});
}
void releaseMemory(Critical critical, Synchronous synchronous)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [214294] trunk/Source
Revision 214294
Author akl...@apple.com
Date 2017-03-22 21:14:03 -0700 (Wed, 22 Mar 2017)
Log Message
Let MemoryPressureHandler track whether the process is active or inactive.
Reviewed by Antti Koivisto.
Source/WebCore:
Have PerformanceMonitor inform MemoryPressureHandler about relevant
changes to the page activity states.
Also change the "1 hour after last page load" policy to "1 hour after
last being visible in an active window."
* page/MainFrame.cpp:
(WebCore::MainFrame::didCompleteLoad):
* page/MainFrame.h:
* page/MemoryRelease.cpp:
(WebCore::processIsEligibleForMemoryKill): Deleted.
* page/MemoryRelease.h:
* page/Page.h:
(WebCore::Page::performanceMonitor):
* page/PerformanceMonitor.cpp:
(WebCore::PerformanceMonitor::PerformanceMonitor):
(WebCore::PerformanceMonitor::activityStateChanged):
(WebCore::PerformanceMonitor::processMayBecomeInactiveTimerFired):
(WebCore::PerformanceMonitor::updateProcessStateForMemoryPressure):
* page/PerformanceMonitor.h:
Source/WebKit2:
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
Source/WTF:
An active process is a process that meets any of these criteria:
- Has had a visible Page in an active window in the last hour
- Is playing audio
This replaces the old mechanism where MemoryPressureHandler would invoke
a callback to know whether the process was eligible for a memory kill.
Instead we now plumb the relevant information down from WebCore and kill
based on this activity state.
* wtf/MemoryPressureHandler.cpp:
(WTF::MemoryPressureHandler::measurementTimerFired):
(WTF::MemoryPressureHandler::setProcessState):
* wtf/MemoryPressureHandler.h:
(WTF::MemoryPressureHandler::setMemoryKillCallback):
(WTF::MemoryPressureHandler::processState):
(WTF::MemoryPressureHandler::setProcessIsEligibleForMemoryKillCallback): Deleted.
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/MemoryPressureHandler.cpp
trunk/Source/WTF/wtf/MemoryPressureHandler.h
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/MainFrame.cpp
trunk/Source/WebCore/page/MainFrame.h
trunk/Source/WebCore/page/MemoryRelease.cpp
trunk/Source/WebCore/page/MemoryRelease.h
trunk/Source/WebCore/page/Page.h
trunk/Source/WebCore/page/PerformanceMonitor.cpp
trunk/Source/WebCore/page/PerformanceMonitor.h
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebProcess.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (214293 => 214294)
--- trunk/Source/WTF/ChangeLog 2017-03-23 02:44:57 UTC (rev 214293)
+++ trunk/Source/WTF/ChangeLog 2017-03-23 04:14:03 UTC (rev 214294)
@@ -1,3 +1,28 @@
+2017-03-22 Andreas Kling
+
+Let MemoryPressureHandler track whether the process is active or inactive.
+
+
+Reviewed by Antti Koivisto.
+
+An active process is a process that meets any of these criteria:
+
+- Has had a visible Page in an active window in the last hour
+- Is playing audio
+
+This replaces the old mechanism where MemoryPressureHandler would invoke
+a callback to know whether the process was eligible for a memory kill.
+Instead we now plumb the relevant information down from WebCore and kill
+based on this activity state.
+
+* wtf/MemoryPressureHandler.cpp:
+(WTF::MemoryPressureHandler::measurementTimerFired):
+(WTF::MemoryPressureHandler::setProcessState):
+* wtf/MemoryPressureHandler.h:
+(WTF::MemoryPressureHandler::setMemoryKillCallback):
+(WTF::MemoryPressureHandler::processState):
+(WTF::MemoryPressureHandler::setProcessIsEligibleForMemoryKillCallback): Deleted.
+
2017-03-20 Simon Fraser
Add a system trace point for memory warning handling
Modified: trunk/Source/WTF/wtf/MemoryPressureHandler.cpp (214293 => 214294)
--- trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-03-23 02:44:57 UTC (rev 214293)
+++ trunk/Source/WTF/wtf/MemoryPressureHandler.cpp 2017-03-23 04:14:03 UTC (rev 214294)
@@ -143,11 +143,9 @@
RELEASE_ASSERT(newPolicy == MemoryUsagePolicy::Panic);
RELEASE_LOG(MemoryPressure, "Attempting to reduce memory footprint by freeing more important objects.");
-if (m_processIsEligibleForMemoryKillCallback) {
-if (!m_processIsEligibleForMemoryKillCallback()) {
-releaseMemory(Critical::Yes, Synchronous::No);
-return;
-}
+if (m_processState == WebsamProcessState::Active) {
+releaseMemory(Critical::Yes, Synchronous::No);
+return;
}
releaseMemory(Critical::Yes, Synchronous::Yes);
@@ -168,6 +166,13 @@
m_memoryKillCallback();
}
+void MemoryPressureHandler::setProcessState(WebsamProcessState state)
+{
+if (m_processState == state)
+return;
+m_processState = state;
+}
+
void MemoryPressureHandler::beginSimulatedMemoryPressure()
{
if (m_isSimulatingMemoryPressure)
Modified:
Title: [213274] trunk/Source/WebCore
Revision 213274
Author akl...@apple.com
Date 2017-03-02 01:03:41 -0800 (Thu, 02 Mar 2017)
Log Message
Don't keep dead resources in MemoryCache while under memory pressure.
Reviewed by Antti Koivisto.
Have CachedResource::deleteIfPossible() remove the resource from the MemoryCache
if we're under memory pressure and that was the only thing keeping it alive.
This is consistent with the policy where dead resources are evicted from the cache
as we come under pressure.
* loader/cache/CachedResource.cpp:
(WebCore::CachedResource::deleteIfPossible):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/loader/cache/CachedResource.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (213273 => 213274)
--- trunk/Source/WebCore/ChangeLog 2017-03-02 08:59:12 UTC (rev 213273)
+++ trunk/Source/WebCore/ChangeLog 2017-03-02 09:03:41 UTC (rev 213274)
@@ -1,3 +1,19 @@
+2017-03-02 Andreas Kling
+
+Don't keep dead resources in MemoryCache while under memory pressure.
+
+
+Reviewed by Antti Koivisto.
+
+Have CachedResource::deleteIfPossible() remove the resource from the MemoryCache
+if we're under memory pressure and that was the only thing keeping it alive.
+
+This is consistent with the policy where dead resources are evicted from the cache
+as we come under pressure.
+
+* loader/cache/CachedResource.cpp:
+(WebCore::CachedResource::deleteIfPossible):
+
2017-03-01 Carlos Garcia Campos
REGRESSION(r213062): [SOUP] UTF-8 filename in Content-Disposition header incorrectly handled since r213062
Modified: trunk/Source/WebCore/loader/cache/CachedResource.cpp (213273 => 213274)
--- trunk/Source/WebCore/loader/cache/CachedResource.cpp 2017-03-02 08:59:12 UTC (rev 213273)
+++ trunk/Source/WebCore/loader/cache/CachedResource.cpp 2017-03-02 09:03:41 UTC (rev 213274)
@@ -549,6 +549,12 @@
bool CachedResource::deleteIfPossible()
{
if (canDelete()) {
+if (inCache() && MemoryPressureHandler::singleton().isUnderMemoryPressure()) {
+MemoryCache::singleton().remove(*this);
+// MemoryCache::remove() will call back into deleteIfPossible() and succeed.
+// FIXME: This would be less incomprehensible if CachedResource were ref-counted.
+return true;
+}
if (!inCache()) {
InspectorInstrumentation::willDestroyCachedResource(*this);
delete this;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [212742] trunk/Source
Revision 212742
Author akl...@apple.com
Date 2017-02-21 13:04:50 -0800 (Tue, 21 Feb 2017)
Log Message
[iOS] WebKit1 should use shared memory pressure handler code.
Reviewed by Antti Koivisto.
Source/WebCore:
Remove iOS WebKit1 specific members and code from MemoryPressureHandler in favor
of using the same code that iOS WebKit2 and macOS WebKit uses.
* page/cocoa/MemoryReleaseCocoa.mm:
(WebCore::platformReleaseMemory): Add two cleanup calls that were only in the iOS WebView code.
* platform/MemoryPressureHandler.h:
(WebCore::MemoryPressureHandler::m_releaseMemoryBlock): Deleted.
* platform/cocoa/MemoryPressureHandlerCocoa.mm:
(WebCore::respondToMemoryPressureCallback): Deleted.
(WebCore::MemoryPressureHandler::installMemoryReleaseBlock): Deleted.
(WebCore::MemoryPressureHandler::setReceivedMemoryPressure): Deleted.
(WebCore::MemoryPressureHandler::clearMemoryPressure): Deleted.
(WebCore::MemoryPressureHandler::shouldWaitForMemoryClearMessage): Deleted.
(WebCore::MemoryPressureHandler::respondToMemoryPressureIfNeeded): Deleted.
Source/WebKit/ios:
* Misc/WebUIKitSupport.mm:
(WebKitInitialize): Don't unconditionally install a memory warning handler just
because the framework is loaded.
Source/WebKit/mac:
Register a WebThread-aware memory callback with the shared MemoryPressureHandler
and get rid of the old iOS WebKit1 specific implementation. Some of it was even
dead code since MobileSafari has been using WebKit2 for quite a while.
* WebView/WebView.h:
* WebView/WebView.mm:
(WebInstallMemoryPressureHandler):
(+[WebView _handleMemoryWarning]): Deleted.
(+[WebView registerForMemoryNotifications]): Deleted.
(+[WebView releaseFastMallocMemoryOnCurrentThread]): Deleted.
(+[WebView garbageCollectNow]): Deleted.
(+[WebView purgeInactiveFontData]): Deleted.
(+[WebView drainLayerPool]): Deleted.
(+[WebView discardAllCompiledCode]): Deleted.
(+[WebView _clearMemoryPressure]): Deleted.
(+[WebView _shouldWaitForMemoryClearMessage]): Deleted.
* WebView/WebViewPrivate.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm
trunk/Source/WebCore/platform/MemoryPressureHandler.h
trunk/Source/WebCore/platform/cocoa/MemoryPressureHandlerCocoa.mm
trunk/Source/WebKit/ios/ChangeLog
trunk/Source/WebKit/ios/Misc/WebUIKitSupport.mm
trunk/Source/WebKit/mac/ChangeLog
trunk/Source/WebKit/mac/WebView/WebView.h
trunk/Source/WebKit/mac/WebView/WebView.mm
trunk/Source/WebKit/mac/WebView/WebViewPrivate.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (212741 => 212742)
--- trunk/Source/WebCore/ChangeLog 2017-02-21 21:03:55 UTC (rev 212741)
+++ trunk/Source/WebCore/ChangeLog 2017-02-21 21:04:50 UTC (rev 212742)
@@ -1,3 +1,25 @@
+2017-02-21 Andreas Kling
+
+[iOS] WebKit1 should use shared memory pressure handler code.
+
+
+Reviewed by Antti Koivisto.
+
+Remove iOS WebKit1 specific members and code from MemoryPressureHandler in favor
+of using the same code that iOS WebKit2 and macOS WebKit uses.
+
+* page/cocoa/MemoryReleaseCocoa.mm:
+(WebCore::platformReleaseMemory): Add two cleanup calls that were only in the iOS WebView code.
+* platform/MemoryPressureHandler.h:
+(WebCore::MemoryPressureHandler::m_releaseMemoryBlock): Deleted.
+* platform/cocoa/MemoryPressureHandlerCocoa.mm:
+(WebCore::respondToMemoryPressureCallback): Deleted.
+(WebCore::MemoryPressureHandler::installMemoryReleaseBlock): Deleted.
+(WebCore::MemoryPressureHandler::setReceivedMemoryPressure): Deleted.
+(WebCore::MemoryPressureHandler::clearMemoryPressure): Deleted.
+(WebCore::MemoryPressureHandler::shouldWaitForMemoryClearMessage): Deleted.
+(WebCore::MemoryPressureHandler::respondToMemoryPressureIfNeeded): Deleted.
+
2017-02-21 Anders Carlsson
Fix two failing WebKit legacy tests
Modified: trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm (212741 => 212742)
--- trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm 2017-02-21 21:03:55 UTC (rev 212741)
+++ trunk/Source/WebCore/page/cocoa/MemoryReleaseCocoa.mm 2017-02-21 21:04:50 UTC (rev 212742)
@@ -32,6 +32,12 @@
#import "LayerPool.h"
#import
+#if PLATFORM(IOS)
+#import "LegacyTileCache.h"
+#import "TileControllerMemoryHandlerIOS.h"
+#endif
+
+
extern "C" void _sqlite3_purgeEligiblePagerCacheMemory(void);
namespace WebCore {
@@ -47,6 +53,11 @@
for (auto& pool : LayerPool::allLayerPools())
pool->drain();
+#if PLATFORM(IOS)
+LegacyTileCache::drainLayerPool();
+tileControllerMemoryHandler().trimUnparentedTilesToTarget(0);
+#endif
+
#if USE(IOSURFACE)
IOSurfacePool::sharedPool().discardAllSurfaces();
#endif
Modified: trunk/Source/WebCore/platform/MemoryPressureHandler.h (212741 => 212742)
--- trunk/Source/WebCore/platform/MemoryPressureHandler.h 2017-02-21 21:03:55 UTC (rev 212741)
+++
Title: [211885] trunk/Source/WebCore
Revision 211885
Author akl...@apple.com
Date 2017-02-08 10:37:13 -0800 (Wed, 08 Feb 2017)
Log Message
No need for CachedFrame to detach custom scrollbars.
Reviewed by Sam Weinig.
Custom scrollbars have already been torn down with the rest of the render tree
by the time we're creating a CachedFrame.
* history/CachedFrame.cpp:
(WebCore::CachedFrame::CachedFrame):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/history/CachedFrame.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (211884 => 211885)
--- trunk/Source/WebCore/ChangeLog 2017-02-08 18:33:46 UTC (rev 211884)
+++ trunk/Source/WebCore/ChangeLog 2017-02-08 18:37:13 UTC (rev 211885)
@@ -1,3 +1,16 @@
+2017-02-08 Andreas Kling
+
+No need for CachedFrame to detach custom scrollbars.
+
+
+Reviewed by Sam Weinig.
+
+Custom scrollbars have already been torn down with the rest of the render tree
+by the time we're creating a CachedFrame.
+
+* history/CachedFrame.cpp:
+(WebCore::CachedFrame::CachedFrame):
+
2017-02-08 Zalan Bujtas
Simple line layout: Fix printReason for unsupported overflow values.
Modified: trunk/Source/WebCore/history/CachedFrame.cpp (211884 => 211885)
--- trunk/Source/WebCore/history/CachedFrame.cpp 2017-02-08 18:33:46 UTC (rev 211884)
+++ trunk/Source/WebCore/history/CachedFrame.cpp 2017-02-08 18:37:13 UTC (rev 211885)
@@ -137,10 +137,6 @@
ASSERT(m_document);
ASSERT(m_documentLoader);
ASSERT(m_view);
-
-// Custom scrollbar renderers will get reattached when the document comes out of the page cache
-m_view->detachCustomScrollbars();
-
ASSERT(m_document->pageCacheState() == Document::InPageCache);
// Create the CachedFrames for all Frames in the FrameTree.
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [211622] trunk/Source
Revision 211622
Author akl...@apple.com
Date 2017-02-02 23:25:24 -0800 (Thu, 02 Feb 2017)
Log Message
[Mac] In-process memory pressure monitor for WebContent processes AKA websam
Reviewed by Antti Koivisto.
Source/_javascript_Core:
Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
WebCore-side memory footprint monitor.
* heap/Heap.cpp:
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didExceedMaxLiveSize): Deleted.
* heap/Heap.h:
(JSC::Heap::setMaxLiveSize): Deleted.
Source/WebCore:
Add a new timer-based memory pressure monitor that checks the process memory
footprint every 30 seconds and reacts to changes by setting a MemoryUsagePolicy.
There are four MemoryUsagePolicy values:
- Unrestricted (below 1GB)
- Conservative (above 1GB)
- Strict (above 2GB)
- Panic (above 4GB, or 3GB if 32-bit)
For Strict and above, the old-style "isUnderMemoryPressure()" API will return true.
Transitioning to a higher policy will cause memory pressure handlers to run:
At Strict, we run the "non-critical" memory pressure handler, then carry on.
At Panic, we run the "critical" memory pressure handler. If that fails to recover
enough memory to bring us back below 4GB, we may kill the process:
A process is eligible to get killed for using too much memory if:
- It's not visible on screen (i.e it's a background tab.)
- It's not playing audio.
- It has not performed a main frame navigation in the last hour.
Before killing the process, an exit-time callback will run. This patch installs such
a callback that prints out some time-of-death statistics about C++ and _javascript_ memory
usage to hopefully help understand what was soaking up all the memory.
* bindings/js/CommonVM.cpp:
(WebCore::commonVMSlow):
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::setState):
* page/MainFrame.cpp:
(WebCore::MainFrame::didCompleteLoad):
* page/MainFrame.h:
* page/MemoryRelease.cpp:
(WebCore::pageCount):
(WebCore::logMemoryStatisticsAtTimeOfDeath):
(WebCore::didExceedMemoryLimitAndFailedToRecover):
(WebCore::processIsEligibleForMemoryKill):
* page/MemoryRelease.h:
* page/ResourceUsageThread.h:
* page/cocoa/ResourceUsageThreadCocoa.mm:
(WebCore::vmPageSize):
* platform/MemoryPressureHandler.cpp:
(WebCore::MemoryPressureHandler::MemoryPressureHandler):
(WebCore::MemoryPressureHandler::setShouldUsePeriodicMemoryMonitor):
(WebCore::toString):
(WebCore::thresholdForPolicy):
(WebCore::policyForFootprint):
(WebCore::MemoryPressureHandler::measurementTimerFired):
* platform/MemoryPressureHandler.h:
(WebCore::MemoryPressureHandler::setMemoryKillCallback):
(WebCore::MemoryPressureHandler::setProcessIsEligibleForMemoryKillCallback):
(WebCore::MemoryPressureHandler::isUnderMemoryPressure):
Source/WebKit2:
Enable the in-process memory monitor for WebContent processes on macOS 10.12+
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
Source/WTF:
Add a WTF helper function for getting the current process's memory footprint.
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/MemoryFootprint.cpp:
(WTF::memoryFootprint):
* wtf/MemoryFootprint.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/Heap.cpp
trunk/Source/_javascript_Core/heap/Heap.h
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/WTF.xcodeproj/project.pbxproj
trunk/Source/WTF/wtf/CMakeLists.txt
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/bindings/js/CommonVM.cpp
trunk/Source/WebCore/loader/FrameLoader.cpp
trunk/Source/WebCore/page/MainFrame.cpp
trunk/Source/WebCore/page/MainFrame.h
trunk/Source/WebCore/page/MemoryRelease.cpp
trunk/Source/WebCore/page/MemoryRelease.h
trunk/Source/WebCore/page/ResourceUsageThread.h
trunk/Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm
trunk/Source/WebCore/platform/MemoryPressureHandler.cpp
trunk/Source/WebCore/platform/MemoryPressureHandler.h
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebProcess.cpp
Added Paths
trunk/Source/WTF/wtf/MemoryFootprint.cpp
trunk/Source/WTF/wtf/MemoryFootprint.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (211621 => 211622)
--- trunk/Source/_javascript_Core/ChangeLog 2017-02-03 06:30:30 UTC (rev 211621)
+++ trunk/Source/_javascript_Core/ChangeLog 2017-02-03 07:25:24 UTC (rev 211622)
@@ -1,3 +1,20 @@
+2017-02-02 Andreas Kling
+
+[Mac] In-process memory pressure monitor for WebContent processes AKA websam
+
+
+
+Reviewed by Antti Koivisto.
+
+Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
+WebCore-side memory footprint monitor.
+
+* heap/Heap.cpp:
+(JSC::Heap::updateAllocationLimits):
+(JSC::Heap::didExceedMaxLiveSize): Deleted.
+* heap/Heap.h:
+(JSC::Heap::setMaxLiveSize): Deleted.
+
2017-02-02 Mark Lam
Add a SIGILL crash analyzer to make
Title: [211571] trunk/Source
Revision 211571
Author akl...@apple.com
Date 2017-02-02 10:35:55 -0800 (Thu, 02 Feb 2017)
Log Message
Source/_javascript_Core:
[Mac] In-process memory pressure monitor for WebContent processes.
Reviewed by Antti Koivisto.
Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
WebCore-side memory footprint monitor.
* heap/Heap.cpp:
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didExceedMaxLiveSize): Deleted.
* heap/Heap.h:
(JSC::Heap::setMaxLiveSize): Deleted.
Source/WebCore:
[Mac] In-process memory pressure monitor for WebContent processes AKA websam
Reviewed by Antti Koivisto.
Add a new timer-based memory pressure monitor that checks the process memory
footprint every 30 seconds and reacts to changes by setting a MemoryUsagePolicy.
There are four MemoryUsagePolicy values:
- Unrestricted (below 1GB)
- Conservative (above 1GB)
- Strict (above 2GB)
- Panic (above 4GB, or 3GB if 32-bit)
For Strict and above, the old-style "isUnderMemoryPressure()" API will return true.
Transitioning to a higher policy will cause memory pressure handlers to run:
At Strict, we run the "non-critical" memory pressure handler, then carry on.
At Panic, we run the "critical" memory pressure handler. If that fails to recover
enough memory to bring us back below 4GB, we may kill the process:
A process is eligible to get killed for using too much memory if:
- It's not visible on screen (i.e it's a background tab.)
- It's not playing audio.
- It has not performed a main frame navigation in the last hour.
Before killing the process, an exit-time callback will run. This patch installs such
a callback that prints out some time-of-death statistics about C++ and _javascript_ memory
usage to hopefully help understand what was soaking up all the memory.
* bindings/js/CommonVM.cpp:
(WebCore::commonVMSlow):
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::setState):
* page/MainFrame.cpp:
(WebCore::MainFrame::didCompleteLoad):
* page/MainFrame.h:
* page/MemoryRelease.cpp:
(WebCore::pageCount):
(WebCore::logMemoryStatisticsAtTimeOfDeath):
(WebCore::didExceedMemoryLimitAndFailedToRecover):
(WebCore::processIsEligibleForMemoryKill):
* page/MemoryRelease.h:
* page/ResourceUsageThread.h:
* page/cocoa/ResourceUsageThreadCocoa.mm:
(WebCore::vmPageSize):
* platform/MemoryPressureHandler.cpp:
(WebCore::MemoryPressureHandler::MemoryPressureHandler):
(WebCore::MemoryPressureHandler::setShouldUsePeriodicMemoryMonitor):
(WebCore::toString):
(WebCore::thresholdForPolicy):
(WebCore::policyForFootprint):
(WebCore::MemoryPressureHandler::measurementTimerFired):
* platform/MemoryPressureHandler.h:
(WebCore::MemoryPressureHandler::setMemoryKillCallback):
(WebCore::MemoryPressureHandler::setProcessIsEligibleForMemoryKillCallback):
(WebCore::MemoryPressureHandler::isUnderMemoryPressure):
Source/WebKit2:
[Mac] In-process memory pressure monitor for WebContent processes.
Reviewed by Antti Koivisto.
Enable the in-process memory monitor for WebContent processes on macOS 10.12+
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
Source/WTF:
[Mac] In-process memory pressure monitor for WebContent processes.
Reviewed by Antti Koivisto.
Add a WTF helper function for getting the current process's memory footprint.
* WTF.xcodeproj/project.pbxproj:
* wtf/CMakeLists.txt:
* wtf/MemoryFootprint.cpp:
(WTF::memoryFootprint):
* wtf/MemoryFootprint.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/Heap.cpp
trunk/Source/_javascript_Core/heap/Heap.h
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/WTF.xcodeproj/project.pbxproj
trunk/Source/WTF/wtf/CMakeLists.txt
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/bindings/js/CommonVM.cpp
trunk/Source/WebCore/loader/FrameLoader.cpp
trunk/Source/WebCore/page/MainFrame.cpp
trunk/Source/WebCore/page/MainFrame.h
trunk/Source/WebCore/page/MemoryRelease.cpp
trunk/Source/WebCore/page/MemoryRelease.h
trunk/Source/WebCore/page/ResourceUsageThread.h
trunk/Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm
trunk/Source/WebCore/platform/MemoryPressureHandler.cpp
trunk/Source/WebCore/platform/MemoryPressureHandler.h
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebProcess.cpp
Added Paths
trunk/Source/WTF/wtf/MemoryFootprint.cpp
trunk/Source/WTF/wtf/MemoryFootprint.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (211570 => 211571)
--- trunk/Source/_javascript_Core/ChangeLog 2017-02-02 18:33:29 UTC (rev 211570)
+++ trunk/Source/_javascript_Core/ChangeLog 2017-02-02 18:35:55 UTC (rev 211571)
@@ -1,3 +1,20 @@
+2017-02-02 Andreas Kling
+
+[Mac] In-process memory pressure monitor for WebContent processes.
+
+
+
+Reviewed by Antti Koivisto.
+
+Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
+WebCore-side memory footprint monitor.
+
+
Title: [211482] trunk/Source
Revision 211482
Author akl...@apple.com
Date 2017-02-01 06:55:00 -0800 (Wed, 01 Feb 2017)
Log Message
Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
Reviewed by Antti Koivisto.
Source/bmalloc:
Support changing the QoS level of the scavenger thread asynchronously through
a request variable. This is not the most elegant thing in the world, but since
threads are only allowed to change their own QoS class, our options are limited.
* bmalloc/Heap.cpp:
(bmalloc::Heap::concurrentScavenge):
* bmalloc/Heap.h:
(bmalloc::Heap::takeRequestedScavengerThreadQOSClass):
(bmalloc::Heap::setScavengerThreadQOSClass):
* bmalloc/bmalloc.h:
(bmalloc::api::setScavengerThreadQOSClass):
Source/WebKit2:
Remove the old ProcessThrottlerClient implementation of alwaysRunsAtBackgroundPriority
and replace it with WTF::setGlobalMaxQOSClass().
If the setting is enabled, it's passed over to each WK2 child process along with its
bootstrap parameter, and we notify WTF in XPCServiceInitializer(), before anything
too threading related happens.
* Platform/IPC/Connection.cpp:
(IPC::Connection::processIncomingMessage):
* Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.h:
(WebKit::XPCServiceInitializer):
* Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.mm:
(WebKit::XPCServiceInitializerDelegate::getExtraInitializationData):
* UIProcess/API/APIProcessPoolConfiguration.h:
* UIProcess/ChildProcessProxy.cpp:
(WebKit::ChildProcessProxy::ChildProcessProxy):
(WebKit::ChildProcessProxy::getLaunchOptions):
* UIProcess/ChildProcessProxy.h:
* UIProcess/Databases/DatabaseProcessProxy.cpp:
(WebKit::DatabaseProcessProxy::DatabaseProcessProxy):
* UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::NetworkProcessProxy):
(WebKit::NetworkProcessProxy::alwaysRunsAtBackgroundPriority): Deleted.
* UIProcess/Network/NetworkProcessProxy.h:
* UIProcess/ProcessThrottler.cpp:
(WebKit::ProcessThrottler::assertionState):
* UIProcess/ProcessThrottlerClient.h:
* UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::WebProcessProxy):
(WebKit::WebProcessProxy::alwaysRunsAtBackgroundPriority): Deleted.
* UIProcess/WebProcessProxy.h:
Source/WTF:
Add a new mechanism for overriding the max thread QoS level globally:
void setGlobalMaxQOSClass(qos_class_t)
qos_class_t adjustedQOSClass(qos_class_t)
The QoS cap applies to all newly created threads, threads that try to override
their QoS class manually, and also passed down to bmalloc.
* wtf/Threading.cpp:
(WTF::setCurrentThreadIsUserInteractive):
(WTF::setCurrentThreadIsUserInitiated):
(WTF::setGlobalMaxQOSClass):
(WTF::adjustedQOSClass):
* wtf/Threading.h:
* wtf/ThreadingPthreads.cpp:
(WTF::createThreadInternal):
* wtf/cocoa/WorkQueueCocoa.cpp:
(WTF::dispatchQOSClass):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/Threading.cpp
trunk/Source/WTF/wtf/Threading.h
trunk/Source/WTF/wtf/ThreadingPthreads.cpp
trunk/Source/WTF/wtf/cocoa/WorkQueueCocoa.cpp
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/Platform/IPC/Connection.cpp
trunk/Source/WebKit2/Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.h
trunk/Source/WebKit2/Shared/EntryPointUtilities/mac/XPCService/XPCServiceEntryPoint.mm
trunk/Source/WebKit2/UIProcess/ChildProcessProxy.cpp
trunk/Source/WebKit2/UIProcess/ChildProcessProxy.h
trunk/Source/WebKit2/UIProcess/Databases/DatabaseProcessProxy.cpp
trunk/Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp
trunk/Source/WebKit2/UIProcess/Network/NetworkProcessProxy.h
trunk/Source/WebKit2/UIProcess/ProcessThrottler.cpp
trunk/Source/WebKit2/UIProcess/ProcessThrottlerClient.h
trunk/Source/WebKit2/UIProcess/WebProcessProxy.cpp
trunk/Source/WebKit2/UIProcess/WebProcessProxy.h
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/Heap.cpp
trunk/Source/bmalloc/bmalloc/Heap.h
trunk/Source/bmalloc/bmalloc/bmalloc.h
Diff
Modified: trunk/Source/WTF/ChangeLog (211481 => 211482)
--- trunk/Source/WTF/ChangeLog 2017-02-01 14:14:36 UTC (rev 211481)
+++ trunk/Source/WTF/ChangeLog 2017-02-01 14:55:00 UTC (rev 211482)
@@ -1,3 +1,30 @@
+2017-02-01 Andreas Kling
+
+Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
+
+
+
+Reviewed by Antti Koivisto.
+
+Add a new mechanism for overriding the max thread QoS level globally:
+
+void setGlobalMaxQOSClass(qos_class_t)
+qos_class_t adjustedQOSClass(qos_class_t)
+
+The QoS cap applies to all newly created threads, threads that try to override
+their QoS class manually, and also passed down to bmalloc.
+
+* wtf/Threading.cpp:
+(WTF::setCurrentThreadIsUserInteractive):
+(WTF::setCurrentThreadIsUserInitiated):
+(WTF::setGlobalMaxQOSClass):
+(WTF::adjustedQOSClass):
+* wtf/Threading.h:
+* wtf/ThreadingPthreads.cpp:
+
Title: [211399] trunk/Source/WebCore
Revision 211399
Author akl...@apple.com
Date 2017-01-30 18:12:06 -0800 (Mon, 30 Jan 2017)
Log Message
Fix CMSampleBuffer leak in MediaSampleAVFObjC::createNonDisplayingCopy().
Reviewed by Andy Estes.
We were failing to adopt the CMSampleBuffer after copying it. Seen on leaks bot.
* platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm:
(WebCore::MediaSampleAVFObjC::createNonDisplayingCopy):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (211398 => 211399)
--- trunk/Source/WebCore/ChangeLog 2017-01-31 01:54:02 UTC (rev 211398)
+++ trunk/Source/WebCore/ChangeLog 2017-01-31 02:12:06 UTC (rev 211399)
@@ -1,3 +1,15 @@
+2017-01-30 Andreas Kling
+
+Fix CMSampleBuffer leak in MediaSampleAVFObjC::createNonDisplayingCopy().
+
+
+Reviewed by Andy Estes.
+
+We were failing to adopt the CMSampleBuffer after copying it. Seen on leaks bot.
+
+* platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm:
+(WebCore::MediaSampleAVFObjC::createNonDisplayingCopy):
+
2017-01-30 Andy Estes
[QuickLook] QLPreviewConverter and QuickLookHandle have different lifetime requirements
Modified: trunk/Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm (211398 => 211399)
--- trunk/Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm 2017-01-31 01:54:02 UTC (rev 211398)
+++ trunk/Source/WebCore/platform/graphics/avfoundation/objc/MediaSampleAVFObjC.mm 2017-01-31 02:12:06 UTC (rev 211399)
@@ -229,7 +229,7 @@
CFDictionarySetValue(attachments, kCMSampleAttachmentKey_DoNotDisplay, kCFBooleanTrue);
}
-return MediaSampleAVFObjC::create(newSampleBuffer, m_id);
+return MediaSampleAVFObjC::create(adoptCF(newSampleBuffer).get(), m_id);
}
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [211362] trunk/Source/WebKit/mac
Revision 211362
Author akl...@apple.com
Date 2017-01-30 04:07:15 -0800 (Mon, 30 Jan 2017)
Log Message
[macOS] WebHTMLView has an internal retain cycle with its flagsChangedEventMonitor.
Reviewed by Antti Koivisto.
Avoid the implicit strong capture of self by keeping it in a __block variable.
Also add code to dealloc to unregister the event monitor, since it will otherwise leak.
This fixes huge WebHTMLView leaks seen on the leaks bot.
* WebView/WebHTMLView.mm:
(-[WebHTMLViewPrivate dealloc]):
(-[WebHTMLView viewDidMoveToWindow]):
Modified Paths
trunk/Source/WebKit/mac/ChangeLog
trunk/Source/WebKit/mac/WebView/WebHTMLView.mm
Diff
Modified: trunk/Source/WebKit/mac/ChangeLog (211361 => 211362)
--- trunk/Source/WebKit/mac/ChangeLog 2017-01-30 10:27:00 UTC (rev 211361)
+++ trunk/Source/WebKit/mac/ChangeLog 2017-01-30 12:07:15 UTC (rev 211362)
@@ -1,3 +1,18 @@
+2017-01-30 Andreas Kling
+
+[macOS] WebHTMLView has an internal retain cycle with its flagsChangedEventMonitor.
+
+
+Reviewed by Antti Koivisto.
+
+Avoid the implicit strong capture of self by keeping it in a __block variable.
+Also add code to dealloc to unregister the event monitor, since it will otherwise leak.
+This fixes huge WebHTMLView leaks seen on the leaks bot.
+
+* WebView/WebHTMLView.mm:
+(-[WebHTMLViewPrivate dealloc]):
+(-[WebHTMLView viewDidMoveToWindow]):
+
2017-01-29 Andy Estes
[QuickLook] Add a WebPreference to enable saving QuickLook documents in WebKitLegacy
Modified: trunk/Source/WebKit/mac/WebView/WebHTMLView.mm (211361 => 211362)
--- trunk/Source/WebKit/mac/WebView/WebHTMLView.mm 2017-01-30 10:27:00 UTC (rev 211361)
+++ trunk/Source/WebKit/mac/WebView/WebHTMLView.mm 2017-01-30 12:07:15 UTC (rev 211362)
@@ -1066,6 +1066,11 @@
#if !PLATFORM(IOS)
if (promisedDragTIFFDataSource)
promisedDragTIFFDataSource->removeClient(promisedDataClient());
+
+if (flagsChangedEventMonitor) {
+[NSEvent removeMonitor:flagsChangedEventMonitor];
+flagsChangedEventMonitor = nil;
+}
#endif
[super dealloc];
@@ -3504,8 +3509,9 @@
#if !PLATFORM(IOS)
if (!_private->flagsChangedEventMonitor) {
+__block WebHTMLView *weakSelf = self;
_private->flagsChangedEventMonitor = [NSEvent addLocalMonitorForEventsMatchingMask:NSEventMaskFlagsChanged handler:^(NSEvent *flagsChangedEvent) {
-[self _postFakeMouseMovedEventForFlagsChangedEvent:flagsChangedEvent];
+[weakSelf _postFakeMouseMovedEventForFlagsChangedEvent:flagsChangedEvent];
return flagsChangedEvent;
}];
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [211336] trunk/Source/WebCore
Revision 211336
Author akl...@apple.com
Date 2017-01-28 07:19:59 -0800 (Sat, 28 Jan 2017)
Log Message
Avoid synchronous style recalc in dispatchUnloadEvents().
Reviewed by Antti Koivisto.
It shouldn't be necessary to force a synchronous style resolution in an unloading document.
This call has been here since the import of KHTMLPart.
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::dispatchUnloadEvents):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/loader/FrameLoader.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (211335 => 211336)
--- trunk/Source/WebCore/ChangeLog 2017-01-28 12:16:23 UTC (rev 211335)
+++ trunk/Source/WebCore/ChangeLog 2017-01-28 15:19:59 UTC (rev 211336)
@@ -1,5 +1,18 @@
2017-01-28 Andreas Kling
+Avoid synchronous style recalc in dispatchUnloadEvents().
+
+
+Reviewed by Antti Koivisto.
+
+It shouldn't be necessary to force a synchronous style resolution in an unloading document.
+This call has been here since the import of KHTMLPart.
+
+* loader/FrameLoader.cpp:
+(WebCore::FrameLoader::dispatchUnloadEvents):
+
+2017-01-28 Andreas Kling
+
REGRESSION(r196383): Automatic shrink-to-fit of RuleSet no longer works.
Modified: trunk/Source/WebCore/loader/FrameLoader.cpp (211335 => 211336)
--- trunk/Source/WebCore/loader/FrameLoader.cpp 2017-01-28 12:16:23 UTC (rev 211335)
+++ trunk/Source/WebCore/loader/FrameLoader.cpp 2017-01-28 15:19:59 UTC (rev 211336)
@@ -2941,8 +2941,6 @@
}
}
m_pageDismissalEventBeingDispatched = PageDismissalType::None;
-if (m_frame.document())
-m_frame.document()->updateStyleIfNeeded();
m_wasUnloadEventEmitted = true;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [211252] branches/safari-603-branch/Source/WebCore
Revision 211252
Author akl...@apple.com
Date 2017-01-26 20:29:16 -0800 (Thu, 26 Jan 2017)
Log Message
Branch-specific fix for a crash seen after merging r201777.
Reviewed by Andy Estes.
Add null checking of the FrameView in Document::destroyRenderTree() before
calling functions on it. This is not necessary in trunk, as the FrameView
is guaranteed to be present there.
FrameView can be missing on the branch, since render trees for page cached documents
are destroyed when leaving the page cache, not when entering it (trunk behavior.)
When leaving the page cache, the FrameView is already detached, hence the bug.
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree):
Modified Paths
branches/safari-603-branch/Source/WebCore/ChangeLog
branches/safari-603-branch/Source/WebCore/dom/Document.cpp
Diff
Modified: branches/safari-603-branch/Source/WebCore/ChangeLog (211251 => 211252)
--- branches/safari-603-branch/Source/WebCore/ChangeLog 2017-01-27 04:22:29 UTC (rev 211251)
+++ branches/safari-603-branch/Source/WebCore/ChangeLog 2017-01-27 04:29:16 UTC (rev 211252)
@@ -1,3 +1,21 @@
+2017-01-26 Andreas Kling
+
+Branch-specific fix for a crash seen after merging r201777.
+
+
+Reviewed by Andy Estes.
+
+Add null checking of the FrameView in Document::destroyRenderTree() before
+calling functions on it. This is not necessary in trunk, as the FrameView
+is guaranteed to be present there.
+
+FrameView can be missing on the branch, since render trees for page cached documents
+are destroyed when leaving the page cache, not when entering it (trunk behavior.)
+When leaving the page cache, the FrameView is already detached, hence the bug.
+
+* dom/Document.cpp:
+(WebCore::Document::destroyRenderTree):
+
2017-01-25 Matthew Hanson
Merge r211151. rdar://problem/30171195
Modified: branches/safari-603-branch/Source/WebCore/dom/Document.cpp (211251 => 211252)
--- branches/safari-603-branch/Source/WebCore/dom/Document.cpp 2017-01-27 04:22:29 UTC (rev 211251)
+++ branches/safari-603-branch/Source/WebCore/dom/Document.cpp 2017-01-27 04:29:16 UTC (rev 211252)
@@ -2219,10 +2219,7 @@
{
ASSERT(hasLivingRenderTree());
ASSERT(m_pageCacheState != InPageCache);
-ASSERT(frame()->view());
-FrameView& frameView = *frame()->view();
-
SetForScope change(m_renderTreeBeingDestroyed, true);
if (this == ())
@@ -2230,7 +2227,8 @@
documentWillBecomeInactive();
-frameView.willDestroyRenderTree();
+if (auto* frameView = view())
+frameView->willDestroyRenderTree();
#if ENABLE(FULLSCREEN_API)
if (m_fullScreenRenderer)
@@ -2257,7 +2255,8 @@
m_textAutoSizedNodes.clear();
#endif
-frameView.didDestroyRenderTree();
+if (auto* frameView = view())
+frameView->didDestroyRenderTree();
}
void Document::prepareForDestruction()
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210836] trunk/Source/WebCore
Revision 210836
Author akl...@apple.com
Date 2017-01-17 17:21:16 -0800 (Tue, 17 Jan 2017)
Log Message
WidthCache should be off while under memory pressure.
Reviewed by Antti Koivisto.
Since we empty all the WidthCaches when we come under memory pressure, we shouldn't
repopulate them until the pressure has gone away.
* platform/graphics/WidthCache.h:
(WebCore::WidthCache::add):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/platform/graphics/WidthCache.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (210835 => 210836)
--- trunk/Source/WebCore/ChangeLog 2017-01-18 01:14:33 UTC (rev 210835)
+++ trunk/Source/WebCore/ChangeLog 2017-01-18 01:21:16 UTC (rev 210836)
@@ -1,3 +1,16 @@
+2017-01-17 Andreas Kling
+
+WidthCache should be off while under memory pressure.
+
+
+Reviewed by Antti Koivisto.
+
+Since we empty all the WidthCaches when we come under memory pressure, we shouldn't
+repopulate them until the pressure has gone away.
+
+* platform/graphics/WidthCache.h:
+(WebCore::WidthCache::add):
+
2017-01-17 Antti Koivisto
Persist derived data
Modified: trunk/Source/WebCore/platform/graphics/WidthCache.h (210835 => 210836)
--- trunk/Source/WebCore/platform/graphics/WidthCache.h 2017-01-18 01:14:33 UTC (rev 210835)
+++ trunk/Source/WebCore/platform/graphics/WidthCache.h 2017-01-18 01:21:16 UTC (rev 210836)
@@ -26,6 +26,7 @@
#ifndef WidthCache_h
#define WidthCache_h
+#include "MemoryPressureHandler.h"
#include "TextRun.h"
#include
#include
@@ -120,6 +121,8 @@
float* add(const TextRun& run, float entry, bool hasKerningOrLigatures, bool hasWordSpacingOrLetterSpacing, GlyphOverflow* glyphOverflow)
{
+if (MemoryPressureHandler::singleton().isUnderMemoryPressure())
+return nullptr;
// The width cache is not really profitable unless we're doing expensive glyph transformations.
if (!hasKerningOrLigatures)
return 0;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210777] trunk/Source/WebCore
Revision 210777
Author akl...@apple.com
Date 2017-01-15 02:48:04 -0800 (Sun, 15 Jan 2017)
Log Message
FrameView shouldn't keep dangling pointers into dead render trees.
Reviewed by Antti Koivisto.
Added some pretty paranoid assertions to FrameView that verify all of its raw pointers
into the render tree are gone after the render tree has been destroyed.
They immediately caught two bugs, also fixed in this patch.
* page/FrameView.h:
* page/FrameView.cpp:
(WebCore::FrameView::willDestroyRenderTree):
(WebCore::FrameView::didDestroyRenderTree): Added these two callbacks for before/after
Document tears down its render tree. The former clears the layout root, and detaches
custom scrollbars. The latter contains a bunch of sanity assertions that pointers into
the now-destroyed render tree are gone.
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree): Notify FrameView before/after teardown.
* page/animation/AnimationController.h:
* page/animation/AnimationController.cpp:
(WebCore::AnimationController::hasAnimations): Added a helper to check if there are
any composite animations around, as these contain raw pointers to renderers.
* rendering/RenderElement.cpp:
(WebCore::RenderElement::willBeRemovedFromTree):
(WebCore::RenderElement::willBeDestroyed): Moved slow repaint object unregistration
from willBeRemovedFromTree() to willBeDestroyed(). The willBeRemovedFromTree() callback
is skipped as an optimization during full tree teardown, but willBeDestroyed() always
gets called. This fixes a bug where we'd fail to remove dangling pointers.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
trunk/Source/WebCore/page/FrameView.cpp
trunk/Source/WebCore/page/FrameView.h
trunk/Source/WebCore/page/animation/AnimationController.cpp
trunk/Source/WebCore/page/animation/AnimationController.h
trunk/Source/WebCore/rendering/RenderElement.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (210776 => 210777)
--- trunk/Source/WebCore/ChangeLog 2017-01-15 08:23:31 UTC (rev 210776)
+++ trunk/Source/WebCore/ChangeLog 2017-01-15 10:48:04 UTC (rev 210777)
@@ -1,3 +1,37 @@
+2017-01-15 Andreas Kling
+
+FrameView shouldn't keep dangling pointers into dead render trees.
+
+
+Reviewed by Antti Koivisto.
+
+Added some pretty paranoid assertions to FrameView that verify all of its raw pointers
+into the render tree are gone after the render tree has been destroyed.
+They immediately caught two bugs, also fixed in this patch.
+
+* page/FrameView.h:
+* page/FrameView.cpp:
+(WebCore::FrameView::willDestroyRenderTree):
+(WebCore::FrameView::didDestroyRenderTree): Added these two callbacks for before/after
+Document tears down its render tree. The former clears the layout root, and detaches
+custom scrollbars. The latter contains a bunch of sanity assertions that pointers into
+the now-destroyed render tree are gone.
+
+* dom/Document.cpp:
+(WebCore::Document::destroyRenderTree): Notify FrameView before/after teardown.
+
+* page/animation/AnimationController.h:
+* page/animation/AnimationController.cpp:
+(WebCore::AnimationController::hasAnimations): Added a helper to check if there are
+any composite animations around, as these contain raw pointers to renderers.
+
+* rendering/RenderElement.cpp:
+(WebCore::RenderElement::willBeRemovedFromTree):
+(WebCore::RenderElement::willBeDestroyed): Moved slow repaint object unregistration
+from willBeRemovedFromTree() to willBeDestroyed(). The willBeRemovedFromTree() callback
+is skipped as an optimization during full tree teardown, but willBeDestroyed() always
+gets called. This fixes a bug where we'd fail to remove dangling pointers.
+
2017-01-15 Myles C. Maxfield
[Cocoa] Unify font fallback between macOS and iOS for when the font-family list is exhausted
Modified: trunk/Source/WebCore/dom/Document.cpp (210776 => 210777)
--- trunk/Source/WebCore/dom/Document.cpp 2017-01-15 08:23:31 UTC (rev 210776)
+++ trunk/Source/WebCore/dom/Document.cpp 2017-01-15 10:48:04 UTC (rev 210777)
@@ -2199,8 +2199,11 @@
{
ASSERT(hasLivingRenderTree());
ASSERT(frame());
+ASSERT(frame()->view());
ASSERT(page());
+FrameView& frameView = *frame()->view();
+
// Prevent Widget tree changes from committing until the RenderView is dead and gone.
WidgetHierarchyUpdatesSuspensionScope suspendWidgetHierarchyUpdates;
@@ -2211,8 +2214,7 @@
documentWillBecomeInactive();
-if (FrameView* frameView = view())
-frameView->detachCustomScrollbars();
+frameView.willDestroyRenderTree();
#if ENABLE(FULLSCREEN_API)
if (m_fullScreenRenderer)
@@ -2238,6 +2240,8 @@
// Do this before the arena is cleared, which is needed to deref
Title: [210666] trunk/Source/WebKit2
Revision 210666
Author akl...@apple.com
Date 2017-01-12 09:52:59 -0800 (Thu, 12 Jan 2017)
Log Message
WebBackForwardListProxy should remove restored session history items from PageCache on close.
Reviewed by Brady Eidson.
Register history item ID's from the UIProcess with the associated-items map
so that we can remove any PageCache entries associated with them immediately
when closing a WebPage.
Otherwise they might not get removed until the next PageCache pruning happens.
This patch is a speculative fix for what looks like it might be weirdness
related to a PageCache entry outliving its originating Page.
* WebProcess/WebPage/WebBackForwardListProxy.cpp:
(WebKit::WebBackForwardListProxy::addItemFromUIProcess):
* WebProcess/WebPage/WebBackForwardListProxy.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::restoreSessionInternal):
Modified Paths
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.cpp
trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.h
trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp
Diff
Modified: trunk/Source/WebKit2/ChangeLog (210665 => 210666)
--- trunk/Source/WebKit2/ChangeLog 2017-01-12 17:49:32 UTC (rev 210665)
+++ trunk/Source/WebKit2/ChangeLog 2017-01-12 17:52:59 UTC (rev 210666)
@@ -1,3 +1,25 @@
+2017-01-12 Andreas Kling
+
+WebBackForwardListProxy should remove restored session history items from PageCache on close.
+
+
+
+Reviewed by Brady Eidson.
+
+Register history item ID's from the UIProcess with the associated-items map
+so that we can remove any PageCache entries associated with them immediately
+when closing a WebPage.
+
+Otherwise they might not get removed until the next PageCache pruning happens.
+This patch is a speculative fix for what looks like it might be weirdness
+related to a PageCache entry outliving its originating Page.
+
+* WebProcess/WebPage/WebBackForwardListProxy.cpp:
+(WebKit::WebBackForwardListProxy::addItemFromUIProcess):
+* WebProcess/WebPage/WebBackForwardListProxy.h:
+* WebProcess/WebPage/WebPage.cpp:
+(WebKit::WebPage::restoreSessionInternal):
+
2017-01-12 Michael Catanzaro
[GTK] Correct license on WebKitSecurityOrigin headers
Modified: trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.cpp (210665 => 210666)
--- trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.cpp 2017-01-12 17:49:32 UTC (rev 210665)
+++ trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.cpp 2017-01-12 17:52:59 UTC (rev 210666)
@@ -100,6 +100,8 @@
ASSERT(!historyItemToIDMap().contains(item.ptr()));
ASSERT(!idToHistoryItemMap().contains(itemID));
+m_associatedItemIDs.add(itemID);
+
historyItemToIDMap().set(item.ptr(), { .itemID = itemID, .pageID = pageID });
idToHistoryItemMap().set(itemID, item.ptr());
}
Modified: trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.h (210665 => 210666)
--- trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.h 2017-01-12 17:49:32 UTC (rev 210665)
+++ trunk/Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.h 2017-01-12 17:52:59 UTC (rev 210666)
@@ -41,7 +41,7 @@
static uint64_t idForItem(WebCore::HistoryItem*);
static void removeItem(uint64_t itemID);
-static void addItemFromUIProcess(uint64_t itemID, Ref&&, uint64_t pageID);
+void addItemFromUIProcess(uint64_t itemID, Ref&&, uint64_t pageID);
static void setHighestItemIDFromUIProcess(uint64_t itemID);
void clear();
Modified: trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp (210665 => 210666)
--- trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp 2017-01-12 17:49:32 UTC (rev 210665)
+++ trunk/Source/WebKit2/WebProcess/WebPage/WebPage.cpp 2017-01-12 17:52:59 UTC (rev 210666)
@@ -115,6 +115,7 @@
#include <_javascript_Core/APICast.h>
#include
#include
+#include
#include
#include
#include
@@ -2330,7 +2331,7 @@
for (const auto& itemState : itemStates) {
auto historyItem = toHistoryItem(itemState.pageState);
historyItem->setWasRestoredFromSession(restoredByAPIRequest == WasRestoredByAPIRequest::Yes);
-WebBackForwardListProxy::addItemFromUIProcess(itemState.identifier, WTFMove(historyItem), m_pageID);
+static_cast(corePage()->backForward().client())->addItemFromUIProcess(itemState.identifier, WTFMove(historyItem), m_pageID);
}
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210609] trunk/Source
Revision 210609
Author akl...@apple.com
Date 2017-01-11 16:55:32 -0800 (Wed, 11 Jan 2017)
Log Message
Crash when WebCore's GC heap grows way too large.
Reviewed by Mark Lam.
Source/_javascript_Core:
Add a simple API to JSC::Heap that allows setting a hard limit on the amount
of live bytes. If this is exceeded, we crash with a recognizable signature.
By default there is no limit.
* heap/Heap.cpp:
(JSC::Heap::didExceedMaxLiveSize):
(JSC::Heap::updateAllocationLimits):
* heap/Heap.h:
(JSC::Heap::setMaxLiveSize):
Source/WebCore:
Cap the common WebCore VM at 4 GB of live _javascript_ heap objects.
* bindings/js/CommonVM.cpp:
(WebCore::commonVMSlow):
Source/WTF:
Publish the WTF::GB constant.
* wtf/StdLibExtras.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/Heap.cpp
trunk/Source/_javascript_Core/heap/Heap.h
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/StdLibExtras.h
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/bindings/js/CommonVM.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (210608 => 210609)
--- trunk/Source/_javascript_Core/ChangeLog 2017-01-12 00:44:42 UTC (rev 210608)
+++ trunk/Source/_javascript_Core/ChangeLog 2017-01-12 00:55:32 UTC (rev 210609)
@@ -1,3 +1,21 @@
+2017-01-11 Andreas Kling
+
+Crash when WebCore's GC heap grows way too large.
+
+
+
+Reviewed by Mark Lam.
+
+Add a simple API to JSC::Heap that allows setting a hard limit on the amount
+of live bytes. If this is exceeded, we crash with a recognizable signature.
+By default there is no limit.
+
+* heap/Heap.cpp:
+(JSC::Heap::didExceedMaxLiveSize):
+(JSC::Heap::updateAllocationLimits):
+* heap/Heap.h:
+(JSC::Heap::setMaxLiveSize):
+
2017-01-11 Yusuke Suzuki
Decouple module loading initiator from ScriptElement
Modified: trunk/Source/_javascript_Core/heap/Heap.cpp (210608 => 210609)
--- trunk/Source/_javascript_Core/heap/Heap.cpp 2017-01-12 00:44:42 UTC (rev 210608)
+++ trunk/Source/_javascript_Core/heap/Heap.cpp 2017-01-12 00:55:32 UTC (rev 210609)
@@ -1676,6 +1676,11 @@
m_sweeper->startSweeping();
}
+NEVER_INLINE void Heap::didExceedMaxLiveSize()
+{
+CRASH();
+}
+
void Heap::updateAllocationLimits()
{
static const bool verbose = false;
@@ -1707,6 +1712,9 @@
if (verbose)
dataLog("extraMemorySize() = ", extraMemorySize(), ", currentHeapSize = ", currentHeapSize, "\n");
+
+if (m_maxLiveSize && currentHeapSize > m_maxLiveSize)
+didExceedMaxLiveSize();
if (Options::gcMaxHeapSize() && currentHeapSize > Options::gcMaxHeapSize())
HeapStatistics::exitWithFailure();
Modified: trunk/Source/_javascript_Core/heap/Heap.h (210608 => 210609)
--- trunk/Source/_javascript_Core/heap/Heap.h 2017-01-12 00:44:42 UTC (rev 210608)
+++ trunk/Source/_javascript_Core/heap/Heap.h 2017-01-12 00:55:32 UTC (rev 210609)
@@ -131,6 +131,9 @@
void lastChanceToFinalize();
void releaseDelayedReleasedObjects();
+// Set a hard limit where JSC will crash if live heap size exceeds it.
+void setMaxLiveSize(size_t size) { m_maxLiveSize = size; }
+
VM* vm() const { return m_vm; }
MarkedSpace& objectSpace() { return m_objectSpace; }
MachineThreads& machineThreads() { return m_machineThreads; }
@@ -619,6 +622,9 @@
size_t m_blockBytesAllocated { 0 };
size_t m_externalMemorySize { 0 };
#endif
+
+NO_RETURN_DUE_TO_CRASH void didExceedMaxLiveSize();
+size_t m_maxLiveSize { 0 };
std::unique_ptr m_scheduler;
Modified: trunk/Source/WTF/ChangeLog (210608 => 210609)
--- trunk/Source/WTF/ChangeLog 2017-01-12 00:44:42 UTC (rev 210608)
+++ trunk/Source/WTF/ChangeLog 2017-01-12 00:55:32 UTC (rev 210609)
@@ -1,3 +1,15 @@
+2017-01-11 Andreas Kling
+
+Crash when WebCore's GC heap grows way too large.
+
+
+
+Reviewed by Mark Lam.
+
+Publish the WTF::GB constant.
+
+* wtf/StdLibExtras.h:
+
2017-01-11 Anders Carlsson
navigator.plugins.refresh and WKContextRefreshPlugIns doesn't pick up changes to already-present plug-ins
Modified: trunk/Source/WTF/wtf/StdLibExtras.h (210608 => 210609)
--- trunk/Source/WTF/wtf/StdLibExtras.h 2017-01-12 00:44:42 UTC (rev 210608)
+++ trunk/Source/WTF/wtf/StdLibExtras.h 2017-01-12 00:55:32 UTC (rev 210609)
@@ -477,6 +477,7 @@
using WTF::KB;
using WTF::MB;
+using WTF::GB;
using WTF::approximateBinarySearch;
using WTF::binarySearch;
using WTF::bitwise_cast;
Modified: trunk/Source/WebCore/ChangeLog (210608 => 210609)
--- trunk/Source/WebCore/ChangeLog 2017-01-12 00:44:42 UTC (rev 210608)
+++ trunk/Source/WebCore/ChangeLog 2017-01-12 00:55:32 UTC (rev 210609)
@@ -1,3 +1,16 @@
+2017-01-11 Andreas Kling
+
+Crash when
Title: [210540] trunk/Source/_javascript_Core
Revision 210540
Author akl...@apple.com
Date 2017-01-10 04:16:35 -0800 (Tue, 10 Jan 2017)
Log Message
Crash when GC heap grows way too large.
Reviewed by Mark Lam.
Hard cap the _javascript_ heap at 4GB of live objects (determined post-GC.)
If we go past this limit, crash with a recognizable signature.
* heap/Heap.cpp:
(JSC::Heap::didExceedHeapSizeLimit):
(JSC::Heap::updateAllocationLimits):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/Heap.cpp
trunk/Source/_javascript_Core/heap/Heap.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (210539 => 210540)
--- trunk/Source/_javascript_Core/ChangeLog 2017-01-10 11:03:12 UTC (rev 210539)
+++ trunk/Source/_javascript_Core/ChangeLog 2017-01-10 12:16:35 UTC (rev 210540)
@@ -1,3 +1,18 @@
+2017-01-10 Andreas Kling
+
+Crash when GC heap grows way too large.
+
+
+
+Reviewed by Mark Lam.
+
+Hard cap the _javascript_ heap at 4GB of live objects (determined post-GC.)
+If we go past this limit, crash with a recognizable signature.
+
+* heap/Heap.cpp:
+(JSC::Heap::didExceedHeapSizeLimit):
+(JSC::Heap::updateAllocationLimits):
+
2017-01-09 Yusuke Suzuki
Implement JSSourceCode to propagate SourceCode in module pipeline
Modified: trunk/Source/_javascript_Core/heap/Heap.cpp (210539 => 210540)
--- trunk/Source/_javascript_Core/heap/Heap.cpp 2017-01-10 11:03:12 UTC (rev 210539)
+++ trunk/Source/_javascript_Core/heap/Heap.cpp 2017-01-10 12:16:35 UTC (rev 210540)
@@ -1646,6 +1646,11 @@
m_sweeper->startSweeping();
}
+NEVER_INLINE void Heap::didExceedHeapSizeLimit()
+{
+CRASH();
+}
+
void Heap::updateAllocationLimits()
{
static const bool verbose = false;
@@ -1677,6 +1682,12 @@
if (verbose)
dataLog("extraMemorySize() = ", extraMemorySize(), ", currentHeapSize = ", currentHeapSize, "\n");
+
+#if USE(JSVALUE64)
+// If the heap has grown larger than 4GB, just crash before things get out of control.
+if (currentHeapSize > 4096 * MB)
+didExceedHeapSizeLimit();
+#endif
if (Options::gcMaxHeapSize() && currentHeapSize > Options::gcMaxHeapSize())
HeapStatistics::exitWithFailure();
Modified: trunk/Source/_javascript_Core/heap/Heap.h (210539 => 210540)
--- trunk/Source/_javascript_Core/heap/Heap.h 2017-01-10 11:03:12 UTC (rev 210539)
+++ trunk/Source/_javascript_Core/heap/Heap.h 2017-01-10 12:16:35 UTC (rev 210540)
@@ -507,6 +507,8 @@
void assertSharedMarkStacksEmpty();
+NO_RETURN_DUE_TO_CRASH void didExceedHeapSizeLimit();
+
const HeapType m_heapType;
const size_t m_ramSize;
const size_t m_minBytesPerCycle;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210498] trunk/Source/_javascript_Core
Revision 210498
Author akl...@apple.com
Date 2017-01-08 21:35:14 -0800 (Sun, 08 Jan 2017)
Log Message
Inject MarkedSpace size classes for a few more high-volume objects.
Reviewed by Darin Adler.
Add the following classes to the list of manually injected size classes:
- JSString
- JSFunction
- PropertyTable
- Structure
Only Structure actually ends up with a new size class, the others already
can't get any tighter due to the current MarkedBlock::atomSize being 16.
I've put them in anyway to ensure that we have optimally carved-out cells
for them in the future, should they grow.
With this change, Structures get allocated in 128-byte cells instead of
160-byte cells, giving us 25% more Structures per MarkedBlock.
* heap/MarkedSpace.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/MarkedSpace.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (210497 => 210498)
--- trunk/Source/_javascript_Core/ChangeLog 2017-01-09 04:12:17 UTC (rev 210497)
+++ trunk/Source/_javascript_Core/ChangeLog 2017-01-09 05:35:14 UTC (rev 210498)
@@ -1,3 +1,27 @@
+2017-01-08 Andreas Kling
+
+Inject MarkedSpace size classes for a few more high-volume objects.
+
+
+Reviewed by Darin Adler.
+
+Add the following classes to the list of manually injected size classes:
+
+- JSString
+- JSFunction
+- PropertyTable
+- Structure
+
+Only Structure actually ends up with a new size class, the others already
+can't get any tighter due to the current MarkedBlock::atomSize being 16.
+I've put them in anyway to ensure that we have optimally carved-out cells
+for them in the future, should they grow.
+
+With this change, Structures get allocated in 128-byte cells instead of
+160-byte cells, giving us 25% more Structures per MarkedBlock.
+
+* heap/MarkedSpace.cpp:
+
2017-01-06 Saam Barati
Add a slice intrinsic to the DFG/FTL
Modified: trunk/Source/_javascript_Core/heap/MarkedSpace.cpp (210497 => 210498)
--- trunk/Source/_javascript_Core/heap/MarkedSpace.cpp 2017-01-09 04:12:17 UTC (rev 210497)
+++ trunk/Source/_javascript_Core/heap/MarkedSpace.cpp 2017-01-09 05:35:14 UTC (rev 210498)
@@ -130,10 +130,15 @@
add(betterSizeClass);
}
+// Manually inject size classes for objects we know will be allocated in high volume.
add(sizeof(UnlinkedFunctionExecutable));
add(sizeof(UnlinkedFunctionCodeBlock));
add(sizeof(FunctionExecutable));
add(sizeof(FunctionCodeBlock));
+add(sizeof(JSString));
+add(sizeof(JSFunction));
+add(sizeof(PropertyTable));
+add(sizeof(Structure));
{
// Sort and deduplicate.
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210436] trunk/Source/WebCore
Revision 210436
Author akl...@apple.com
Date 2017-01-06 06:05:29 -0800 (Fri, 06 Jan 2017)
Log Message
Give RenderObject a Page& getter.
Reviewed by Darin Adler.
The render tree should now only ever be live while in a Frame that's connected to a Page.
Hence we can give RenderObject a Page& getter and simplify a lot of code that previously
had to get the Page from Document (or Frame) and perform null checks on it.
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree): Assert that the Page is present when we tear the render tree down.
* page/Frame.cpp:
(WebCore::Frame::willDetachPage): Assert that there's no render tree when we're about to detach from the Page.
Also added a comment explaining the two main ways that render trees die.
* rendering/RenderObject.h:
(WebCore::RenderObject::page): Added. So neat!
* accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::estimatedLoadingProgress):
* rendering/ImageQualityController.cpp:
(WebCore::ImageQualityController::chooseInterpolationQuality):
* rendering/InlineTextBox.cpp:
(WebCore::InlineTextBox::paint):
* rendering/RenderAttachment.cpp:
(WebCore::RenderAttachment::layout):
(WebCore::RenderAttachment::baselinePosition):
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::paintCaret):
* rendering/RenderBox.cpp:
(WebCore::RenderBox::styleDidChange):
(WebCore::setupWheelEventTestTrigger):
(WebCore::RenderBox::setScrollLeft):
(WebCore::RenderBox::setScrollTop):
* rendering/RenderElement.cpp:
(WebCore::RenderElement::paintFocusRing):
* rendering/RenderEmbeddedObject.cpp:
(WebCore::shouldUnavailablePluginMessageBeButton):
(WebCore::RenderEmbeddedObject::paint):
(WebCore::RenderEmbeddedObject::paintReplaced):
(WebCore::RenderEmbeddedObject::getReplacementTextGeometry):
(WebCore::RenderEmbeddedObject::handleUnavailablePluginIndicatorEvent):
(WebCore::RenderEmbeddedObject::getCursor):
* rendering/RenderHTMLCanvas.cpp:
(WebCore::RenderHTMLCanvas::paintReplaced):
* rendering/RenderIFrame.cpp:
(WebCore::RenderIFrame::flattenFrame):
* rendering/RenderImage.cpp:
(WebCore::RenderImage::paintReplaced):
(WebCore::RenderImage::paintAreaElementFocusRing):
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::~RenderLayer):
(WebCore::RenderLayer::forceUpdateScrollbarsOnMainThreadForPerformanceTesting):
(WebCore::RenderLayer::scrollRectToVisible):
(WebCore::RenderLayer::isActive):
(WebCore::RenderLayer::didStartScroll):
(WebCore::RenderLayer::didEndScroll):
(WebCore::RenderLayer::didUpdateScroll):
(WebCore::RenderLayer::createScrollbar):
(WebCore::RenderLayer::setupFontSubpixelQuantization):
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderLayer.h:
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::RenderLayerBacking):
(WebCore::RenderLayerBacking::createGraphicsLayer):
(WebCore::RenderLayerBacking::updateOverflowControlsLayers):
(WebCore::RenderLayerBacking::detachFromScrollingCoordinator):
(WebCore::RenderLayerBacking::paintContents):
(WebCore::RenderLayerBacking::shouldAggressivelyRetainTiles):
(WebCore::RenderLayerBacking::shouldTemporarilyRetainTileCohorts):
(WebCore::RenderLayerBacking::useGiantTiles):
(WebCore::RenderLayerBacking::verifyNotPainting):
(WebCore::RenderLayerBacking::startAnimation):
(WebCore::scrollingCoordinatorFromLayer): Deleted.
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::cacheAcceleratedCompositingFlags):
(WebCore::RenderLayerCompositor::scheduleLayerFlushNow):
(WebCore::RenderLayerCompositor::flushPendingLayerChanges):
(WebCore::updateScrollingLayerWithClient):
(WebCore::RenderLayerCompositor::updateCustomLayersAfterFlush):
(WebCore::RenderLayerCompositor::notifyFlushBeforeDisplayRefresh):
(WebCore::RenderLayerCompositor::layerTiledBackingUsageChanged):
(WebCore::RenderLayerCompositor::updateCompositingLayers):
(WebCore::RenderLayerCompositor::appendDocumentOverlayLayers):
(WebCore::RenderLayerCompositor::layerBecameNonComposited):
(WebCore::RenderLayerCompositor::updateBacking):
(WebCore::RenderLayerCompositor::pageScaleFactor):
(WebCore::RenderLayerCompositor::zoomedOutPageScaleFactor):
(WebCore::RenderLayerCompositor::contentsScaleMultiplierForNewTiles):
(WebCore::RenderLayerCompositor::updateLayerForHeader):
(WebCore::RenderLayerCompositor::updateLayerForFooter):
(WebCore::RenderLayerCompositor::setRootExtendedBackgroundColor):
(WebCore::RenderLayerCompositor::attachRootLayer):
(WebCore::RenderLayerCompositor::detachRootLayer):
(WebCore::RenderLayerCompositor::rootLayerAttachmentChanged):
(WebCore::RenderLayerCompositor::registerAllScrollingLayers):
(WebCore::RenderLayerCompositor::scrollingCoordinator):
(WebCore::RenderLayerCompositor::graphicsLayerFactory):
(WebCore::RenderLayerCompositor::createDisplayRefreshMonitor):
(WebCore::RenderLayerCompositor::page):
* rendering/RenderLayerCompositor.h:
* rendering/RenderListBox.cpp:
(WebCore::setupWheelEventTestTrigger):
(WebCore::RenderListBox::setScrollTop):
Title: [210329] trunk
Revision 210329
Author akl...@apple.com
Date 2017-01-05 08:02:44 -0800 (Thu, 05 Jan 2017)
Log Message
REGRESSION(r210226): overflow:scroll scroll position not restored on back navigation
Reviewed by Antti Koivisto.
Source/WebCore:
Before r210226, the render tree being torn down and the document being destroyed
were roughly the same thing, since they would always happen together, from the
render tree's perspective.
Changing this caused us to skip over the code that saves the scroll position
for an element's RenderLayer when going into the page cache. Navigating back to
that page would then scroll the layer to (0,0) instead of the previous position.
The fix is simply to remove the check for documentBeingDestroyed() in ~RenderLayer().
Note that two checks are being removed, there was also a weird "optimization"
to avoid nulling out EventHandler's m_resizeLayer if it points to this layer.
That pointer would eventually get nulled out in EventHandler::clear() anyway,
but it feels better to not let that pointer dangle.
Test: fast/scrolling/page-cache-back-overflow-scroll-restore.html
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::~RenderLayer):
LayoutTests:
Add a test that navigates back to a page with a scrolled overflow:scroll element.
The test verifies that the scroll position is restored.
* fast/scrolling/page-cache-back-overflow-scroll-restore-expected.txt: Added.
* fast/scrolling/page-cache-back-overflow-scroll-restore.html: Added.
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/rendering/RenderLayer.cpp
Added Paths
trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore-expected.txt
trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore.html
Diff
Modified: trunk/LayoutTests/ChangeLog (210328 => 210329)
--- trunk/LayoutTests/ChangeLog 2017-01-05 15:51:39 UTC (rev 210328)
+++ trunk/LayoutTests/ChangeLog 2017-01-05 16:02:44 UTC (rev 210329)
@@ -1,3 +1,16 @@
+2017-01-05 Andreas Kling
+
+REGRESSION(r210226): overflow:scroll scroll position not restored on back navigation
+
+
+Reviewed by Antti Koivisto.
+
+Add a test that navigates back to a page with a scrolled overflow:scroll element.
+The test verifies that the scroll position is restored.
+
+* fast/scrolling/page-cache-back-overflow-scroll-restore-expected.txt: Added.
+* fast/scrolling/page-cache-back-overflow-scroll-restore.html: Added.
+
2017-01-05 Per Arne Vollan
Unreviewed test gardening.
Added: trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore-expected.txt (0 => 210329)
--- trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore-expected.txt (rev 0)
+++ trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore-expected.txt 2017-01-05 16:02:44 UTC (rev 210329)
@@ -0,0 +1,18 @@
+ALERT: Going back.
+
+
+
+
+
+
+
+layer at (0,0) size 100x126 backgroundClip at (0,0) size 100x100 clip at (0,0) size 85x85 scrollY 41 scrollHeight 126
+ RenderBlock (positioned) {DIV} at (0,0) size 100x100 [bgcolor=#CC]
+RenderBR {BR} at (0,0) size 0x18
+RenderBR {BR} at (0,18) size 0x18
+RenderBR {BR} at (0,36) size 0x18
+RenderBR {BR} at (0,54) size 0x18
+RenderBR {BR} at (0,72) size 0x18
+RenderBR {BR} at (0,90) size 0x18
+RenderBR {BR} at (0,108) size 0x18
+
Added: trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore.html (0 => 210329)
--- trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore.html (rev 0)
+++ trunk/LayoutTests/fast/scrolling/page-cache-back-overflow-scroll-restore.html 2017-01-05 16:02:44 UTC (rev 210329)
@@ -0,0 +1,43 @@
+
+#puffin {
+font: Ahem 10px;
+position: absolute;
+top: 0;
+left: 0;
+overflow: scroll;
+width: 100px;
+height: 100px;
+background-color: #ccc;
+}
+
+
+
+
+
+
+
+
+
+
+
+
+testRunner.dumpAsText();
+testRunner.waitUntilDone();
+testRunner.overridePreference("WebKitUsesPageCachePreferenceKey", 1);
+
+window.addEventListener("pageshow", function(event) {
+if (event.persisted) {
+document.getElementById("tree").innerText = window.internals.elementRenderTreeAsText(document.getElementById("puffin"));
+testRunner.notifyDone();
+}
+}, false);
+
+window.addEventListener("load", function() {
+setTimeout(function() {
+eventSender.mouseMoveTo(10, 10);
+eventSender.mouseScrollBy(0, -100);
+
+setTimeout(function() {location.href = '' + 'script>';}, 0);
+}, 0);
+});
+
Modified: trunk/Source/WebCore/ChangeLog (210328 => 210329)
--- trunk/Source/WebCore/ChangeLog 2017-01-05 15:51:39 UTC (rev 210328)
+++ trunk/Source/WebCore/ChangeLog 2017-01-05 16:02:44 UTC (rev 210329)
@@ -1,3 +1,29 @@
+2017-01-05 Andreas Kling
+
+
Title: [210246] trunk/Source/WebCore
Revision 210246
Author akl...@apple.com
Date 2017-01-03 12:46:08 -0800 (Tue, 03 Jan 2017)
Log Message
REGRESSION(r210226): fast/history/back-from-page-with-focused-iframe.html crashes under GuardMalloc
Reviewed by Antti Koivisto.
The problem was that tearDownRenderers() would cause commit Widget hierarchy updates
before returning, which is just before Document clears its m_renderView pointer.
This led to an awkward callback into Page::setActivityState() which ended up trying
to clear the selection inside a partially dead render tree.
Fix this by adding a WidgetHierarchyUpdatesSuspensionScope to Document::destroyRenderTree()
which ensures that Widget updates don't happen until after Document::m_renderView is cleared.
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (210245 => 210246)
--- trunk/Source/WebCore/ChangeLog 2017-01-03 20:32:49 UTC (rev 210245)
+++ trunk/Source/WebCore/ChangeLog 2017-01-03 20:46:08 UTC (rev 210246)
@@ -1,5 +1,24 @@
2017-01-03 Andreas Kling
+REGRESSION(r210226): fast/history/back-from-page-with-focused-iframe.html crashes under GuardMalloc
+
+
+
+Reviewed by Antti Koivisto.
+
+The problem was that tearDownRenderers() would cause commit Widget hierarchy updates
+before returning, which is just before Document clears its m_renderView pointer.
+This led to an awkward callback into Page::setActivityState() which ended up trying
+to clear the selection inside a partially dead render tree.
+
+Fix this by adding a WidgetHierarchyUpdatesSuspensionScope to Document::destroyRenderTree()
+which ensures that Widget updates don't happen until after Document::m_renderView is cleared.
+
+* dom/Document.cpp:
+(WebCore::Document::destroyRenderTree):
+
+2017-01-03 Andreas Kling
+
Placeholder style mechanism leaks CSSFontSelector for first Document styled.
Modified: trunk/Source/WebCore/dom/Document.cpp (210245 => 210246)
--- trunk/Source/WebCore/dom/Document.cpp 2017-01-03 20:32:49 UTC (rev 210245)
+++ trunk/Source/WebCore/dom/Document.cpp 2017-01-03 20:46:08 UTC (rev 210246)
@@ -2203,6 +2203,9 @@
{
ASSERT(hasLivingRenderTree());
+// Prevent Widget tree changes from committing until the RenderView is dead and gone.
+WidgetHierarchyUpdatesSuspensionScope suspendWidgetHierarchyUpdates;
+
SetForScope change(m_renderTreeBeingDestroyed, true);
if (this == ())
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210240] trunk/Source/WebCore
Revision 210240
Author akl...@apple.com
Date 2017-01-03 10:53:04 -0800 (Tue, 03 Jan 2017)
Log Message
Placeholder style mechanism leaks CSSFontSelector for first Document styled.
Reviewed by Antti Koivisto.
The placeholder style is used when we're resolving style for a non-rendered
element, or any element before stylesheets have loaded.
An old optimization had us reusing the same style each time, which meant that
since it was initialized with a font selector the first time, it kept that
font selector alive forever.
As we have to clone the style anyway, fix this by just making a new style
each time, using the current document's font selector.
* style/StyleTreeResolver.cpp:
(WebCore::Style::makePlaceholderStyle):
(WebCore::Style::TreeResolver::TreeResolver):
(WebCore::Style::TreeResolver::styleForElement):
(WebCore::Style::ensurePlaceholderStyle): Deleted.
(WebCore::Style::isPlaceholderStyle): Deleted.
* style/StyleTreeResolver.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/style/StyleTreeResolver.cpp
trunk/Source/WebCore/style/StyleTreeResolver.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (210239 => 210240)
--- trunk/Source/WebCore/ChangeLog 2017-01-03 15:02:26 UTC (rev 210239)
+++ trunk/Source/WebCore/ChangeLog 2017-01-03 18:53:04 UTC (rev 210240)
@@ -1,3 +1,28 @@
+2017-01-03 Andreas Kling
+
+Placeholder style mechanism leaks CSSFontSelector for first Document styled.
+
+
+Reviewed by Antti Koivisto.
+
+The placeholder style is used when we're resolving style for a non-rendered
+element, or any element before stylesheets have loaded.
+
+An old optimization had us reusing the same style each time, which meant that
+since it was initialized with a font selector the first time, it kept that
+font selector alive forever.
+
+As we have to clone the style anyway, fix this by just making a new style
+each time, using the current document's font selector.
+
+* style/StyleTreeResolver.cpp:
+(WebCore::Style::makePlaceholderStyle):
+(WebCore::Style::TreeResolver::TreeResolver):
+(WebCore::Style::TreeResolver::styleForElement):
+(WebCore::Style::ensurePlaceholderStyle): Deleted.
+(WebCore::Style::isPlaceholderStyle): Deleted.
+* style/StyleTreeResolver.h:
+
2017-01-03 Carlos Alberto Lopez Perez
A floating element within overlaps with the marker
Modified: trunk/Source/WebCore/style/StyleTreeResolver.cpp (210239 => 210240)
--- trunk/Source/WebCore/style/StyleTreeResolver.cpp 2017-01-03 15:02:26 UTC (rev 210239)
+++ trunk/Source/WebCore/style/StyleTreeResolver.cpp 2017-01-03 18:53:04 UTC (rev 210240)
@@ -51,13 +51,9 @@
namespace Style {
-static RenderStyle* placeholderStyle;
-
-static void ensurePlaceholderStyle(Document& document)
+static std::unique_ptr makePlaceholderStyle(Document& document)
{
-if (placeholderStyle)
-return;
-placeholderStyle = RenderStyle::createPtr().release();
+auto placeholderStyle = RenderStyle::createPtr();
placeholderStyle->setDisplay(NONE);
placeholderStyle->setIsPlaceholderStyle();
@@ -70,12 +66,12 @@
placeholderStyle->setFontDescription(fontDescription);
placeholderStyle->fontCascade().update(());
+return placeholderStyle;
}
TreeResolver::TreeResolver(Document& document)
: m_document(document)
{
-ensurePlaceholderStyle(document);
}
TreeResolver::~TreeResolver()
@@ -133,7 +129,7 @@
{
if (!m_document.haveStylesheetsLoaded() && !element.renderer()) {
m_document.setHasNodesWithPlaceholderStyle();
-return RenderStyle::clonePtr(*placeholderStyle);
+return makePlaceholderStyle(m_document);
}
if (element.hasCustomStyleResolveCallbacks()) {
@@ -550,10 +546,5 @@
return resolutionNestingDepth;
}
-bool isPlaceholderStyle(const RenderStyle& style)
-{
-return == placeholderStyle;
}
-
}
-}
Modified: trunk/Source/WebCore/style/StyleTreeResolver.h (210239 => 210240)
--- trunk/Source/WebCore/style/StyleTreeResolver.h 2017-01-03 15:02:26 UTC (rev 210239)
+++ trunk/Source/WebCore/style/StyleTreeResolver.h 2017-01-03 18:53:04 UTC (rev 210240)
@@ -109,8 +109,6 @@
void queuePostResolutionCallback(Function&&);
bool postResolutionCallbacksAreSuspended();
-bool isPlaceholderStyle(const RenderStyle&);
-
class PostResolutionCallbackDisabler {
public:
explicit PostResolutionCallbackDisabler(Document&);
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [210226] trunk/Source/WebCore
Revision 210226
Author akl...@apple.com
Date 2017-01-02 13:16:09 -0800 (Mon, 02 Jan 2017)
Log Message
Drop the render tree for documents in the page cache.
Reviewed by Antti Koivisto.
To save memory and reduce complexity, have documents tear down their render tree
when entering the page cache. I've wanted to do this for a long time and it seems
like we can actually do it now.
This patch will enable a number of clean-ups since it's no longer valid for renderers
to exist while the document is in page cache.
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree): Remove assertion that we're not in the page cache
since we will now be tearing down render trees right as they enter the page cache.
* dom/PageCache.cpp:
(WebCore::destroyRenderTree):
(WebCore::PageCache::addIfCacheable): Tear down the render tree right before setting
the in-cache flag. The render tree is destroyed in bottom-up order to ensure that the
main frame renderers die last.
* history/CachedFrame.cpp:
(WebCore::CachedFrameBase::restore):
* page/FrameView.h:
* page/FrameView.cpp:
(WebCore::FrameView::didRestoreFromPageCache): Update the scollable area set after restoring
a frame from the page cache. This dirties the scrolling tree, which was covered by tests.
* page/animation/AnimationBase.cpp:
(WebCore::AnimationBase::setNeedsStyleRecalc):
* page/animation/AnimationController.cpp:
(WebCore::AnimationController::cancelAnimations): Make these no-ops if called
while the render tree is being torn down. This fixes some assertion failures
on layout tests and avoids pointless style invalidation.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
trunk/Source/WebCore/history/CachedFrame.cpp
trunk/Source/WebCore/history/PageCache.cpp
trunk/Source/WebCore/page/FrameView.cpp
trunk/Source/WebCore/page/FrameView.h
trunk/Source/WebCore/page/animation/AnimationBase.cpp
trunk/Source/WebCore/page/animation/AnimationController.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (210225 => 210226)
--- trunk/Source/WebCore/ChangeLog 2017-01-02 16:41:11 UTC (rev 210225)
+++ trunk/Source/WebCore/ChangeLog 2017-01-02 21:16:09 UTC (rev 210226)
@@ -1,5 +1,43 @@
2017-01-02 Andreas Kling
+Drop the render tree for documents in the page cache.
+
+
+Reviewed by Antti Koivisto.
+
+To save memory and reduce complexity, have documents tear down their render tree
+when entering the page cache. I've wanted to do this for a long time and it seems
+like we can actually do it now.
+
+This patch will enable a number of clean-ups since it's no longer valid for renderers
+to exist while the document is in page cache.
+
+* dom/Document.cpp:
+(WebCore::Document::destroyRenderTree): Remove assertion that we're not in the page cache
+since we will now be tearing down render trees right as they enter the page cache.
+
+* dom/PageCache.cpp:
+(WebCore::destroyRenderTree):
+(WebCore::PageCache::addIfCacheable): Tear down the render tree right before setting
+the in-cache flag. The render tree is destroyed in bottom-up order to ensure that the
+main frame renderers die last.
+
+* history/CachedFrame.cpp:
+(WebCore::CachedFrameBase::restore):
+* page/FrameView.h:
+* page/FrameView.cpp:
+(WebCore::FrameView::didRestoreFromPageCache): Update the scollable area set after restoring
+a frame from the page cache. This dirties the scrolling tree, which was covered by tests.
+
+* page/animation/AnimationBase.cpp:
+(WebCore::AnimationBase::setNeedsStyleRecalc):
+* page/animation/AnimationController.cpp:
+(WebCore::AnimationController::cancelAnimations): Make these no-ops if called
+while the render tree is being torn down. This fixes some assertion failures
+on layout tests and avoids pointless style invalidation.
+
+2017-01-02 Andreas Kling
+
Discard media controls JS/CSS caches under memory pressure.
Modified: trunk/Source/WebCore/dom/Document.cpp (210225 => 210226)
--- trunk/Source/WebCore/dom/Document.cpp 2017-01-02 16:41:11 UTC (rev 210225)
+++ trunk/Source/WebCore/dom/Document.cpp 2017-01-02 21:16:09 UTC (rev 210226)
@@ -2202,7 +2202,6 @@
void Document::destroyRenderTree()
{
ASSERT(hasLivingRenderTree());
-ASSERT(m_pageCacheState != InPageCache);
SetForScope change(m_renderTreeBeingDestroyed, true);
Modified: trunk/Source/WebCore/history/CachedFrame.cpp (210225 => 210226)
--- trunk/Source/WebCore/history/CachedFrame.cpp 2017-01-02 16:41:11 UTC (rev 210225)
+++ trunk/Source/WebCore/history/CachedFrame.cpp 2017-01-02 21:16:09 UTC (rev 210226)
@@ -130,6 +130,7 @@
m_document->page()->chrome().client().needTouchEvents(true);
#endif
+frame.view()->didRestoreFromPageCache();
}
Title: [210224] trunk/Source
Revision 210224
Author akl...@apple.com
Date 2017-01-02 07:36:41 -0800 (Mon, 02 Jan 2017)
Log Message
Discard media controls JS/CSS caches under memory pressure.
Reviewed by Antti Koivisto.
Source/WebCore:
Add a RenderTheme::purgeCaches() virtual and teach the iOS and macOS implementations
to drop their cached media controls JS/CSS strings there. The strings are only cleared
if nothing else is referencing them, which gives us a decent "weak cache" behavior.
This sheds ~300kB memory on iOS with the current media controls.
* page/MemoryRelease.cpp:
(WebCore::releaseNoncriticalMemory):
* rendering/RenderTheme.h:
(WebCore::RenderTheme::purgeCaches):
* rendering/RenderThemeIOS.h:
* rendering/RenderThemeIOS.mm:
(WebCore::RenderThemeIOS::purgeCaches):
* rendering/RenderThemeMac.h:
* rendering/RenderThemeMac.mm:
(WebCore::RenderThemeMac::purgeCaches):
Source/WTF:
* wtf/text/WTFString.h:
(WTF::String::clearImplIfNotShared): Add a helper for clearing a String if the underlying
StringImpl is not referenced by anyone else.
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/text/WTFString.h
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/MemoryRelease.cpp
trunk/Source/WebCore/rendering/RenderTheme.h
trunk/Source/WebCore/rendering/RenderThemeIOS.h
trunk/Source/WebCore/rendering/RenderThemeIOS.mm
trunk/Source/WebCore/rendering/RenderThemeMac.h
trunk/Source/WebCore/rendering/RenderThemeMac.mm
Diff
Modified: trunk/Source/WTF/ChangeLog (210223 => 210224)
--- trunk/Source/WTF/ChangeLog 2017-01-02 13:54:17 UTC (rev 210223)
+++ trunk/Source/WTF/ChangeLog 2017-01-02 15:36:41 UTC (rev 210224)
@@ -1,3 +1,14 @@
+2017-01-02 Andreas Kling
+
+Discard media controls JS/CSS caches under memory pressure.
+
+
+Reviewed by Antti Koivisto.
+
+* wtf/text/WTFString.h:
+(WTF::String::clearImplIfNotShared): Add a helper for clearing a String if the underlying
+StringImpl is not referenced by anyone else.
+
2016-12-22 Mark Lam
De-duplicate finally blocks.
Modified: trunk/Source/WTF/wtf/text/WTFString.h (210223 => 210224)
--- trunk/Source/WTF/wtf/text/WTFString.h 2017-01-02 13:54:17 UTC (rev 210223)
+++ trunk/Source/WTF/wtf/text/WTFString.h 2017-01-02 15:36:41 UTC (rev 210224)
@@ -469,6 +469,14 @@
return (*m_impl)[index];
}
+// Turns this String empty if the StringImpl is not referenced by anyone else.
+// This is useful for clearing String-based caches.
+void clearImplIfNotShared()
+{
+if (m_impl && m_impl->hasOneRef())
+m_impl = nullptr;
+}
+
private:
template
void removeInternal(const CharacterType*, unsigned, int);
Modified: trunk/Source/WebCore/ChangeLog (210223 => 210224)
--- trunk/Source/WebCore/ChangeLog 2017-01-02 13:54:17 UTC (rev 210223)
+++ trunk/Source/WebCore/ChangeLog 2017-01-02 15:36:41 UTC (rev 210224)
@@ -1,3 +1,27 @@
+2017-01-02 Andreas Kling
+
+Discard media controls JS/CSS caches under memory pressure.
+
+
+Reviewed by Antti Koivisto.
+
+Add a RenderTheme::purgeCaches() virtual and teach the iOS and macOS implementations
+to drop their cached media controls JS/CSS strings there. The strings are only cleared
+if nothing else is referencing them, which gives us a decent "weak cache" behavior.
+
+This sheds ~300kB memory on iOS with the current media controls.
+
+* page/MemoryRelease.cpp:
+(WebCore::releaseNoncriticalMemory):
+* rendering/RenderTheme.h:
+(WebCore::RenderTheme::purgeCaches):
+* rendering/RenderThemeIOS.h:
+* rendering/RenderThemeIOS.mm:
+(WebCore::RenderThemeIOS::purgeCaches):
+* rendering/RenderThemeMac.h:
+* rendering/RenderThemeMac.mm:
+(WebCore::RenderThemeMac::purgeCaches):
+
2017-01-02 Carlos Garcia Campos
[GTK] Since the memory pressure relief has been activated, my disk has a high usage and the desktop stalls
Modified: trunk/Source/WebCore/page/MemoryRelease.cpp (210223 => 210224)
--- trunk/Source/WebCore/page/MemoryRelease.cpp 2017-01-02 13:54:17 UTC (rev 210223)
+++ trunk/Source/WebCore/page/MemoryRelease.cpp 2017-01-02 15:36:41 UTC (rev 210224)
@@ -38,6 +38,7 @@
#include "MemoryCache.h"
#include "Page.h"
#include "PageCache.h"
+#include "RenderTheme.h"
#include "ScrollingThread.h"
#include "StyleScope.h"
#include "StyledElement.h"
@@ -48,6 +49,8 @@
static void releaseNoncriticalMemory()
{
+RenderTheme::defaultTheme()->purgeCaches();
+
FontCache::singleton().purgeInactiveFontData();
clearWidthCaches();
Modified: trunk/Source/WebCore/rendering/RenderTheme.h (210223 => 210224)
--- trunk/Source/WebCore/rendering/RenderTheme.h 2017-01-02 13:54:17 UTC (rev 210223)
+++ trunk/Source/WebCore/rendering/RenderTheme.h 2017-01-02 15:36:41 UTC
Title: [210206] trunk/Source/WebCore
Revision 210206
Author akl...@apple.com
Date 2016-12-30 00:54:25 -0800 (Fri, 30 Dec 2016)
Log Message
Drop the render tree for documents in the page cache.
Reviewed by Darin Adler.
To save memory and reduce complexity, have documents tear down their render tree
when entering the page cache. I've wanted to do this for a long time and it seems
like we can actually do it now.
This patch will enable a number of clean-ups since it's no longer valid for renderers
to exist while the document is in page cache.
* dom/Document.cpp:
(WebCore::Document::destroyRenderTree): Remove assertion that we're not in the page cache
since we will now be tearing down render trees right as they enter the page cache.
(WebCore::Document::setPageCacheState): Tear down the render tree right before setting
the in-cache flag. From now on, there should not exist render objects for documents in
the page cache.
* history/CachedFrame.cpp:
(WebCore::CachedFrameBase::restore):
* page/FrameView.h:
* page/FrameView.cpp:
(WebCore::FrameView::didRestoreFromPageCache): Update the scollable area set after restoring a
frame from the page cache. This dirties the scrolling tree, which was covered by tests.
* page/animation/AnimationBase.cpp:
(WebCore::AnimationBase::setNeedsStyleRecalc): Make this a no-op if the render tree is being
torn down. This fixes assertions firing on animation tests.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
trunk/Source/WebCore/history/CachedFrame.cpp
trunk/Source/WebCore/page/FrameView.cpp
trunk/Source/WebCore/page/FrameView.h
trunk/Source/WebCore/page/animation/AnimationBase.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (210205 => 210206)
--- trunk/Source/WebCore/ChangeLog 2016-12-29 18:46:31 UTC (rev 210205)
+++ trunk/Source/WebCore/ChangeLog 2016-12-30 08:54:25 UTC (rev 210206)
@@ -1,3 +1,36 @@
+2016-12-30 Andreas Kling
+
+Drop the render tree for documents in the page cache.
+
+
+Reviewed by Darin Adler.
+
+To save memory and reduce complexity, have documents tear down their render tree
+when entering the page cache. I've wanted to do this for a long time and it seems
+like we can actually do it now.
+
+This patch will enable a number of clean-ups since it's no longer valid for renderers
+to exist while the document is in page cache.
+
+* dom/Document.cpp:
+(WebCore::Document::destroyRenderTree): Remove assertion that we're not in the page cache
+since we will now be tearing down render trees right as they enter the page cache.
+
+(WebCore::Document::setPageCacheState): Tear down the render tree right before setting
+the in-cache flag. From now on, there should not exist render objects for documents in
+the page cache.
+
+* history/CachedFrame.cpp:
+(WebCore::CachedFrameBase::restore):
+* page/FrameView.h:
+* page/FrameView.cpp:
+(WebCore::FrameView::didRestoreFromPageCache): Update the scollable area set after restoring a
+frame from the page cache. This dirties the scrolling tree, which was covered by tests.
+
+* page/animation/AnimationBase.cpp:
+(WebCore::AnimationBase::setNeedsStyleRecalc): Make this a no-op if the render tree is being
+torn down. This fixes assertions firing on animation tests.
+
2016-12-29 Chris Fleizach
AX: Need to expose frames to iOS Accessibility
Modified: trunk/Source/WebCore/dom/Document.cpp (210205 => 210206)
--- trunk/Source/WebCore/dom/Document.cpp 2016-12-29 18:46:31 UTC (rev 210205)
+++ trunk/Source/WebCore/dom/Document.cpp 2016-12-30 08:54:25 UTC (rev 210206)
@@ -2221,7 +2221,6 @@
void Document::destroyRenderTree()
{
ASSERT(hasLivingRenderTree());
-ASSERT(m_pageCacheState != InPageCache);
SetForScope change(m_renderTreeBeingDestroyed, true);
@@ -4524,6 +4523,13 @@
if (m_pageCacheState == state)
return;
+if (state == InPageCache) {
+// When entering page cache, tear down the render tree before setting the in-cache flag.
+// This maintains the invariant that render trees are never present in the page cache.
+if (hasLivingRenderTree())
+destroyRenderTree();
+}
+
m_pageCacheState = state;
FrameView* v = view();
Modified: trunk/Source/WebCore/history/CachedFrame.cpp (210205 => 210206)
--- trunk/Source/WebCore/history/CachedFrame.cpp 2016-12-29 18:46:31 UTC (rev 210205)
+++ trunk/Source/WebCore/history/CachedFrame.cpp 2016-12-30 08:54:25 UTC (rev 210206)
@@ -130,6 +130,7 @@
m_document->page()->chrome().client().needTouchEvents(true);
#endif
+frame.view()->didRestoreFromPageCache();
}
CachedFrame::CachedFrame(Frame& frame)
Modified: trunk/Source/WebCore/page/FrameView.cpp (210205 => 210206)
---
Title: [209932] trunk
Revision 209932
Author akl...@apple.com
Date 2016-12-16 12:44:01 -0800 (Fri, 16 Dec 2016)
Log Message
Subframes going into page cache don't need to resetScrollbars().
Reviewed by Antti Koivisto.
Source/WebCore:
The main frame is the only frame that switches its FrameView when using the page cache,
subframes just suspend their DOM and wait around to be either killed or restored.
Thus there is no reason for subframes to reset their FrameView's scrollbars when going
into page cache, since nothing affects them while cached, and their layout should end up
identical when restoring.
This was causing some flakiness with subframe scrollbars jumping between different sizes
in when restoring from page cache in macOS/WK1. This change makes the behavior consistent
in both WK1 and WK2, and removes the flakiness.
* dom/Document.cpp:
(WebCore::Document::setPageCacheState):
LayoutTests:
Unskip compositing/iframes/page-cache-layer-tree.html on mac-wk1 and fix up the
result now that WK2 behaves correctly as well.
Both DRT and WTR run with scrollbars in "always on" mode, so the correct dimensions
for the 300x150 iframe layers here are 285x135.
* compositing/iframes/page-cache-layer-tree-expected.txt:
* platform/mac-wk1/TestExpectations:
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt
trunk/LayoutTests/platform/mac-wk1/TestExpectations
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
Diff
Modified: trunk/LayoutTests/ChangeLog (209931 => 209932)
--- trunk/LayoutTests/ChangeLog 2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/LayoutTests/ChangeLog 2016-12-16 20:44:01 UTC (rev 209932)
@@ -1,3 +1,20 @@
+2016-12-16 Andreas Kling
+
+Subframes going into page cache don't need to resetScrollbars().
+
+
+
+Reviewed by Antti Koivisto.
+
+Unskip compositing/iframes/page-cache-layer-tree.html on mac-wk1 and fix up the
+result now that WK2 behaves correctly as well.
+
+Both DRT and WTR run with scrollbars in "always on" mode, so the correct dimensions
+for the 300x150 iframe layers here are 285x135.
+
+* compositing/iframes/page-cache-layer-tree-expected.txt:
+* platform/mac-wk1/TestExpectations:
+
2016-12-16 Wenson Hsieh
Visual viewports: carets and selection UI are incorrectly positioned when editing fixed elements
Modified: trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt (209931 => 209932)
--- trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt 2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt 2016-12-16 20:44:01 UTC (rev 209932)
@@ -23,7 +23,7 @@
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
- (bounds 285.00 150.00)
+ (bounds 285.00 135.00)
(children 1
(GraphicsLayer
(children 1
@@ -73,7 +73,7 @@
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
- (bounds 285.00 150.00)
+ (bounds 285.00 135.00)
(children 1
(GraphicsLayer
(children 1
Modified: trunk/LayoutTests/platform/mac-wk1/TestExpectations (209931 => 209932)
--- trunk/LayoutTests/platform/mac-wk1/TestExpectations 2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/LayoutTests/platform/mac-wk1/TestExpectations 2016-12-16 20:44:01 UTC (rev 209932)
@@ -285,8 +285,6 @@
webkit.org/b/163361 imported/w3c/web-platform-tests/html/webappapis/animation-frames/callback-invoked.html [ Pass Failure ]
webkit.org/b/163361 imported/w3c/web-platform-tests/html/webappapis/animation-frames/callback-multicalls.html [ Pass Failure ]
-webkit.org/b/163750 compositing/iframes/page-cache-layer-tree.html [ Pass Failure ]
-
webkit.org/b/164491 [ Yosemite ElCapitan ] fast/visual-viewport/rtl-zoomed-rects.html [ Failure ]
webkit.org/b/164933 http/tests/misc/link-rel-icon-beforeload.html [ Failure ]
Modified: trunk/Source/WebCore/ChangeLog (209931 => 209932)
--- trunk/Source/WebCore/ChangeLog 2016-12-16 20:24:37 UTC (rev 209931)
+++ trunk/Source/WebCore/ChangeLog 2016-12-16 20:44:01 UTC (rev 209932)
@@ -1,3 +1,25 @@
+2016-12-16 Andreas Kling
+
+Subframes going into page cache don't need to resetScrollbars().
+
+
+
+Reviewed by Antti Koivisto.
+
+The main frame is the only frame that switches its FrameView when using the page cache,
+subframes just suspend their DOM and wait around to be either killed or restored.
+
+Thus there is no reason for subframes to reset their FrameView's scrollbars when going
+into page
Title: [209851] trunk/Source/WebKit2
Revision 209851
Author akl...@apple.com
Date 2016-12-14 19:48:49 -0800 (Wed, 14 Dec 2016)
Log Message
Only send Messages::WebPageProxy::DidSaveToPageCache once when entering page cache.
Reviewed by Brady Eidson.
We were sending one of these IPC messages per frame when a page enters the page cache,
and we really only need one, so only do it for the main frame.
(This message is used to adopt the page cache on the UI process side, in case another
web process currently owns the cache. That happens in WebProcessPool::processDidCachePage().)
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::didSaveToPageCache):
Modified Paths
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
Diff
Modified: trunk/Source/WebKit2/ChangeLog (209850 => 209851)
--- trunk/Source/WebKit2/ChangeLog 2016-12-15 03:30:44 UTC (rev 209850)
+++ trunk/Source/WebKit2/ChangeLog 2016-12-15 03:48:49 UTC (rev 209851)
@@ -1,3 +1,19 @@
+2016-12-14 Andreas Kling
+
+Only send Messages::WebPageProxy::DidSaveToPageCache once when entering page cache.
+
+
+Reviewed by Brady Eidson.
+
+We were sending one of these IPC messages per frame when a page enters the page cache,
+and we really only need one, so only do it for the main frame.
+
+(This message is used to adopt the page cache on the UI process side, in case another
+web process currently owns the cache. That happens in WebProcessPool::processDidCachePage().)
+
+* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
+(WebKit::WebFrameLoaderClient::didSaveToPageCache):
+
2016-12-14 Simon Fraser
Fix cause of viewport-related flakiness in iOS tests
Modified: trunk/Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp (209850 => 209851)
--- trunk/Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp 2016-12-15 03:30:44 UTC (rev 209850)
+++ trunk/Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp 2016-12-15 03:48:49 UTC (rev 209851)
@@ -1370,7 +1370,8 @@
if (!webPage)
return;
-webPage->send(Messages::WebPageProxy::DidSaveToPageCache());
+if (m_frame->isMainFrame())
+webPage->send(Messages::WebPageProxy::DidSaveToPageCache());
}
void WebFrameLoaderClient::didRestoreFromPageCache()
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [209456] trunk/Source/WebCore
Revision 209456
Author akl...@apple.com
Date 2016-12-07 08:27:34 -0800 (Wed, 07 Dec 2016)
Log Message
[iOS] Remove bitrotted FrameLoader attempt to limit page caching under memory pressure.
Reviewed by Antti Koivisto.
This code no longer does anything, as the page cache is hard capped
at 0 entries while under memory pressure.
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::commitProvisionalLoad):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/loader/FrameLoader.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (209455 => 209456)
--- trunk/Source/WebCore/ChangeLog 2016-12-07 15:32:27 UTC (rev 209455)
+++ trunk/Source/WebCore/ChangeLog 2016-12-07 16:27:34 UTC (rev 209456)
@@ -1,3 +1,16 @@
+2016-12-07 Andreas Kling
+
+[iOS] Remove bitrotted FrameLoader attempt to limit page caching under memory pressure.
+
+
+Reviewed by Antti Koivisto.
+
+This code no longer does anything, as the page cache is hard capped
+at 0 entries while under memory pressure.
+
+* loader/FrameLoader.cpp:
+(WebCore::FrameLoader::commitProvisionalLoad):
+
2016-12-06 Antoine Quint
[Modern Media Controls] Use tap and pinch gestures on iOS
Modified: trunk/Source/WebCore/loader/FrameLoader.cpp (209455 => 209456)
--- trunk/Source/WebCore/loader/FrameLoader.cpp 2016-12-07 15:32:27 UTC (rev 209455)
+++ trunk/Source/WebCore/loader/FrameLoader.cpp 2016-12-07 16:27:34 UTC (rev 209456)
@@ -136,7 +136,6 @@
#include "DocumentType.h"
#include "ResourceLoader.h"
#include "RuntimeApplicationChecks.h"
-#include "SystemMemory.h"
#include "WKContentObservation.h"
#endif
@@ -149,10 +148,6 @@
static const char defaultAcceptHeader[] = "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8";
-#if PLATFORM(IOS)
-const int memoryLevelThresholdToPrunePageCache = 20;
-#endif
-
bool isBackForwardLoadType(FrameLoadType type)
{
switch (type) {
@@ -1766,27 +1761,6 @@
m_frame.document() ? m_frame.document()->url().stringCenterEllipsizedToLength().utf8().data() : "",
pdl ? pdl->url().stringCenterEllipsizedToLength().utf8().data() : "");
-#if PLATFORM(IOS)
-// In the case where we are not navigating to a cached page, and the system is under (speculative) memory pressure,
-// we can try to preemptively release some of the pages in the cache.
-// FIXME: Right now the capacity is 1 on iOS devices with 256 MB of RAM, so this will always blow away the whole
-// page cache. We could still preemptively prune the page cache while navigating to a cached page if capacity > 1.
-// See for more details.
-if (!cachedPage) {
-if (MemoryPressureHandler::singleton().isUnderMemoryPressure()) {
-LOG(MemoryPressure, "Pruning page cache because under memory pressure at: %s", __PRETTY_FUNCTION__);
-LOG(PageCache, "Pruning page cache to 0 due to memory pressure");
-// Don't cache any page if we are under memory pressure.
-PageCache::singleton().pruneToSizeNow(0, PruningReason::MemoryPressure);
-} else if (systemMemoryLevel() <= memoryLevelThresholdToPrunePageCache) {
-LOG(MemoryPressure, "Pruning page cache because system memory level is %d at: %s", systemMemoryLevel(), __PRETTY_FUNCTION__);
-auto& pageCache = PageCache::singleton();
-LOG(PageCache, "Pruning page cache to %d due to low memory (level %d less or equal to %d threshold)", pageCache.maxSize() / 2, systemMemoryLevel(), memoryLevelThresholdToPrunePageCache);
-pageCache.pruneToSizeNow(pageCache.maxSize() / 2, PruningReason::MemoryPressure);
-}
-}
-#endif
-
willTransitionToCommitted();
if (!m_frame.tree().parent() && history().currentItem()) {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [209346] trunk/Source
Revision 209346
Author akl...@apple.com
Date 2016-12-05 13:31:23 -0800 (Mon, 05 Dec 2016)
Log Message
[Cocoa] Add some memory usage related information to sysdiagnose state dumps
Reviewed by Darin Adler.
Source/WebCore:
Add a flag to memoryUsageStatistics() to allow gathering of slightly more expensive information.
This mode is used when capturing a state dump for sysdiagnose.
The more expensive information added in this patch relates to information about live objects
and memory on the _javascript_ heap.
* WebCore.xcodeproj/project.pbxproj:
* page/PerformanceLogging.cpp:
(WebCore::PerformanceLogging::memoryUsageStatistics):
(WebCore::PerformanceLogging::_javascript_ObjectCounts):
(WebCore::PerformanceLogging::didReachPointOfInterest):
* page/PerformanceLogging.h:
Source/WebKit2:
Add two new entries to the sysdiagnose state dumps for WebContent processes:
"Memory Usage Stats" and "_javascript_ Object Counts".
The first category contains all the interesting stuff from task_info()
along with some WebCore and _javascript_Core object/memory counters.
The second category contains a list of all the JS object types currently live
on the heap, along with a count.
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::registerWithStateDumper): Add two new entries to the
state dictionary: "Memory Usage Stats" and "_javascript_ Object Counts".
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj
trunk/Source/WebCore/page/PerformanceLogging.cpp
trunk/Source/WebCore/page/PerformanceLogging.h
trunk/Source/WebCore/page/cocoa/PerformanceLoggingCocoa.mm
trunk/Source/WebKit2/ChangeLog
trunk/Source/WebKit2/WebProcess/cocoa/WebProcessCocoa.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (209345 => 209346)
--- trunk/Source/WebCore/ChangeLog 2016-12-05 21:04:29 UTC (rev 209345)
+++ trunk/Source/WebCore/ChangeLog 2016-12-05 21:31:23 UTC (rev 209346)
@@ -1,3 +1,24 @@
+2016-12-05 Andreas Kling
+
+[Cocoa] Add some memory usage related information to sysdiagnose state dumps
+
+
+
+Reviewed by Darin Adler.
+
+Add a flag to memoryUsageStatistics() to allow gathering of slightly more expensive information.
+This mode is used when capturing a state dump for sysdiagnose.
+
+The more expensive information added in this patch relates to information about live objects
+and memory on the _javascript_ heap.
+
+* WebCore.xcodeproj/project.pbxproj:
+* page/PerformanceLogging.cpp:
+(WebCore::PerformanceLogging::memoryUsageStatistics):
+(WebCore::PerformanceLogging::_javascript_ObjectCounts):
+(WebCore::PerformanceLogging::didReachPointOfInterest):
+* page/PerformanceLogging.h:
+
2016-12-05 Dave Hyatt
[CSS Parser] Make sure the transform fast path uses WebKitCSSTransformValue
Modified: trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj (209345 => 209346)
--- trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj 2016-12-05 21:04:29 UTC (rev 209345)
+++ trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj 2016-12-05 21:31:23 UTC (rev 209346)
@@ -4517,7 +4517,7 @@
AD49914318F0815100BF0092 /* HTMLUnknownElement.h in Headers */ = {isa = PBXBuildFile; fileRef = AD49914118F0815100BF0092 /* HTMLUnknownElement.h */; settings = {ATTRIBUTES = (Private, ); }; };
AD5A0C231DECACC000707054 /* PerformanceLoggingCocoa.mm in Sources */ = {isa = PBXBuildFile; fileRef = AD5A0C221DECA37E00707054 /* PerformanceLoggingCocoa.mm */; };
AD5A0C241DECACC400707054 /* PerformanceLogging.cpp in Sources */ = {isa = PBXBuildFile; fileRef = AD5A0C211DECA10100707054 /* PerformanceLogging.cpp */; };
- AD5A0C251DECACCC00707054 /* PerformanceLogging.h in Headers */ = {isa = PBXBuildFile; fileRef = AD5A0C201DECA0B500707054 /* PerformanceLogging.h */; };
+ AD5A0C251DECACCC00707054 /* PerformanceLogging.h in Headers */ = {isa = PBXBuildFile; fileRef = AD5A0C201DECA0B500707054 /* PerformanceLogging.h */; settings = {ATTRIBUTES = (Private, ); }; };
AD6E71AC1668899D00320C13 /* DocumentSharedObjectPool.cpp in Sources */ = {isa = PBXBuildFile; fileRef = AD6E71AA1668899D00320C13 /* DocumentSharedObjectPool.cpp */; };
AD6E71AD1668899D00320C13 /* DocumentSharedObjectPool.h in Headers */ = {isa = PBXBuildFile; fileRef = AD6E71AB1668899D00320C13 /* DocumentSharedObjectPool.h */; };
AD726FED16DA1171003A4E6D /* JSCSSStyleDeclarationCustom.h in Headers */ = {isa = PBXBuildFile; fileRef = AD726FEA16D9F40B003A4E6D /* JSCSSStyleDeclarationCustom.h */; settings = {ATTRIBUTES = (Private, ); }; };
Modified: trunk/Source/WebCore/page/PerformanceLogging.cpp (209345 => 209346)
--- trunk/Source/WebCore/page/PerformanceLogging.cpp 2016-12-05 21:04:29 UTC (rev 209345)
+++ trunk/Source/WebCore/page/PerformanceLogging.cpp 2016-12-05 21:31:23 UTC (rev 209346)
@@ -46,19 +46,37 @@
return
Title: [209181] trunk/Source/WebCore
Revision 209181
Author akl...@apple.com
Date 2016-12-01 08:15:27 -0800 (Thu, 01 Dec 2016)
Log Message
Log some basic memory usage stats at interesting points in time
Reviewed by Antti Koivisto.
This patch adds a mechanism to mark points of interests where we might
want to do performance-related logging:
class PerformanceLogging {
enum PointOfInterest {
MainFrameLoadStarted,
MainFrameLoadCompleted,
}
void didReachPointOfInterest(PointOfInterest)
}
You get to this object via MainFrame::performanceLogging().
We respond to these callbacks by logging some basic data about memory usage
to the PerformanceLogging channel.
More PointOfInterest values will be added soon.
* CMakeLists.txt:
* WebCore.xcodeproj/project.pbxproj:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadWithDocumentLoader):
(WebCore::FrameLoader::setState):
* page/MainFrame.cpp:
(WebCore::MainFrame::MainFrame):
* page/MainFrame.h:
* page/PerformanceLogging.cpp: Added.
(WebCore::toString):
(WebCore::getMemoryUsageStatistics):
(WebCore::PerformanceLogging::PerformanceLogging):
(WebCore::writeLog):
(WebCore::PerformanceLogging::didReachPointOfInterest):
(WebCore::PerformanceLogging::getPlatformMemoryUsageStatistics):
* page/PerformanceLogging.h: Added.
* page/cocoa/PerformanceLoggingCocoa.mm: Added.
(WebCore::PerformanceLogging::getPlatformMemoryUsageStatistics):
* platform/Logging.h:
Modified Paths
trunk/Source/WebCore/CMakeLists.txt
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj
trunk/Source/WebCore/loader/FrameLoader.cpp
trunk/Source/WebCore/page/MainFrame.cpp
trunk/Source/WebCore/page/MainFrame.h
trunk/Source/WebCore/platform/Logging.h
Added Paths
trunk/Source/WebCore/page/PerformanceLogging.cpp
trunk/Source/WebCore/page/PerformanceLogging.h
trunk/Source/WebCore/page/cocoa/PerformanceLoggingCocoa.mm
Diff
Modified: trunk/Source/WebCore/CMakeLists.txt (209180 => 209181)
--- trunk/Source/WebCore/CMakeLists.txt 2016-12-01 11:05:22 UTC (rev 209180)
+++ trunk/Source/WebCore/CMakeLists.txt 2016-12-01 16:15:27 UTC (rev 209181)
@@ -2067,6 +2067,7 @@
page/PageVisibilityState.cpp
page/Performance.cpp
page/PerformanceEntry.cpp
+page/PerformanceLogging.cpp
page/PerformanceNavigation.cpp
page/PerformanceResourceTiming.cpp
page/PerformanceTiming.cpp
Modified: trunk/Source/WebCore/ChangeLog (209180 => 209181)
--- trunk/Source/WebCore/ChangeLog 2016-12-01 11:05:22 UTC (rev 209180)
+++ trunk/Source/WebCore/ChangeLog 2016-12-01 16:15:27 UTC (rev 209181)
@@ -1,3 +1,48 @@
+2016-12-01 Andreas Kling
+
+Log some basic memory usage stats at interesting points in time
+
+
+Reviewed by Antti Koivisto.
+
+This patch adds a mechanism to mark points of interests where we might
+want to do performance-related logging:
+
+class PerformanceLogging {
+enum PointOfInterest {
+MainFrameLoadStarted,
+MainFrameLoadCompleted,
+}
+void didReachPointOfInterest(PointOfInterest)
+}
+
+You get to this object via MainFrame::performanceLogging().
+
+We respond to these callbacks by logging some basic data about memory usage
+to the PerformanceLogging channel.
+
+More PointOfInterest values will be added soon.
+
+* CMakeLists.txt:
+* WebCore.xcodeproj/project.pbxproj:
+* loader/FrameLoader.cpp:
+(WebCore::FrameLoader::loadWithDocumentLoader):
+(WebCore::FrameLoader::setState):
+* page/MainFrame.cpp:
+(WebCore::MainFrame::MainFrame):
+* page/MainFrame.h:
+* page/PerformanceLogging.cpp: Added.
+(WebCore::toString):
+(WebCore::getMemoryUsageStatistics):
+(WebCore::PerformanceLogging::PerformanceLogging):
+(WebCore::writeLog):
+(WebCore::PerformanceLogging::didReachPointOfInterest):
+(WebCore::PerformanceLogging::getPlatformMemoryUsageStatistics):
+* page/PerformanceLogging.h: Added.
+* page/cocoa/PerformanceLoggingCocoa.mm: Added.
+(WebCore::PerformanceLogging::getPlatformMemoryUsageStatistics):
+* platform/Logging.h:
+
2016-11-28 Sergio Villar Senin
[css-grid] Move more attributes from RenderGrid to the new Grid class
Modified: trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj (209180 => 209181)
--- trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj 2016-12-01 11:05:22 UTC (rev 209180)
+++ trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj 2016-12-01 16:15:27 UTC (rev 209181)
@@ -4511,6 +4511,9 @@
AD4495F3141FC08900541EDF /* EventListenerMap.cpp in Sources */ = {isa = PBXBuildFile; fileRef = AD4495F1141FC08900541EDF /* EventListenerMap.cpp */; };
AD4495F4141FC08900541EDF /*
Title: [208975] trunk/Source/WebCore
Revision 208975
Author akl...@apple.com
Date 2016-11-25 06:59:07 -0800 (Fri, 25 Nov 2016)
Log Message
MemoryPressureHandler should only trigger synchronous GC on iOS
Reviewed by Sam Weinig.
On iOS we know that there is really only one web process in play at a time,
so it's okay to do a synchronous GC immediately in response to high memory pressure.
On other platforms, we may have tens or hundreds of web processes, and if they
all start doing full GCs at the same time, it can easily bring a system to its knees
if it's already under pressure.
Fix this by using garbageCollectSoon() on non-iOS platforms.
* page/MemoryRelease.cpp:
(WebCore::releaseCriticalMemory):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/MemoryRelease.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (208974 => 208975)
--- trunk/Source/WebCore/ChangeLog 2016-11-24 20:10:25 UTC (rev 208974)
+++ trunk/Source/WebCore/ChangeLog 2016-11-25 14:59:07 UTC (rev 208975)
@@ -1,3 +1,23 @@
+2016-11-25 Andreas Kling
+
+MemoryPressureHandler should only trigger synchronous GC on iOS
+
+
+
+Reviewed by Sam Weinig.
+
+On iOS we know that there is really only one web process in play at a time,
+so it's okay to do a synchronous GC immediately in response to high memory pressure.
+
+On other platforms, we may have tens or hundreds of web processes, and if they
+all start doing full GCs at the same time, it can easily bring a system to its knees
+if it's already under pressure.
+
+Fix this by using garbageCollectSoon() on non-iOS platforms.
+
+* page/MemoryRelease.cpp:
+(WebCore::releaseCriticalMemory):
+
2016-11-23 Sergio Villar Senin
[css-grid] Convert grid representation into a class
Modified: trunk/Source/WebCore/page/MemoryRelease.cpp (208974 => 208975)
--- trunk/Source/WebCore/page/MemoryRelease.cpp 2016-11-24 20:10:25 UTC (rev 208974)
+++ trunk/Source/WebCore/page/MemoryRelease.cpp 2016-11-25 14:59:07 UTC (rev 208975)
@@ -125,8 +125,13 @@
if (synchronous == Synchronous::Yes) {
MemoryPressureHandler::ReliefLogger log("Collecting _javascript_ garbage");
GCController::singleton().garbageCollectNow();
-} else
+} else {
+#if PLATFORM(IOS)
GCController::singleton().garbageCollectNowIfNotDoneRecently();
+#else
+GCController::singleton().garbageCollectSoon();
+#endif
+}
// We reduce tiling coverage while under memory pressure, so make sure to drop excess tiles ASAP.
Page::forEachPage([](Page& page) {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [208317] trunk/Source/_javascript_Core
Revision 208317
Author akl...@apple.com
Date 2016-11-02 17:44:42 -0700 (Wed, 02 Nov 2016)
Log Message
MarkedSpace should have specialized size classes for popular engine objects.
Reviewed by Filip Pizlo.
The MarkedSpace size classes were recently reworked to minimize wasted space
at the end of MarkedBlocks.
However, we know that some specific objects will be allocated in very high volume.
Adding specialized size classes for those object sizes achieves greater utilization
since we're basically guaranteed to allocate them all the time.
Inject specialized size classes for these four objects:
- FunctionCodeBlock
560 bytes instead of 624
28 per block instead of 26 (+2)
- FunctionExecutable
176 bytes instead of 224
92 per block instead of 72 (+20)
- UnlinkedFunctionCodeBlock
256 bytes instead of 320
63 per block instead of 50 (+13)
- UnlinkedFunctionExecutable
192 bytes instead of 224
84 per block instead of 72 (+12)
* heap/MarkedSpace.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/MarkedSpace.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (208316 => 208317)
--- trunk/Source/_javascript_Core/ChangeLog 2016-11-03 00:37:19 UTC (rev 208316)
+++ trunk/Source/_javascript_Core/ChangeLog 2016-11-03 00:44:42 UTC (rev 208317)
@@ -1,3 +1,37 @@
+2016-11-02 Andreas Kling
+
+MarkedSpace should have specialized size classes for popular engine objects.
+
+
+Reviewed by Filip Pizlo.
+
+The MarkedSpace size classes were recently reworked to minimize wasted space
+at the end of MarkedBlocks.
+
+However, we know that some specific objects will be allocated in very high volume.
+Adding specialized size classes for those object sizes achieves greater utilization
+since we're basically guaranteed to allocate them all the time.
+
+Inject specialized size classes for these four objects:
+
+- FunctionCodeBlock
+560 bytes instead of 624
+28 per block instead of 26 (+2)
+
+- FunctionExecutable
+176 bytes instead of 224
+92 per block instead of 72 (+20)
+
+- UnlinkedFunctionCodeBlock
+256 bytes instead of 320
+63 per block instead of 50 (+13)
+
+- UnlinkedFunctionExecutable
+192 bytes instead of 224
+84 per block instead of 72 (+12)
+
+* heap/MarkedSpace.cpp:
+
2016-11-02 Geoffrey Garen
One file per class for UnlinkedCodeBlock.h/.cpp
Modified: trunk/Source/_javascript_Core/heap/MarkedSpace.cpp (208316 => 208317)
--- trunk/Source/_javascript_Core/heap/MarkedSpace.cpp 2016-11-03 00:37:19 UTC (rev 208316)
+++ trunk/Source/_javascript_Core/heap/MarkedSpace.cpp 2016-11-03 00:44:42 UTC (rev 208317)
@@ -21,6 +21,7 @@
#include "config.h"
#include "MarkedSpace.h"
+#include "FunctionCodeBlock.h"
#include "IncrementalSweeper.h"
#include "JSObject.h"
#include "JSCInlines.h"
@@ -43,6 +44,7 @@
result = new Vector();
auto add = [&] (size_t sizeClass) {
+sizeClass = WTF::roundUpToMultipleOf(sizeClass);
if (Options::dumpSizeClasses())
dataLog("Adding JSC MarkedSpace size class: ", sizeClass, "\n");
// Perform some validation as we go.
@@ -49,8 +51,6 @@
RELEASE_ASSERT(!(sizeClass % MarkedSpace::sizeStep));
if (result->isEmpty())
RELEASE_ASSERT(sizeClass == MarkedSpace::sizeStep);
-else
-RELEASE_ASSERT(sizeClass > result->last());
result->append(sizeClass);
};
@@ -129,7 +129,19 @@
add(betterSizeClass);
}
-
+
+add(sizeof(UnlinkedFunctionExecutable));
+add(sizeof(UnlinkedFunctionCodeBlock));
+add(sizeof(FunctionExecutable));
+add(sizeof(FunctionCodeBlock));
+
+{
+// Sort and deduplicate.
+std::sort(result->begin(), result->end());
+auto it = std::unique(result->begin(), result->end());
+result->shrinkCapacity(it - result->begin());
+}
+
if (Options::dumpSizeClasses())
dataLog("JSC Heap MarkedSpace size class dump: ", listDump(*result), "\n");
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [207620] trunk
Revision 207620
Author akl...@apple.com
Date 2016-10-20 09:38:50 -0700 (Thu, 20 Oct 2016)
Log Message
Drop StyleResolver and SelectorQueryCache when entering PageCache.
Reviewed by Antti Koivisto.
Source/WebCore:
Stop keeping these around for cached pages to save lots of memory.
We can easily rebuild them if a cached navigation occurs, and this
way we also don't need to worry about invalidating style for cached
pages in all the right places.
Restoring a cached page will now lead to a forced style recalc.
We don't try to defer this (beyond a zero-timer) since it's going
to happen anyway, and it's nicer to front-load the cost rather than
stuttering on the first user content interaction.
* dom/Document.cpp:
(WebCore::Document::setPageCacheState):
* history/CachedPage.cpp:
(WebCore::CachedPage::restore):
(WebCore::CachedPage::clear):
* history/CachedPage.h:
(WebCore::CachedPage::markForVisitedLinkStyleRecalc): Deleted.
(WebCore::CachedPage::markForFullStyleRecalc): Deleted.
* history/PageCache.cpp:
(WebCore::PageCache::markPagesForVisitedLinkStyleRecalc): Deleted.
(WebCore::PageCache::markPagesForFullStyleRecalc): Deleted.
* history/PageCache.h:
* page/Frame.cpp:
(WebCore::Frame::setPageAndTextZoomFactors):
* page/Page.cpp:
(WebCore::Page::setViewScaleFactor):
(WebCore::Page::setDeviceScaleFactor):
(WebCore::Page::setPagination):
(WebCore::Page::setPaginationLineGridEnabled):
(WebCore::Page::setVisitedLinkStore):
LayoutTests:
Progression in compositing/iframes/page-cache-layer-tree.html, when navigating back,
the two iframes' dimensions correctly exclude the horizontal scrollbar's height since
it's not present after a style recalc.
* compositing/iframes/page-cache-layer-tree-expected.txt:
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
trunk/Source/WebCore/history/CachedPage.cpp
trunk/Source/WebCore/history/CachedPage.h
trunk/Source/WebCore/history/PageCache.cpp
trunk/Source/WebCore/history/PageCache.h
trunk/Source/WebCore/page/Frame.cpp
trunk/Source/WebCore/page/Page.cpp
trunk/Source/WebKit/mac/WebCoreSupport/WebVisitedLinkStore.mm
trunk/Source/WebKit/win/WebCoreSupport/WebVisitedLinkStore.cpp
trunk/Source/WebKit2/WebProcess/WebPage/VisitedLinkTableController.cpp
Diff
Modified: trunk/LayoutTests/ChangeLog (207619 => 207620)
--- trunk/LayoutTests/ChangeLog 2016-10-20 15:57:25 UTC (rev 207619)
+++ trunk/LayoutTests/ChangeLog 2016-10-20 16:38:50 UTC (rev 207620)
@@ -1,3 +1,16 @@
+2016-10-20 Andreas Kling
+
+Drop StyleResolver and SelectorQueryCache when entering PageCache.
+
+
+Reviewed by Antti Koivisto.
+
+Progression in compositing/iframes/page-cache-layer-tree.html, when navigating back,
+the two iframes' dimensions correctly exclude the horizontal scrollbar's height since
+it's not present after a style recalc.
+
+* compositing/iframes/page-cache-layer-tree-expected.txt:
+
2016-10-20 Nael Ouedraogo
WebRTC: The MediaStreamTrackEvent init dictionary needs a required track member
Modified: trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt (207619 => 207620)
--- trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt 2016-10-20 15:57:25 UTC (rev 207619)
+++ trunk/LayoutTests/compositing/iframes/page-cache-layer-tree-expected.txt 2016-10-20 16:38:50 UTC (rev 207620)
@@ -23,7 +23,7 @@
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
- (bounds 285.00 135.00)
+ (bounds 285.00 150.00)
(children 1
(GraphicsLayer
(children 1
@@ -73,7 +73,7 @@
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
- (bounds 285.00 135.00)
+ (bounds 285.00 150.00)
(children 1
(GraphicsLayer
(children 1
Modified: trunk/Source/WebCore/ChangeLog (207619 => 207620)
--- trunk/Source/WebCore/ChangeLog 2016-10-20 15:57:25 UTC (rev 207619)
+++ trunk/Source/WebCore/ChangeLog 2016-10-20 16:38:50 UTC (rev 207620)
@@ -1,3 +1,41 @@
+2016-10-20 Andreas Kling
+
+Drop StyleResolver and SelectorQueryCache when entering PageCache.
+
+
+Reviewed by Antti Koivisto.
+
+Stop keeping these around for cached pages to save lots of memory.
+We can easily rebuild them if a cached navigation occurs, and this
+way we also don't need to worry about invalidating style for cached
+pages in all the right places.
+
+Restoring a cached page will now lead to a forced style recalc.
+We don't try to defer this (beyond a
Title: [207234] trunk/Source/WebCore
Revision 207234
Author akl...@apple.com
Date 2016-10-12 12:35:55 -0700 (Wed, 12 Oct 2016)
Log Message
Make Document::existingAXObjectCache() fast with accessibility disabled.
Reviewed by Antti Koivisto.
Instruments says we were spending 2.3% of Dromaeo/dom-modify.html in this function,
traversing ancestors. Track whether we've ever had a cache, and use that knowledge
to return early if possible.
* dom/Document.cpp:
(WebCore::Document::existingAXObjectCache):
(WebCore::Document::axObjectCache):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Document.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (207233 => 207234)
--- trunk/Source/WebCore/ChangeLog 2016-10-12 19:31:47 UTC (rev 207233)
+++ trunk/Source/WebCore/ChangeLog 2016-10-12 19:35:55 UTC (rev 207234)
@@ -1,3 +1,18 @@
+2016-10-12 Andreas Kling
+
+Make Document::existingAXObjectCache() fast with accessibility disabled.
+
+
+Reviewed by Antti Koivisto.
+
+Instruments says we were spending 2.3% of Dromaeo/dom-modify.html in this function,
+traversing ancestors. Track whether we've ever had a cache, and use that knowledge
+to return early if possible.
+
+* dom/Document.cpp:
+(WebCore::Document::existingAXObjectCache):
+(WebCore::Document::axObjectCache):
+
2016-10-12 Jeremy Huddleston Sequoia
[SOUP] trunk r207192 fails to compile due to missing std::function being unavailable (missing #include )
Modified: trunk/Source/WebCore/dom/Document.cpp (207233 => 207234)
--- trunk/Source/WebCore/dom/Document.cpp 2016-10-12 19:31:47 UTC (rev 207233)
+++ trunk/Source/WebCore/dom/Document.cpp 2016-10-12 19:35:55 UTC (rev 207234)
@@ -2427,8 +2427,13 @@
m_axObjectCache = nullptr;
}
+static bool hasEverCreatedAnAXObjectCache = false;
+
AXObjectCache* Document::existingAXObjectCache() const
{
+if (!hasEverCreatedAnAXObjectCache)
+return nullptr;
+
Document& topDocument = this->topDocument();
if (!topDocument.hasLivingRenderTree())
return nullptr;
@@ -2451,8 +2456,10 @@
return nullptr;
ASSERT( == this || !m_axObjectCache);
-if (!topDocument.m_axObjectCache)
+if (!topDocument.m_axObjectCache) {
topDocument.m_axObjectCache = std::make_unique(topDocument);
+hasEverCreatedAnAXObjectCache = true;
+}
return topDocument.m_axObjectCache.get();
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [206922] trunk
Revision 206922
Author akl...@apple.com
Date 2016-10-07 11:55:09 -0700 (Fri, 07 Oct 2016)
Log Message
[WK2] didRemoveFrameFromHierarchy callback doesn't fire for subframes when evicting from PageCache.
Reviewed by Antti Koivisto.
Source/WebCore:
Fix a bug where WK2 didRemoveFrameFromHierarchy callbacks wouldn't fire for subframes that were getting
kicked out of PageCache. The problem was happening because CachedFrame would disconnect the Frame from
its Page just before calling FrameLoader::detachViewsAndDocumentLoader() where the callbacks are fired.
Without a Page, the WebFrame on WK2 side can't find its WebPage, and so it can't fire its callbacks.
The fix is just to switch the order of those two lines.
This bug was causing frequent DOM and window object leaks in some clients *cough* Safari *cough* that
were relying on didRemoveFrameFromHierarchy to release their isolated worlds.
Test: WebKit2.DidRemoveFrameFromHiearchyInPageCache
* history/CachedFrame.cpp:
(WebCore::CachedFrame::destroy):
Tools:
Add an API test that puts a 10-subframe page into the page cache, then loads other pages
until the first page gets kicked out. The test succeeds if we receive didRemoveFrameFromHierarchy
callbacks for all the subframes.
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKit2/DidRemoveFrameFromHiearchyInPageCache.cpp: Added.
(TestWebKitAPI::didFinishLoadForFrame):
(TestWebKitAPI::setPageLoaderClient):
(TestWebKitAPI::didReceivePageMessageFromInjectedBundle):
(TestWebKitAPI::setInjectedBundleClient):
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKit2/DidRemoveFrameFromHiearchyInPageCache_Bundle.cpp: Added.
(TestWebKitAPI::didRemoveFrameFromHierarchyCallback):
(TestWebKitAPI::DidRemoveFrameFromHiearchyInPageCacheTest::DidRemoveFrameFromHiearchyInPageCacheTest):
(TestWebKitAPI::DidRemoveFrameFromHiearchyInPageCacheTest::didCreatePage):
* TestWebKitAPI/Tests/WebKit2/many-iframes.html: Added.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/history/CachedFrame.cpp
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
Added Paths
trunk/Tools/TestWebKitAPI/Tests/WebKit2/DidRemoveFrameFromHiearchyInPageCache.cpp
trunk/Tools/TestWebKitAPI/Tests/WebKit2/DidRemoveFrameFromHiearchyInPageCache_Bundle.cpp
trunk/Tools/TestWebKitAPI/Tests/WebKit2/many-iframes.html
Diff
Modified: trunk/Source/WebCore/ChangeLog (206921 => 206922)
--- trunk/Source/WebCore/ChangeLog 2016-10-07 17:44:51 UTC (rev 206921)
+++ trunk/Source/WebCore/ChangeLog 2016-10-07 18:55:09 UTC (rev 206922)
@@ -1,3 +1,26 @@
+2016-10-07 Andreas Kling
+
+[WK2] didRemoveFrameFromHierarchy callback doesn't fire for subframes when evicting from PageCache.
+
+
+
+Reviewed by Antti Koivisto.
+
+Fix a bug where WK2 didRemoveFrameFromHierarchy callbacks wouldn't fire for subframes that were getting
+kicked out of PageCache. The problem was happening because CachedFrame would disconnect the Frame from
+its Page just before calling FrameLoader::detachViewsAndDocumentLoader() where the callbacks are fired.
+Without a Page, the WebFrame on WK2 side can't find its WebPage, and so it can't fire its callbacks.
+
+The fix is just to switch the order of those two lines.
+
+This bug was causing frequent DOM and window object leaks in some clients *cough* Safari *cough* that
+were relying on didRemoveFrameFromHierarchy to release their isolated worlds.
+
+Test: WebKit2.DidRemoveFrameFromHiearchyInPageCache
+
+* history/CachedFrame.cpp:
+(WebCore::CachedFrame::destroy):
+
2016-10-07 Nan Wang
AX: AXRoleDescription for details and summary elements
Modified: trunk/Source/WebCore/history/CachedFrame.cpp (206921 => 206922)
--- trunk/Source/WebCore/history/CachedFrame.cpp 2016-10-07 17:44:51 UTC (rev 206921)
+++ trunk/Source/WebCore/history/CachedFrame.cpp 2016-10-07 18:55:09 UTC (rev 206922)
@@ -248,8 +248,8 @@
m_document->domWindow()->willDestroyCachedFrame();
if (!m_isMainFrame) {
+m_view->frame().loader().detachViewsAndDocumentLoader();
m_view->frame().detachFromPage();
-m_view->frame().loader().detachViewsAndDocumentLoader();
}
for (int i = m_childFrames.size() - 1; i >= 0; --i)
Modified: trunk/Tools/ChangeLog (206921 => 206922)
--- trunk/Tools/ChangeLog 2016-10-07 17:44:51 UTC (rev 206921)
+++ trunk/Tools/ChangeLog 2016-10-07 18:55:09 UTC (rev 206922)
@@ -1,3 +1,28 @@
+2016-10-07 Andreas Kling
+
+[WK2] didRemoveFrameFromHierarchy callback doesn't fire for subframes when evicting from PageCache.
+
+
+
+Reviewed by Antti Koivisto.
+
+Add an API test that puts a 10-subframe page into the page cache, then loads other pages
+until the first page gets kicked out. The
Title: [205290] trunk/Source/WebCore
Revision 205290
Author akl...@apple.com
Date 2016-09-01 07:22:33 -0700 (Thu, 01 Sep 2016)
Log Message
FocusController should pass KeyboardEvent around by reference.
Reviewed by Sam Weinig.
Clean up FocusController to pass KeyboardEvent& around internally.
Also make FocusController::setInitialFocus() synthesize a dummy KeyboardEvent
if one isn't provided, just like nextFocusableElement()/previousFocusableElement() does.
This way we can feel confident about dereferencing the formerly KeyboardEvent* everywhere.
* page/EventHandler.cpp:
(WebCore::EventHandler::defaultArrowEventHandler):
(WebCore::EventHandler::defaultTabEventHandler):
* page/FocusController.cpp:
(WebCore::isFocusableElementOrScopeOwner):
(WebCore::isNonFocusableScopeOwner):
(WebCore::isFocusableScopeOwner):
(WebCore::shadowAdjustedTabIndex):
(WebCore::FocusController::findFocusableElementDescendingDownIntoFrameDocument):
(WebCore::FocusController::setInitialFocus):
(WebCore::FocusController::advanceFocus):
(WebCore::FocusController::advanceFocusInDocumentOrder):
(WebCore::FocusController::findFocusableElementAcrossFocusScope):
(WebCore::FocusController::findFocusableElementWithinScope):
(WebCore::FocusController::nextFocusableElementWithinScope):
(WebCore::FocusController::previousFocusableElementWithinScope):
(WebCore::FocusController::findFocusableElementOrScopeOwner):
(WebCore::FocusController::findElementWithExactTabIndex):
(WebCore::nextElementWithGreaterTabIndex):
(WebCore::previousElementWithLowerTabIndex):
(WebCore::FocusController::nextFocusableElement):
(WebCore::FocusController::previousFocusableElement):
(WebCore::FocusController::nextFocusableElementOrScopeOwner):
(WebCore::FocusController::previousFocusableElementOrScopeOwner):
(WebCore::FocusController::findFocusCandidateInContainer):
(WebCore::FocusController::advanceFocusDirectionallyInContainer):
(WebCore::FocusController::advanceFocusDirectionally):
* page/FocusController.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/page/EventHandler.cpp
trunk/Source/WebCore/page/FocusController.cpp
trunk/Source/WebCore/page/FocusController.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (205289 => 205290)
--- trunk/Source/WebCore/ChangeLog 2016-09-01 14:14:05 UTC (rev 205289)
+++ trunk/Source/WebCore/ChangeLog 2016-09-01 14:22:33 UTC (rev 205290)
@@ -1,3 +1,45 @@
+2016-09-01 Andreas Kling
+
+FocusController should pass KeyboardEvent around by reference.
+
+
+Reviewed by Sam Weinig.
+
+Clean up FocusController to pass KeyboardEvent& around internally.
+
+Also make FocusController::setInitialFocus() synthesize a dummy KeyboardEvent
+if one isn't provided, just like nextFocusableElement()/previousFocusableElement() does.
+This way we can feel confident about dereferencing the formerly KeyboardEvent* everywhere.
+
+* page/EventHandler.cpp:
+(WebCore::EventHandler::defaultArrowEventHandler):
+(WebCore::EventHandler::defaultTabEventHandler):
+* page/FocusController.cpp:
+(WebCore::isFocusableElementOrScopeOwner):
+(WebCore::isNonFocusableScopeOwner):
+(WebCore::isFocusableScopeOwner):
+(WebCore::shadowAdjustedTabIndex):
+(WebCore::FocusController::findFocusableElementDescendingDownIntoFrameDocument):
+(WebCore::FocusController::setInitialFocus):
+(WebCore::FocusController::advanceFocus):
+(WebCore::FocusController::advanceFocusInDocumentOrder):
+(WebCore::FocusController::findFocusableElementAcrossFocusScope):
+(WebCore::FocusController::findFocusableElementWithinScope):
+(WebCore::FocusController::nextFocusableElementWithinScope):
+(WebCore::FocusController::previousFocusableElementWithinScope):
+(WebCore::FocusController::findFocusableElementOrScopeOwner):
+(WebCore::FocusController::findElementWithExactTabIndex):
+(WebCore::nextElementWithGreaterTabIndex):
+(WebCore::previousElementWithLowerTabIndex):
+(WebCore::FocusController::nextFocusableElement):
+(WebCore::FocusController::previousFocusableElement):
+(WebCore::FocusController::nextFocusableElementOrScopeOwner):
+(WebCore::FocusController::previousFocusableElementOrScopeOwner):
+(WebCore::FocusController::findFocusCandidateInContainer):
+(WebCore::FocusController::advanceFocusDirectionallyInContainer):
+(WebCore::FocusController::advanceFocusDirectionally):
+* page/FocusController.h:
+
2016-09-01 Romain Bellessort
[Streams API] Align internal structure of ReadableStream with spec
Modified: trunk/Source/WebCore/page/EventHandler.cpp (205289 => 205290)
--- trunk/Source/WebCore/page/EventHandler.cpp 2016-09-01 14:14:05 UTC (rev 205289)
+++ trunk/Source/WebCore/page/EventHandler.cpp 2016-09-01 14:22:33 UTC (rev
Title: [205053] trunk/Source/WebCore
Revision 205053
Author akl...@apple.com
Date 2016-08-26 15:41:41 -0700 (Fri, 26 Aug 2016)
Log Message
REGRESSION (r204987): fast/canvas-composite-* tests are now flaky assertion failures
Reviewed by Joseph Pecoraro.
Fix a blunder where HTMLCanvasElement::memoryCost() wasn't forwarding the inquiry
to ImageBuffer but HTMLCanvasElement::externalMemoryCost() was.
This fixes flaky "externalMemorySize() <= extraMemorySize()" assertions on debug bots.
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::memoryCost):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/html/HTMLCanvasElement.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (205052 => 205053)
--- trunk/Source/WebCore/ChangeLog 2016-08-26 22:16:36 UTC (rev 205052)
+++ trunk/Source/WebCore/ChangeLog 2016-08-26 22:41:41 UTC (rev 205053)
@@ -1,5 +1,20 @@
2016-08-26 Andreas Kling
+REGRESSION (r204987): fast/canvas-composite-* tests are now flaky assertion failures
+
+
+Reviewed by Joseph Pecoraro.
+
+Fix a blunder where HTMLCanvasElement::memoryCost() wasn't forwarding the inquiry
+to ImageBuffer but HTMLCanvasElement::externalMemoryCost() was.
+
+This fixes flaky "externalMemorySize() <= extraMemorySize()" assertions on debug bots.
+
+* html/HTMLCanvasElement.cpp:
+(WebCore::HTMLCanvasElement::memoryCost):
+
+2016-08-26 Andreas Kling
+
The :enabled/:disabled selectors should only match elements that can be disabled.
Modified: trunk/Source/WebCore/html/HTMLCanvasElement.cpp (205052 => 205053)
--- trunk/Source/WebCore/html/HTMLCanvasElement.cpp 2016-08-26 22:16:36 UTC (rev 205052)
+++ trunk/Source/WebCore/html/HTMLCanvasElement.cpp 2016-08-26 22:41:41 UTC (rev 205053)
@@ -575,7 +575,7 @@
{
if (!m_imageBuffer)
return 0;
-return 4 * m_imageBuffer->internalSize().width() * m_imageBuffer->internalSize().height();
+return m_imageBuffer->memoryCost();
}
size_t HTMLCanvasElement::externalMemoryCost() const
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [205050] trunk
Revision 205050
Author akl...@apple.com
Date 2016-08-26 14:46:07 -0700 (Fri, 26 Aug 2016)
Log Message
The :enabled/:disabled selectors should only match elements that can be disabled.
Reviewed by Chris Dumez.
LayoutTests/imported/w3c:
* web-platform-tests/html/semantics/selectors/pseudo-classes/disabled-expected.txt:
Source/WebCore:
Per the HTML spec, only the following elements can be actually disabled:
button, input, select, textarea, optgroup, option, menuitem, fieldset
Since HTMLOutputElement inherits from HTMLFormControlElement, it had some
misguided ideas about being disableable. This was causing it to get matched
by :enabled and :disabled selectors.
Test: imported/w3c/web-platform-tests/html/semantics/selectors/pseudo-classes/disabled.html
* css/SelectorChecker.cpp:
(WebCore::SelectorChecker::checkOne):
* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::addPseudoClassType):
* css/SelectorCheckerTestFunctions.h:
(WebCore::matchesDisabledPseudoClass):
(WebCore::matchesEnabledPseudoClass): Renamed from isEnabled/isDisabled. Now only allows
:enabled and :disabled selectors to match elements that are actually disableable.
* html/HTMLElement.h:
* html/HTMLElement.cpp:
(WebCore::HTMLElement::canBeActuallyDisabled):
(WebCore::HTMLElement::isActuallyDisabled): Added supporting functions for the aforementioned selectors.
* html/HTMLFormControlElement.cpp:
(WebCore::HTMLFormControlElement::parseAttribute): Don't care about disabled state
changes in elements that are not disableable in the first place.
Modified Paths
trunk/LayoutTests/imported/w3c/ChangeLog
trunk/LayoutTests/imported/w3c/web-platform-tests/html/semantics/selectors/pseudo-classes/disabled-expected.txt
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/css/SelectorChecker.cpp
trunk/Source/WebCore/css/SelectorCheckerTestFunctions.h
trunk/Source/WebCore/cssjit/SelectorCompiler.cpp
trunk/Source/WebCore/html/HTMLElement.cpp
trunk/Source/WebCore/html/HTMLElement.h
trunk/Source/WebCore/html/HTMLFormControlElement.cpp
Diff
Modified: trunk/LayoutTests/imported/w3c/ChangeLog (205049 => 205050)
--- trunk/LayoutTests/imported/w3c/ChangeLog 2016-08-26 21:41:28 UTC (rev 205049)
+++ trunk/LayoutTests/imported/w3c/ChangeLog 2016-08-26 21:46:07 UTC (rev 205050)
@@ -1,3 +1,12 @@
+2016-08-26 Andreas Kling
+
+The :enabled/:disabled selectors should only match elements that can be disabled.
+
+
+Reviewed by Chris Dumez.
+
+* web-platform-tests/html/semantics/selectors/pseudo-classes/disabled-expected.txt:
+
2016-08-26 Chris Dumez
HTMLAreaElement's coords attributes parsing does not comply with the HTML specification
Modified: trunk/LayoutTests/imported/w3c/web-platform-tests/html/semantics/selectors/pseudo-classes/disabled-expected.txt (205049 => 205050)
--- trunk/LayoutTests/imported/w3c/web-platform-tests/html/semantics/selectors/pseudo-classes/disabled-expected.txt 2016-08-26 21:41:28 UTC (rev 205049)
+++ trunk/LayoutTests/imported/w3c/web-platform-tests/html/semantics/selectors/pseudo-classes/disabled-expected.txt 2016-08-26 21:46:07 UTC (rev 205050)
@@ -1,10 +1,10 @@
-FAIL ':disabled' should match only disabled elements assert_array_equals: lengths differ, expected 9 got 10
-FAIL ':disabled' should not match elements whose disabled attribute has been removed assert_array_equals: lengths differ, expected 8 got 9
-FAIL ':disabled' should also match elements whose disabled attribute has been set assert_array_equals: lengths differ, expected 9 got 10
-FAIL ':disabled' should also match elements whose disabled attribute has been set twice assert_array_equals: lengths differ, expected 9 got 10
-FAIL ':disabled' should also match disabled elements whose type has changed assert_array_equals: lengths differ, expected 9 got 10
-FAIL ':disabled' should not match elements not in the document assert_array_equals: lengths differ, expected 9 got 10
+PASS ':disabled' should match only disabled elements
+PASS ':disabled' should not match elements whose disabled attribute has been removed
+PASS ':disabled' should also match elements whose disabled attribute has been set
+PASS ':disabled' should also match elements whose disabled attribute has been set twice
+PASS ':disabled' should also match disabled elements whose type has changed
+PASS ':disabled' should not match elements not in the document
button1 button2
Name on card:
Modified: trunk/Source/WebCore/ChangeLog (205049 => 205050)
--- trunk/Source/WebCore/ChangeLog 2016-08-26 21:41:28 UTC (rev 205049)
+++ trunk/Source/WebCore/ChangeLog 2016-08-26 21:46:07 UTC (rev 205050)
@@ -1,3 +1,38 @@
+2016-08-26 Andreas Kling
+
+The :enabled/:disabled selectors should only match elements that can be disabled.
+
+
+Reviewed by Chris Dumez.
+
+Per the HTML spec, only the following elements can be actually
Title: [204987] trunk/Source/WebCore
Revision 204987
Author akl...@apple.com
Date 2016-08-25 14:57:13 -0700 (Thu, 25 Aug 2016)
Log Message
REGRESSION: RELEASE_ASSERT in ResourceUsageThread::platformThreadBody when ASan is enabled
Reviewed by Joseph Pecoraro.
* page/cocoa/ResourceUsageThreadCocoa.mm:
(WebCore::ResourceUsageThread::platformThreadBody): Remove overly optimistic assertions about
"GC owned" memory never being higher than total malloc memory usage. This accounting is not
really exact and pretending otherwise will just lead to crashes.
* html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::externalMemoryCost): Hook up HTMLCanvasElement to the ImageBuffer
helper for reporting external memory cost. This makes accounting slightly more correct.
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/html/HTMLCanvasElement.cpp
trunk/Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm
Diff
Modified: trunk/Source/WebCore/ChangeLog (204986 => 204987)
--- trunk/Source/WebCore/ChangeLog 2016-08-25 21:48:33 UTC (rev 204986)
+++ trunk/Source/WebCore/ChangeLog 2016-08-25 21:57:13 UTC (rev 204987)
@@ -1,3 +1,20 @@
+2016-08-25 Andreas Kling
+
+REGRESSION: RELEASE_ASSERT in ResourceUsageThread::platformThreadBody when ASan is enabled
+
+
+
+Reviewed by Joseph Pecoraro.
+
+* page/cocoa/ResourceUsageThreadCocoa.mm:
+(WebCore::ResourceUsageThread::platformThreadBody): Remove overly optimistic assertions about
+"GC owned" memory never being higher than total malloc memory usage. This accounting is not
+really exact and pretending otherwise will just lead to crashes.
+
+* html/HTMLCanvasElement.cpp:
+(WebCore::HTMLCanvasElement::externalMemoryCost): Hook up HTMLCanvasElement to the ImageBuffer
+helper for reporting external memory cost. This makes accounting slightly more correct.
+
2016-08-25 Chris Dumez
Regression(r203623): Breaks App Store application
Modified: trunk/Source/WebCore/html/HTMLCanvasElement.cpp (204986 => 204987)
--- trunk/Source/WebCore/html/HTMLCanvasElement.cpp 2016-08-25 21:48:33 UTC (rev 204986)
+++ trunk/Source/WebCore/html/HTMLCanvasElement.cpp 2016-08-25 21:57:13 UTC (rev 204987)
@@ -582,7 +582,7 @@
{
if (!m_imageBuffer)
return 0;
-return 4 * m_imageBuffer->internalSize().width() * m_imageBuffer->internalSize().height();
+return m_imageBuffer->externalMemoryCost();
}
void HTMLCanvasElement::setUsesDisplayListDrawing(bool usesDisplayListDrawing)
Modified: trunk/Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm (204986 => 204987)
--- trunk/Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm 2016-08-25 21:48:33 UTC (rev 204986)
+++ trunk/Source/WebCore/page/cocoa/ResourceUsageThreadCocoa.mm 2016-08-25 21:57:13 UTC (rev 204987)
@@ -227,15 +227,16 @@
data.categories[MemoryCategory::GCOwned].dirtySize = currentGCOwnedExtra - currentGCOwnedExternal;
data.categories[MemoryCategory::GCOwned].externalSize = currentGCOwnedExternal;
-// Subtract known subchunks from the appropriate malloc bucket.
+auto& mallocBucket = isFastMallocEnabled() ? data.categories[MemoryCategory::bmalloc] : data.categories[MemoryCategory::LibcMalloc];
+
+// First subtract memory allocated by the GC heap, since we track that separately.
+mallocBucket.dirtySize -= currentGCHeapCapacity;
+
+// It would be nice to assert that the "GC owned" amount is smaller than the total dirty malloc size,
+// but since the "GC owned" accounting is inexact, it's not currently feasible.
size_t currentGCOwnedGenerallyInMalloc = currentGCOwnedExtra - currentGCOwnedExternal;
-if (isFastMallocEnabled()) {
-RELEASE_ASSERT(currentGCOwnedGenerallyInMalloc < data.categories[MemoryCategory::bmalloc].dirtySize);
-data.categories[MemoryCategory::bmalloc].dirtySize -= currentGCHeapCapacity + currentGCOwnedGenerallyInMalloc;
-} else {
-RELEASE_ASSERT(currentGCOwnedGenerallyInMalloc < data.categories[MemoryCategory::LibcMalloc].dirtySize);
-data.categories[MemoryCategory::LibcMalloc].dirtySize -= currentGCHeapCapacity + currentGCOwnedGenerallyInMalloc;
-}
+if (currentGCOwnedGenerallyInMalloc < mallocBucket.dirtySize)
+mallocBucket.dirtySize -= currentGCOwnedGenerallyInMalloc;
data.totalExternalSize = currentGCOwnedExternal;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [203420] trunk/Source/WebCore
Revision 203420
Author akl...@apple.com
Date 2016-07-19 14:14:04 -0700 (Tue, 19 Jul 2016)
Log Message
Fix SharedBuffer leak in MockContentFilter::replacementData().
Reviewed by Andy Estes.
Spotted on leaks bot. This code was pretty explicit about how it's going to leak.
Since this is in the mock filter, it only affected layout tests.
* testing/MockContentFilter.cpp:
(WebCore::MockContentFilter::replacementData):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/testing/MockContentFilter.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (203419 => 203420)
--- trunk/Source/WebCore/ChangeLog 2016-07-19 20:52:48 UTC (rev 203419)
+++ trunk/Source/WebCore/ChangeLog 2016-07-19 21:14:04 UTC (rev 203420)
@@ -1,3 +1,16 @@
+2016-07-19 Andreas Kling
+
+Fix SharedBuffer leak in MockContentFilter::replacementData().
+
+
+Reviewed by Andy Estes.
+
+Spotted on leaks bot. This code was pretty explicit about how it's going to leak.
+Since this is in the mock filter, it only affected layout tests.
+
+* testing/MockContentFilter.cpp:
+(WebCore::MockContentFilter::replacementData):
+
2016-07-19 Zalan Bujtas
theguardian.co.uk crossword puzzles are sometimes not displaying text
Modified: trunk/Source/WebCore/testing/MockContentFilter.cpp (203419 => 203420)
--- trunk/Source/WebCore/testing/MockContentFilter.cpp 2016-07-19 20:52:48 UTC (rev 203419)
+++ trunk/Source/WebCore/testing/MockContentFilter.cpp 2016-07-19 21:14:04 UTC (rev 203420)
@@ -114,7 +114,7 @@
Ref MockContentFilter::replacementData() const
{
ASSERT(didBlockData());
-return SharedBuffer::create(m_replacementData.data(), m_replacementData.size()).leakRef();
+return SharedBuffer::create(m_replacementData.data(), m_replacementData.size());
}
ContentFilterUnblockHandler MockContentFilter::unblockHandler() const
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
Title: [203379] trunk
Revision 203379
Author akl...@apple.com
Date 2016-07-18 16:16:24 -0700 (Mon, 18 Jul 2016)
Log Message
There should be a way to simulate memory pressure in layout tests
Reviewed by Simon Fraser.
Source/WebCore:
Add three window.internal APIs:
- boolean isUnderMemoryPressure (readonly attribute)
- void beginSimulatedMemoryPressure()
- void endSimulatedMemoryPressure()
These make it possible to write tests that exercise behaviors that only
occur during memory pressure situations.
I also implemented the "org.WebKit.lowMemory" notification handler using the new API.
Test: memory/memory-pressure-simulation.html
* platform/MemoryPressureHandler.cpp:
(WebCore::MemoryPressureHandler::beginSimulatedMemoryPressure):
(WebCore::MemoryPressureHandler::endSimulatedMemoryPressure):
* platform/MemoryPressureHandler.h:
(WebCore::MemoryPressureHandler::isUnderMemoryPressure):
* platform/cocoa/MemoryPressureHandlerCocoa.mm:
(WebCore::MemoryPressureHandler::platformReleaseMemory):
(WebCore::MemoryPressureHandler::install):
* testing/Internals.cpp:
(WebCore::Internals::isUnderMemoryPressure):
(WebCore::Internals::beginSimulatedMemoryPressure):
(WebCore::Internals::endSimulatedMemoryPressure):
* testing/Internals.h:
* testing/Internals.idl:
LayoutTests:
Add a basic test for the new APIs.
* memory/memory-pressure-simulation-expected.txt: Added.
* memory/memory-pressure-simulation.html: Added.
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/platform/MemoryPressureHandler.cpp
trunk/Source/WebCore/platform/MemoryPressureHandler.h
trunk/Source/WebCore/platform/cocoa/MemoryPressureHandlerCocoa.mm
trunk/Source/WebCore/testing/Internals.cpp
trunk/Source/WebCore/testing/Internals.h
trunk/Source/WebCore/testing/Internals.idl
Added Paths
trunk/LayoutTests/memory/
trunk/LayoutTests/memory/memory-pressure-simulation-expected.txt
trunk/LayoutTests/memory/memory-pressure-simulation.html
Diff
Modified: trunk/LayoutTests/ChangeLog (203378 => 203379)
--- trunk/LayoutTests/ChangeLog 2016-07-18 22:46:37 UTC (rev 203378)
+++ trunk/LayoutTests/ChangeLog 2016-07-18 23:16:24 UTC (rev 203379)
@@ -1,3 +1,15 @@
+2016-07-18 Andreas Kling
+
+There should be a way to simulate memory pressure in layout tests
+
+
+Reviewed by Simon Fraser.
+
+Add a basic test for the new APIs.
+
+* memory/memory-pressure-simulation-expected.txt: Added.
+* memory/memory-pressure-simulation.html: Added.
+
2016-07-18 Said Abou-Hallawa
[iOS] PDFDocumentImage should cache only a sub image of the PDF when caching the whole image is expensive
Added: trunk/LayoutTests/memory/memory-pressure-simulation-expected.txt (0 => 203379)
--- trunk/LayoutTests/memory/memory-pressure-simulation-expected.txt (rev 0)
+++ trunk/LayoutTests/memory/memory-pressure-simulation-expected.txt 2016-07-18 23:16:24 UTC (rev 203379)
@@ -0,0 +1,15 @@
+Basic test for the memory pressure simulation mechanism.
+
+On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
+
+
+Verify that we're not running under memory pressure from the beginning.
+PASS internals.isUnderMemoryPressure is false
+Begin simulated memory pressure.
+PASS internals.isUnderMemoryPressure is true
+End simulated memory pressure.
+PASS internals.isUnderMemoryPressure is false
+PASS successfullyParsed is true
+
+TEST COMPLETE
+
Added: trunk/LayoutTests/memory/memory-pressure-simulation.html (0 => 203379)
--- trunk/LayoutTests/memory/memory-pressure-simulation.html (rev 0)
+++ trunk/LayoutTests/memory/memory-pressure-simulation.html 2016-07-18 23:16:24 UTC (rev 203379)
@@ -0,0 +1,28 @@
+
+
+
+
+
+