Reduce memory use for static property maps
https://bugs.webkit.org/show_bug.cgi?id=129986

Reviewed by Andreas Kling.

Static property tables are currently duplicated on first use from read-only memory into dirty memory
in every process, and since the entries are large (48 bytes) and the tables can be unusually sparse
(we use a custom hash table without a rehash) a lot of memory may be wasted.

Source/JavaScriptCore: 

First, reduce the size of the hashtable. Instead of storing values in the table the hashtable maps
from string hashes to indicies into a densely packed array of values. Compute the index table at
compile time as a part of the derived sources step, such that this may be read-only data.

Second, don't copy all data from the HashTableValue array into a HashEntry objects. Instead refer
directly to the HashTableValue entries. The only data that needs to be allocated at runtime are the
keys, which are Identifiers.

* create_hash_table:
    - emit the hash table index into the derived source (we were calculating this already to ensure chaining does not get too deep).
* parser/Lexer.cpp:
(JSC::Lexer<LChar>::parseIdentifier):
(JSC::Lexer<UChar>::parseIdentifier):
(JSC::Lexer<T>::parseIdentifierSlowCase):
    - HashEntry -> HashTableValue.
* parser/Lexer.h:
(JSC::Keywords::getKeyword):
    - HashEntry -> HashTableValue.
* runtime/ClassInfo.h:
    - removed HashEntry.
* runtime/JSObject.cpp:
(JSC::getClassPropertyNames):
    - use HashTable::ConstIterator.
(JSC::JSObject::put):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::findPropertyHashEntry):
    - HashEntry -> HashTableValue.
(JSC::JSObject::reifyStaticFunctionsForDelete):
    - changed HashTable::ConstIterator interface.
* runtime/JSObject.h:
    - HashEntry -> HashTableValue.
* runtime/Lookup.cpp:
(JSC::HashTable::createTable):
    - table -> keys, keys array is now densely packed.
(JSC::HashTable::deleteTable):
    - table -> keys.
(JSC::setUpStaticFunctionSlot):
    - HashEntry -> HashTableValue.
* runtime/Lookup.h:
(JSC::HashTableValue::builtinGenerator):
(JSC::HashTableValue::function):
(JSC::HashTableValue::functionLength):
(JSC::HashTableValue::propertyGetter):
(JSC::HashTableValue::propertyPutter):
(JSC::HashTableValue::lexerValue):
    - added accessor methods from HashEntry.
(JSC::HashTable::copy):
    - fields changed.
(JSC::HashTable::initializeIfNeeded):
    - table -> keys.
(JSC::HashTable::entry):
    - HashEntry -> HashTableValue.
(JSC::HashTable::ConstIterator::ConstIterator):
    - iterate packed value array, so no need to skipInvalidKeys().
(JSC::HashTable::ConstIterator::value):
(JSC::HashTable::ConstIterator::key):
(JSC::HashTable::ConstIterator::operator->):
    - accessors now get HashTableValue/StringImpl* separately.
(JSC::HashTable::ConstIterator::operator++):
    - iterate packed value array, so no need to skipInvalidKeys().
(JSC::HashTable::end):
    - end is now size of dense not sparse array.
(JSC::getStaticPropertySlot):
(JSC::getStaticFunctionSlot):
(JSC::getStaticValueSlot):
(JSC::putEntry):
(JSC::lookupPut):
    - HashEntry -> HashTableValue.

Source/WebCore: 

* bindings/js/JSDOMBinding.h:
(WebCore::getStaticValueSlotEntryWithoutCaching):
(WebCore::getStaticValueSlotEntryWithoutCaching<JSDOMWrapper>):
    - HashEntry -> HashTableValue.
* bindings/js/JSDOMWindowCustom.cpp:
(WebCore::JSDOMWindow::getOwnPropertySlot):
    - HashEntry -> HashTableValue.
* bindings/js/JSHistoryCustom.cpp:
(WebCore::JSHistory::getOwnPropertySlotDelegate):
    - HashEntry -> HashTableValue.
* bindings/js/JSLocationCustom.cpp:
(WebCore::JSLocation::getOwnPropertySlotDelegate):
(WebCore::JSLocation::putDelegate):
    - HashEntry -> HashTableValue.
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateGetOwnPropertySlotBody):
    - HashEntry -> HashTableValue.
(GenerateHashTable):
    - emit the hash table index into the derived source (we were calculating this already to ensure chaining does not get too deep).

LayoutTests: 

* inspector-protocol/debugger/setPauseOnExceptions-all-expected.txt:
* inspector-protocol/debugger/setPauseOnExceptions-none-expected.txt:
* inspector-protocol/debugger/setPauseOnExceptions-uncaught-expected.txt:
* js/dom/dom-static-property-for-in-iteration-expected.txt:
    - Properties now iterated in correct order, not permuted by hash table.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165482 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Change scrollOffsetForFixedPosition() to do LayoutUnit math
https://bugs.webkit.org/show_bug.cgi?id=129981

Reviewed by Beth Dakin.

Source/WebCore:

FrameView::scrollOffsetForFixedPosition() returned an IntSize,
but to allow subpixel scroll offsets, we need it to return a LayoutSize.

Fix code that calls this to use more LayoutUnit math.

This progresses fixed background images on zoom, which cam now be subpixel
positioned.

* WebCore.exp.in:
* page/FrameView.cpp:
(WebCore::FrameView::viewportConstrainedVisibleContentRect):
(WebCore::FrameView::scrollOffsetForFixedPosition):
* page/FrameView.h:
* page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll):
* platform/ScrollableArea.cpp:
(WebCore::ScrollableArea::constrainScrollPositionForOverhang):
* platform/ScrollableArea.h:
* rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::calculateBackgroundImageGeometry):
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects):
* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateGraphicsLayerGeometry):
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateScrollLayerPosition):

LayoutTests:

FrameView::scrollOffsetForFixedPosition() returned an IntSize,
but to allow subpixel scroll offsets, we need it to return a LayoutSize.

Update test results for the progression.

* platform/mac-wk2/tiled-drawing/fixed-background/fixed-body-background-zoomed-expected.png:
* platform/mac-wk2/tiled-drawing/fixed-background/fixed-body-background-zoomed-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165484 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r165471.
https://bugs.webkit.org/show_bug.cgi?id=130139

Didn't really fix the issue and broke another bot (Requested
by mrobinson on #webkit).

Reverted changeset:

"[CMake] Newer versions of CMake cannot find older versions of
Freetype"
https://bugs.webkit.org/show_bug.cgi?id=130107
http://trac.webkit.org/changeset/165471

Patch by Commit Queue <commit-queue@webkit.org> on 2014-03-12

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165485 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Layout Test fast/workers/worker-gc.html is failing
https://bugs.webkit.org/show_bug.cgi?id=130135

Reviewed by Geoffrey Garen.

When removing MarkedBlocks, we always expect them to be in the MarkedAllocator's 
main list of blocks, i.e. not in the retired list. When shutting down the VM this
wasn't always the case which was causing ASSERTs to fire. We should rearrange things 
so that allocators are notified with lastChanceToFinalize. This will give them 
the chance to move their retired blocks back into the main list before removing them all.

* heap/MarkedAllocator.cpp:
(JSC::LastChanceToFinalize::operator()):
(JSC::MarkedAllocator::lastChanceToFinalize):
* heap/MarkedAllocator.h:
* heap/MarkedSpace.cpp:
(JSC::LastChanceToFinalize::operator()):
(JSC::MarkedSpace::lastChanceToFinalize):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165486 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: DataGrid should have an API to set sort column and direction
https://bugs.webkit.org/show_bug.cgi?id=128783

Reviewed by Timothy Hatcher.

Previously there was no way for DataGrid clients to programmatically change
the sort order or sort column identifier after the data grid was constructed.
This patch modernizes DataGrid sorting by exposing getters and setters for
sortOrder and sortColumnIdentifier, which trigger the SortChanged event if
the sort settings have changed.

This patch also modernizes sorting functionality in DataGrid clients, and in
a few clients it moves column identifiers from numbers to string identifiers.

* UserInterface/Main.html:
* UserInterface/Views/ApplicationCacheFrameContentView.js: Use string column identifiers
instead of numbers. Don't repopulate the entire table when the sort changes, instead
call DataGrid.sortNodes from the sorting callback. Explicitly set the sort order.

(WebInspector.ApplicationCacheFrameContentView.prototype._createDataGrid):
(WebInspector.ApplicationCacheFrameContentView.prototype._sortDataGrid):
(WebInspector.ApplicationCacheFrameContentView.prototype._sortDataGrid.localeCompare):
(WebInspector.ApplicationCacheFrameContentView.prototype._populateDataGrid):

* UserInterface/Views/CookieStorageContentView.js: Use string column identifiers instead
of numbers. Don't sort the cookies themselves, just the data grid nodes representing
each cookie. Use DataGrid.sortNodes as the sorting implementation, and provide a
comparator. Don't rebuild the entire table when the sort changes.

(WebInspector.CookieStorageContentView.prototype._rebuildTable):
(WebInspector.CookieStorageContentView.prototype._sortDataGrid):
(WebInspector.CookieStorageContentView.prototype._sortDataGrid.numberCompare):
(WebInspector.CookieStorageContentView.prototype._sortDataGrid.expiresCompare):

* UserInterface/Views/DataGrid.js: Add the DataGrid.SortOrder enum. Put sortOrder
and sortColumnIdentifier behind getters and setters. Pull some hardcoded style
class names into constants. Remove the "sort" field on column config objects; instead
should use the DataGrid.sortColumnIdentifier setter after construction.

(WebInspector.DataGrid): Keep sort settings in private variables.
(WebInspector.DataGrid.prototype.get sortOrder): Reimplemented.
(WebInspector.DataGrid.prototype.get sortColumnIdentifier): Reimplemented.
(WebInspector.DataGrid.prototype.moveToNextCell):
(WebInspector.DataGrid.prototype._editingCommitted):
(WebInspector.DataGrid.prototype.sortNodes): Use requestAnimationFrame to
coalesce multiple sort requests within the same draw frame.
(WebInspector.DataGrid.prototype._sortNodesCallback):
(WebInspector.DataGrid.prototype._headerCellClicked): Use the new sort API.
* UserInterface/Views/LayerTreeDataGrid.js: Removed. Unnecessary for performance
now that sort requests are coalesced by requestAnimationFrame.

* UserInterface/Views/LayerTreeSidebarPanel.js: Use DataGrid instead of LayerTreeDataGrid.
Hook up the _sortDataGrid method to the built-in DataGrid.sortNodes API.

(WebInspector.LayerTreeSidebarPanel.prototype._buildDataGridSection):
(WebInspector.LayerTreeSidebarPanel.prototype._sortDataGrid.comparator):
(WebInspector.LayerTreeSidebarPanel.prototype._sortDataGrid):
* UserInterface/Views/LayoutTimelineView.js:
* UserInterface/Views/LegacyJavaScriptProfileView.js:
(WebInspector.LegacyJavaScriptProfileView.prototype._sortProfile):
* UserInterface/Views/NetworkTimelineView.js:
* UserInterface/Views/ResourceDetailsSidebarPanel.js: Use the DataGrid.sortNodes API.
(WebInspector.ResourceDetailsSidebarPanel.prototype._createNameValueDataGrid.sortDataGrid.comparator):
(WebInspector.ResourceDetailsSidebarPanel.prototype._createNameValueDataGrid.sortDataGrid):
(WebInspector.ResourceDetailsSidebarPanel.prototype._createNameValueDataGrid):
* UserInterface/Views/ScriptTimelineView.js:
* UserInterface/Views/TimelineDataGrid.js:
(WebInspector.TimelineDataGrid.prototype._sortComparator):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165487 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK][CMAKE] Remove compile warnings about GTK+ deprecated API
https://bugs.webkit.org/show_bug.cgi?id=130014

Reviewed by Martin Robinson.

.:

Set GDK_VERSION_MIN_REQUIRED to GDK_VERSION_3_6.

* Source/cmake/OptionsGTK.cmake:
* Source/cmakeconfig.h.cmake:

Tools:

Include cmake or autotools config header.

* MiniBrowser/gtk/BrowserDownloadsBar.c:
* MiniBrowser/gtk/BrowserSearchBar.c:
* MiniBrowser/gtk/BrowserWindow.c:
* MiniBrowser/gtk/main.c:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165488 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Runtime error when page is closed while print operation is in progress
https://bugs.webkit.org/show_bug.cgi?id=129869

Reviewed by Anders Carlsson.

Sometimes when the page is closed right after printing the web
process aborts with the runtime message "pure virtual method
called terminate called without an active exception".
This happens because the page is closed when the pages have been
printed, but print job is still ongoing sending the data to the
printer. When print job finishes, we try to notify the UI process
sending the print callback message using WebPage::send(), but the
web page object has been destroyed. The virtual method it complains
about is probably MessageSender::messageSenderDestinationID() used
by send(). Since our print operation is always asynchronous, we
need a way to notify the web page when the print operation has
actually finished to clean it up, but also notify the print
operation when the page has been closed to not try to notify the
UI process in that case.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close): Call disconnectFromPage to notify the
print operation in case there's an ongoing print job.
(WebKit::WebPage::endPrinting): Do not cleanup the print operation
here, since the print opertation might not have finished yet.
(WebKit::WebPage::didFinishPrintOperation): Send
PrintFinishedCallback message to the Ui process and cleanup the
print operation.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/gtk/WebPrintOperationGtk.cpp:
(WebKit::WebPrintOperationGtk::disconnectFromPage): Set m_webPage
to nullptr.
(WebKit::WebPrintOperationGtk::printDone): Call
didFinishPrintOperation() is the web page hasn't been closed.
* WebProcess/WebPage/gtk/WebPrintOperationGtk.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165489 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove HandleSet::m_nextToFinalize
https://bugs.webkit.org/show_bug.cgi?id=130109

Reviewed by Mark Lam.

This is a remnant of when HandleSet contained things that needed to be finalized. 

* heap/HandleSet.cpp:
(JSC::HandleSet::HandleSet):
(JSC::HandleSet::writeBarrier):
* heap/HandleSet.h:
(JSC::HandleSet::allocate):
(JSC::HandleSet::deallocate):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165490 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Spelling is hard
https://bugs.webkit.org/show_bug.cgi?id=130146

Source/WebCore:

Reviewed by Beth Dakin.

Fix spelling (constained -> constrained).

* rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::styleDidChange):

Source/WebKit/ios:

Reviewed by Beth Dakin.

Fix spelling (constained -> constrained).

* WebCoreSupport/WebFixedPositionContent.mm:
(-[WebFixedPositionContent scrollOrZoomChanged:]):
(-[WebFixedPositionContent overflowScrollPositionForLayer:changedTo:]):
(-[WebFixedPositionContent setViewportConstrainedLayers:WTF::WebCore::stickyContainerMap:WTF::]):
(-[WebFixedPositionContent hasFixedOrStickyPositionLayers]):
(-[WebFixedPositionContent minimumOffsetFromFixedPositionLayersToAnchorEdge:ofRect:inLayer:]):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165491 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r165481.
https://bugs.webkit.org/show_bug.cgi?id=130151

That didn't go well. (Requested by kling on #webkit).

Reverted changeset:

https://bugs.webkit.org/show_bug.cgi?id=130140
http://trac.webkit.org/changeset/165481

Patch by Commit Queue <commit-queue@webkit.org> on 2014-03-12

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165492 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Have the scrolling tree track the viewport size, not the viewport rect
https://bugs.webkit.org/show_bug.cgi?id=130141

Reviewed by Beth Dakin.

Source/WebCore:

The scrolling tree only needs to know the size of the viewport, not its
origin, since the origin is deduced from the updated scroll position.

* WebCore.exp.in:
* page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::frameViewLayoutUpdated):
* page/scrolling/ScrollingStateScrollingNode.cpp:
(WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode):
(WebCore::ScrollingStateScrollingNode::setViewportSize):
(WebCore::ScrollingStateScrollingNode::dumpProperties):
* page/scrolling/ScrollingStateScrollingNode.h:
* page/scrolling/ScrollingTreeScrollingNode.cpp:
(WebCore::ScrollingTreeScrollingNode::updateBeforeChildren):
* page/scrolling/ScrollingTreeScrollingNode.h:
(WebCore::ScrollingTreeScrollingNode::viewportSize):
* page/scrolling/ios/ScrollingTreeScrollingNodeIOS.mm:
(WebCore::ScrollingTreeScrollingNodeIOS::setScrollLayerPosition):
(WebCore::ScrollingTreeScrollingNodeIOS::maximumScrollPosition):
* page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm:
(WebCore::ScrollingTreeScrollingNodeMac::updateAfterChildren):
(WebCore::ScrollingTreeScrollingNodeMac::setScrollLayerPosition):
(WebCore::ScrollingTreeScrollingNodeMac::maximumScrollPosition):
(WebCore::ScrollingTreeScrollingNodeMac::logExposedUnfilledArea):

Source/WebKit2:

The scrolling tree only needs to know the size of the viewport, not its
origin, since the origin is deduced from the updated scroll position.

* Shared/Scrolling/RemoteScrollingCoordinatorTransaction.cpp:
(ArgumentCoder<ScrollingStateScrollingNode>::encode):
(ArgumentCoder<ScrollingStateScrollingNode>::decode):

LayoutTests:

The scrolling tree only needs to know the size of the viewport, not its
origin, since the origin is deduced from the updated scroll position.

Tests dump a size, not a rect with a 0,0 origin now.

* platform/mac-wk2/tiled-drawing/clamp-out-of-bounds-scrolls-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/absolute-inside-fixed-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/absolute-inside-out-of-view-fixed-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/fixed-in-overflow-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/fixed-position-out-of-view-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/fixed-position-out-of-view-negative-zindex-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/four-bars-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/four-bars-with-header-and-footer-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/negative-scroll-offset-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/negative-scroll-offset-in-view-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/nested-fixed-expected.txt:
* platform/mac-wk2/tiled-drawing/fixed/percentage-inside-fixed-expected.txt:
* platform/mac-wk2/tiled-drawing/scrolling-tree-after-scroll-expected.txt:
* platform/mac-wk2/tiled-drawing/scrolling-tree-slow-scrolling-expected.txt:
* platform/mac-wk2/tiled-drawing/sticky/negative-scroll-offset-expected.txt:
* platform/mac-wk2/tiled-drawing/sticky/sticky-horizontal-expected.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165493 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Fix GTK+ cmake build after r165488.

* MiniBrowser/gtk/CMakeLists.txt: Add CMAKE_BINARY_DIR to include dirs.

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