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

Timestamp:

Jul 24, 2013, 8:59:31 PM (12 years ago)

Author:

[email protected]

Message:

fourthTier: Profiler should be thread-safe
​https://bugs.webkit.org/show_bug.cgi?id=115445

Reviewed by Geoffrey Garen.

Change the Profiler::Database API for Compilation creation so that we don't add
it to the Database until it's completely constructed. This prevents the Database
from seeing Compilations that are being concurrently constructed.

Change the Profiler::Database itself to do locking for creation of Bytecodes and
for modifying the map. This map may be consulted by both the main thread and the
concurrent thread.

• dfg/DFGGraph.cpp:

(JSC::DFG::Graph::Graph):

• dfg/DFGJITCompiler.cpp:

(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::linkFunction):

• jit/JIT.cpp:

(JSC::JIT::privateCompile):

• profiler/ProfilerBytecodes.h:
• profiler/ProfilerDatabase.cpp:

(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
(JSC::Profiler::Database::addCompilation):

• profiler/ProfilerDatabase.h:

(Database):

File:

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

trunk/Source/JavaScriptCore/profiler/ProfilerDatabase.h

@@ -36 +36 @@
 #include <wtf/PassRefPtr.h>
 #include <wtf/SegmentedVector.h>
+#include <wtf/ThreadingPrimitives.h>
 #include <wtf/text/WTFString.h>
 
@@ -51 +52 @@
     void notifyDestruction(CodeBlock*);
     
-    PassRefPtr<Compilation> newCompilation(CodeBlock*, CompilationKind);
-    PassRefPtr<Compilation> newCompilation(Bytecodes*, CompilationKind);
+    void addCompilation(PassRefPtr<Compilation>);
     
     // Converts the database to a JavaScript object that is suitable for JSON stringification.
@@ -71 +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();
@@ -86 +100 @@
     CString m_atExitSaveFilename;
     Database* m_nextRegisteredDatabase;
+    Lock m_lock;
 };