1 files changed, 1 insertions, 15 deletions
diff --git a/Source/JavaScriptCore/profiler/ProfilerDatabase.h b/Source/JavaScriptCore/profiler/ProfilerDatabase.h
index 7d4f3cf2c..9bb64cf49 100644
--- a/Source/JavaScriptCore/profiler/ProfilerDatabase.h
+++ b/Source/JavaScriptCore/profiler/ProfilerDatabase.h
@@ -32,6 +32,7 @@
 #include "ProfilerCompilationKind.h"
 #include <wtf/FastMalloc.h>
 #include <wtf/HashMap.h>
+#include <wtf/Lock.h>
 #include <wtf/Noncopyable.h>
 #include <wtf/PassRefPtr.h>
 #include <wtf/SegmentedVector.h>
@@ -70,21 +71,6 @@ public:
     void registerToSaveAtExit(const char* filename);
     
 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();
     void performAtExitSave() const;