From a4e969f4965059196ca948db781e52f7cfebf19e Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 24 May 2016 08:28:08 +0000 Subject: webkitgtk-2.12.3 --- Source/JavaScriptCore/profiler/ProfilerDatabase.h | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) (limited to 'Source/JavaScriptCore/profiler/ProfilerDatabase.h') 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 #include +#include #include #include #include @@ -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; -- cgit v1.2.1