Changeset 36843 in webkit for trunk/JavaScriptCore/VM/Machine.h

Timestamp:

Sep 24, 2008, 12:32:23 AM (17 years ago)

Author:

[email protected]

Message:

Bug 19968: Slow Script at www.huffingtonpost.com
<​https://bugs.webkit.org/show_bug.cgi?id=19968>

Reviewed by Maciej Stachowiak

Finally found the cause of this accursed issue. It is triggered
by synchronous creation of a new global object from JS. The new
global object resets the timer state in this execution group's
Machine, taking timerCheckCount to 0. Then when JS returns the
timerCheckCount is decremented making it non-zero. The next time
we execute JS we will start the timeout counter, however the non-zero
timeoutCheckCount means we don't reset the timer information. This
means that the timeout check is now checking the cumulative time
since the creation of the global object rather than the time since
JS was last entered. At this point the slow script dialog is guaranteed
to eventually be displayed incorrectly unless a page is loaded
asynchronously (which will reset everything into a sane state).

The fix for this is rather trivial -- the JSGlobalObject constructor
should not be resetting the machine timer state.

File:

• trunk/JavaScriptCore/VM/Machine.h (modified) (2 diffs)

trunk/JavaScriptCore/VM/Machine.h

@@ -110 +110 @@
         void stopTimeoutCheck()
         {
+            ASSERT(m_timeoutCheckCount);
             --m_timeoutCheckCount;
         }
@@ -115 +116 @@
         inline void initTimeout()
         {
+            ASSERT(!m_timeoutCheckCount);
             resetTimeoutCheck();
             m_timeoutTime = 0;