Changeset 188475 in webkit for trunk/Source/JavaScriptCore/profiler/ProfilerDatabase.h

Timestamp:

Aug 14, 2015, 9:53:37 AM (10 years ago)

Author:

[email protected]

Message:

Unreviewed, rolling out r188444.
​https://bugs.webkit.org/show_bug.cgi?id=148029

Broke GTK and EFL (see bug #148027) (Requested by philn on
#webkit).

Reverted changeset:

"Use WTF::Lock and WTF::Condition instead of WTF::Mutex,
WTF::ThreadCondition, std::mutex, and std::condition_variable"
​https://bugs.webkit.org/show_bug.cgi?id=147999
​http://trac.webkit.org/changeset/188444

File:

• trunk/Source/JavaScriptCore/profiler/ProfilerDatabase.h (modified) (2 diffs)

trunk/Source/JavaScriptCore/profiler/ProfilerDatabase.h

@@ -33 +33 @@
 #include <wtf/FastMalloc.h>
 #include <wtf/HashMap.h>
-#include <wtf/Lock.h>
 #include <wtf/Noncopyable.h>
 #include <wtf/PassRefPtr.h>
@@ -72 +71 @@
     
 private:
+    // Use a full-blown adaptive mutex because:
+    // - There is only one ProfilerDatabase per VM. The size overhead of the system's
+    //   mutex is negligible if you only have one of them.
+    // - It's locked infrequently - once per bytecode generation, compilation, and
+    //   code block collection - so the fact that the fast path still requires a
+    //   function call is neglible.
+    // - It tends to be held for a while. Currently, we hold it while generating
+    //   Profiler::Bytecodes for a CodeBlock. That's uncommon and shouldn't affect
+    //   performance, but if we did have contention, we would want a sensible,
+    //   power-aware backoff. An adaptive mutex will do this as a matter of course,
+    //   but a spinlock won't.
+    typedef Mutex Lock;
+    typedef MutexLocker Locker;
+    
+
     void addDatabaseToAtExit();
     void removeDatabaseFromAtExit();