[Chromium] Remove unused PlatformSupport reference in DraggedIsolatedFileSystem
https://bugs.webkit.org/show_bug.cgi?id=97851

Reviewed by Kentaro Hara.

Part of a refactoring series. See tracking bug 82948.

* Modules/filesystem/chromium/DraggedIsolatedFileSystem.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129843 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CSSComputedStyleDeclaration::getPropertyCSSValue() triggering unnecessary relayouts and style recalcs
https://bugs.webkit.org/show_bug.cgi?id=97760

Reviewed by Andreas Kling.

Currently getPropertyCSSValue() (which is also used to implement the more common getPropertyValue()) 
calls Document::updateLayoutIgnorePendingStylesheets() unconditionally. However only a few properties 
are actually layout dependent, making many of these relayouts unnecessary. Moreover, triggering full 
style recalc is also often unnecessary as the current node may already have valid style even if some 
other parts of the tree require recalc.
        
- Only trigger relayouts for layout dependent properties.
- Trigger style recalc only if the style of the current element or its ancestors is dirty.
        
This is a significant (several percent) progression on some real world web content based page loading
benchmarks.

* css/CSSComputedStyleDeclaration.cpp:
(WebCore::isLayoutDependentProperty):
(WebCore):
(WebCore::CSSComputedStyleDeclaration::getPropertyCSSValue):
* css/StyleResolver.h:
(WebCore::StyleResolver::hasViewportDependentMediaQueries):
* dom/Document.cpp:
(WebCore::Document::hasPendingStyleRecalc):
        
    Renamed for consistency.

(WebCore::Document::hasPendingForcedStyleRecalc):
(WebCore):
* dom/Document.h:
(Document):
* rendering/RenderImage.cpp:
(WebCore::RenderImage::imageChanged):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129844 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Remove unused PlatformSupport reference in ChromeClientImpl
https://bugs.webkit.org/show_bug.cgi?id=97853

Reviewed by Kentaro Hara.

Part of a refactoring series. See tracking bug 82948.

* src/ChromeClientImpl.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129845 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Update comment in WebFrameClient to point to new userAgent() function
https://bugs.webkit.org/show_bug.cgi?id=97854

Reviewed by Adam Barth.

Part of a refactoring series. See tracking bug 82948.

* public/WebFrameClient.h:
(WebFrameClient):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129846 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove unused features and reduce code duplications in PerfTestRunner
https://bugs.webkit.org/show_bug.cgi?id=97852

Reviewed by Kentaro Hara.

Made the following refactoring changes:
- Remove PerfTestRunner.info since it's never used.
- Moved the js heap/malloc related functions up to where they belong.
- Moved the initialization of _callsPerIteration, _test, and -description into _start,
  and stopped initializing _runFunction and _doneFunction since both test times now
  use _test object.
- Made _measureTimeOnce and _measureRunsPerSecondOnce return the measured value
  instead of calling ignoreWarmUpAndLog and _runLoop to share the code; they're now
  called in _measureRunsPerSecondOnce.

* resources/runner.js:
(PerfTestRunner.storeHeapResults): Moved.
(PerfTestRunner.getUsedMallocHeap): Moved.
(PerfTestRunner.getUsedJSHeap): Moved.
(PerfTestRunner.getAndPrintMemoryStatistics): Moved.
(PerfTestRunner._scheduleNextMeasurementOrNotifyDone): Renamed from _runLoop. Calls
ignoreWarmUpAndLog and schedules the next call.
(PerfTestRunner._measureTimeOnce): Renamed from _runner.
(PerfTestRunner._start): Renamed from initAndStartLoop.
(PerfTestRunner.measureTime):
(PerfTestRunner.runPerSecond):
(PerfTestRunner._measureRunsPerSecondOnce): Renamed from _measureRunsPerSecondOnce.
(PerfTestRunner._perSecondRunnerIterator):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129847 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Build fix after r129824.

* DOM/resources/dom-perf.js:
(runBenchmarkSuite):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@129848 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[V8] StringCache::v8ExternalString() can return a stale persistent handle
https://bugs.webkit.org/show_bug.cgi?id=97767

Reviewed by Adam Barth.

For details, see the Chromium bug: http://code.google.com/p/chromium/issues/detail?id=151902

StringCache::v8ExternalString() can return a stale persistent handle
in the following scenario:

(1) Assume that StringImpl A with value "foo" is in m_stringCache.
(2) StringImpl B with value "foo" is accessed. At this point, m_lastStringImpl
points to B, and m_lastV8String points to B's handle.
(3) A minor GC is triggered and a weak callback is called back for StringImpl A.
At this point, "foo" is removed from m_stringCache. A's handle is disposed.
However, m_lastV8String is not cleared because m_lastStringImpl (i.e. StringImpl B)
is not equal to StringImpl A. As a result, m_lastV8String points to a stale
persistent handle.
(4) The persistent handle is eventually reused in V8 and made weak again.
(5) StringImpl B with value "foo" is accessed. Then StringCache::v8ExternalString()
returns the stale persistent handle, which is already used for another purpose.

To solve the problem, we need to clear m_stringImpl and m_lastV8String when any
string wrapper is disposed. Specifically, we need to change the code like this:

  static void cachedStringCallback(v8::Persistent<v8::Value> wrapper, void* parameter)
  {
    StringImpl* stringImpl = static_cast<StringImpl*>(parameter);
    V8PerIsolateData::current()->stringCache()->remove(stringImpl);
    wrapper.Dispose();
    stringImpl->deref();
  }

  void StringCache::remove(StringImpl* stringImpl)
  {
    m_stringCache.remove(stringImpl);
    if (m_lastStringImpl.get() == stringImpl) {  // Remove this line.
        m_lastStringImpl = 0;
        m_lastV8String.Clear();
    }
  }

Note: Removing the line might be stronger than is needed. Instead of removing
the line, we can just replace the line with 'if (m_lastV8String == wrapper)'.
However, just in case (for correctness), I'd prefer removing the line.
Given that GC won't happen so frequently, clearing the cache in every weak callback
won't affect performance.

No tests because it depends on the GC behavior and I couldn't reproduce the bug.

* bindings/v8/V8ValueCache.cpp:
(WebCore::StringCache::remove):


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