Array profiling has convergence issues
https://bugs.webkit.org/show_bug.cgi?id=96891

Reviewed by Gavin Barraclough.

Source/JavaScriptCore: 

Now each array profiling site merges in the indexing type it observed into
the m_observedArrayModes bitset. The ArrayProfile also uses this to detect
cases where the structure must have gone polymorphic (if the bitset is
polymorphic then the structure must be). This achieves something like the
best of both worlds: on the one hand, we get a probabilistic structure that
we can use to optimize the monomorphic structure case, but on the other hand,
we get an accurate view of the set of types that were encountered.

* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::or32):
(MacroAssemblerARMv7):
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::or32):
(MacroAssemblerX86):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::or32):
(MacroAssemblerX86_64):
* assembler/X86Assembler.h:
(X86Assembler):
(JSC::X86Assembler::orl_rm):
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::addressOfArrayModes):
(JSC::ArrayProfile::structureIsPolymorphic):
* jit/JIT.h:
(JIT):
* jit/JITInlineMethods.h:
(JSC):
(JSC::JIT::emitArrayProfilingSite):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::privateCompilePatchGetArrayLength):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::privateCompilePatchGetArrayLength):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:

Source/WTF: 

Added functions for testing if something is a power of 2.

* wtf/MathExtras.h:
(hasZeroOrOneBitsSet):
(hasTwoOrMoreBitsSet):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128790 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash if we fail to allocate memory for the argument encoder buffer.
https://bugs.webkit.org/show_bug.cgi?id=88367

Reviewed by Andreas Kling.
<rdar://problem/11488239>

Since there's no way to recover from malloc returning null here, just crash.

* Platform/CoreIPC/ArgumentEncoder.cpp:
(CoreIPC::ArgumentEncoder::grow):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128792 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        https://bugs.webkit.org/show_bug.cgi?id=96942
        [Mac] Failing test http/tests/inspector/network/network-xhr-replay.html

        * platform/mac/Skipped: Skipping a test for the newly added feature.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore: Allow gesture events to set active/hover state.
https://bugs.webkit.org/show_bug.cgi?id=96060

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-17
Reviewed by Antonio Gomes.

Adds GestureTapDownCancel as a new PlatformGestureEvent type.  On ports
that support gesture events, use GestureTapDown to trigger active/hover
states, and GestureTap/GestureTapDownCancel to clear them.  This is
superior to using touch events for a number of reasons:
  1) some ports (chromium) avoid sending touch events unless absolutely
  necessary, since they hurt scroll performance by blocking threaded
  scrolling.
  2) with touch, and element really shouldn't be 'active' when the user
  happens to be touching it while scrolling.  In that case they aren't
  'manipulating the element', they're manipulating the page or div that
  is scrolling.
  3) similarly, there may be other gestures that involve touching the
  element which aren't really about manipulating that element (eg.
  pinch to zoom).

Test: fast/events/touch/gesture/gesture-tap-active-state.html
Test: fast/events/touch/gesture/gesture-tap-active-state-iframe.html
* dom/GestureEvent.cpp:
(WebCore::GestureEvent::create):
* page/EventHandler.cpp:
(WebCore::EventHandler::handleGestureEvent):
(WebCore::EventHandler::handleTouchEvent):
* platform/PlatformEvent.h:

Source/WebKit/chromium: Send GestureTapDownCancel to WebCore
https://bugs.webkit.org/show_bug.cgi?id=96060

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-17
Reviewed by Antonio Gomes.

Plumb WebInputEvent::GetsureTapCancel to
PlatformInputEvent::GestureTapDownCancel.  After all the chromium code
was landed, it was suggested that 'TapDownCancel' was a better name
than 'TapCancel' since you can't cancel a Tap.  I'm not changing the
WebInputEvent definition here because that would be a breaking change
to chromium, but I can do that as a series of follow-up CLs.
* src/WebInputEventConversion.cpp:
(WebKit::PlatformGestureEventBuilder::PlatformGestureEventBuilder):
* src/WebPopupMenuImpl.cpp:
(WebKit::WebPopupMenuImpl::handleInputEvent):
* src/WebViewImpl.cpp:
(WebKit::WebViewImpl::handleGestureEvent):

Tools: Add handling of new GestureTapCancel in DRT

https://bugs.webkit.org/show_bug.cgi?id=96183

Patch by Rick Byers <rbyers@chromium.org> on 2012-09-17
Reviewed by Antonio Gomes.

* DumpRenderTree/chromium/TestWebPlugin.cpp:
(TestWebPlugin::handleInputEvent):
* DumpRenderTree/chromium/EventSender.cpp:
(EventSender::gestureTapCancel):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128794 268f45cc-cd09-0410-ab3c-d52691b4dbfc
IndexedDB: Result of IDBFactory.deleteDatabase() should be undefined, not null
https://bugs.webkit.org/show_bug.cgi?id=96538

Reviewed by Tony Chang.

Source/WebCore:

Trivial implementation change to match the spec.

Tests: storage/indexeddb/factory-deletedatabase-expected.html
       storage/indexeddb/intversion-long-queue-expected.html

* Modules/indexeddb/IDBDatabaseBackendImpl.cpp:
(WebCore::IDBDatabaseBackendImpl::deleteDatabase):

LayoutTests:

Check result of IDBFactory.deleteDatabase() - one updated assertion, one added assertion.

* storage/indexeddb/factory-deletedatabase-expected.txt:
* storage/indexeddb/intversion-long-queue-expected.txt:
* storage/indexeddb/resources/factory-deletedatabase.js: Add new assertion.
(reopenDatabase):
* storage/indexeddb/resources/intversion-long-queue.js: Update existing assertion.
(deleteDatabaseSuccessCallback):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128795 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Implement uncommitted memory for Linux.
https://bugs.webkit.org/show_bug.cgi?id=65766

Patch by Uli Schlachter <psychon@znc.in> on 2012-09-17
Reviewed by Gavin Barraclough.

The old approach used MAP_NORESERVE to allocate address space without
committing it. However, that flag gets ignored if
/proc/sys/vm/overcommit_memory is set to 2. The new approach uses a
mapping with PROT_NONE. This works because mappings which aren't even
readable don't get accounted as committed on Linux.

* wtf/OSAllocatorPosix.cpp:
(WTF::OSAllocator::reserveUncommitted):
(WTF::OSAllocator::reserveAndCommit):
(WTF::OSAllocator::commit):
(WTF::OSAllocator::decommit):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Measure usage of the legacy WebKitBlobBuilder API in the hopes of being able to remove it
https://bugs.webkit.org/show_bug.cgi?id=96939

Reviewed by Ojan Vafai.

In the course of standardization, the BlobBuilder API was removed in
favor of just using the Blob constructor. This patch adds some
measurement to see how often this legacy API is used. If the API is not
used very much, we might be able to remove it.

* fileapi/WebKitBlobBuilder.cpp:
(WebCore::WebKitBlobBuilder::create):
* page/FeatureObserver.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128797 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Measure the usage of window.webkitIndexedDB so we can measure the transition to webkit.indexedDB
https://bugs.webkit.org/show_bug.cgi?id=96943

Reviewed by Ojan Vafai.

We don't yet support window.indexedDB but we will once
https://bugs.webkit.org/show_bug.cgi?id=96548 lands. This metric will
help us measure the transition from the prefixed to the unprefixed API.

* Modules/indexeddb/DOMWindowIndexedDatabase.idl:
* page/FeatureObserver.h:


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