Changeset 199848 in webkit for trunk/Source/JavaScriptCore/runtime/CodeCache.cpp

Timestamp:

Apr 21, 2016, 5:09:36 PM (9 years ago)

Author:

[email protected]

Message:

Lets do less locking of symbol tables in the BytecodeGenerator where we don't have race conditions
​https://bugs.webkit.org/show_bug.cgi?id=156821

Reviewed by Filip Pizlo.

Source/JavaScriptCore:

The BytecodeGenerator allocates all the SymbolTables that it uses.
This is before any concurrent compiler thread can use that SymbolTable.
This means we don't actually need to lock for any operations of the
SymbolTable. This patch makes this change by removing all locking.
To do this, I've introduced a new constructor for ConcurrentJITLocker
which implies no locking is necessary. You instantiate such a ConcurrentJITLocker like so:
ConcurrentJITLocker locker(ConcurrentJITLocker::NoLockingNecessary);

This patch also removes all uses of Strong<SymbolTable> from the bytecode
generator and instead wraps bytecode generation in a DeferGC.

• bytecode/UnlinkedFunctionExecutable.cpp:

(JSC::generateUnlinkedFunctionCodeBlock):

• bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::initializeBlockScopedFunctions):
(JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):

• bytecompiler/BytecodeGenerator.h:

(JSC::BytecodeGenerator::constructorKind):
(JSC::BytecodeGenerator::superBinding):
(JSC::BytecodeGenerator::generate):

• runtime/CodeCache.cpp:

(JSC::CodeCache::getGlobalCodeBlock):

• runtime/ConcurrentJITLock.h:

(JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
(JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase):
(JSC::ConcurrentJITLocker::ConcurrentJITLocker):

Source/WTF:

This patch introduces a new constructor for Locker which implies no
locking is necessary. You instantiate such a locker like so:
Locker<Lock> locker(Locker<Lock>::NoLockingNecessary);

This is useful to for very specific places when it is not yet
required to engage in a specified locking protocol. As an example,
we use this in JSC when we allocate a particular object that
engages in a locking protocol with the concurrent compiler thread,
but before a concurrent compiler thread that could have access
to the object exists.

• wtf/Locker.h:

(WTF::Locker::Locker):
(WTF::Locker::~Locker):

File:

• trunk/Source/JavaScriptCore/runtime/CodeCache.cpp (modified) (1 diff)

trunk/Source/JavaScriptCore/runtime/CodeCache.cpp

@@ -120 +120 @@
     unlinkedCodeBlock->recordParse(rootNode->features(), rootNode->hasCapturedVariables(), rootNode->firstLine() - source.firstLine(), lineCount, unlinkedEndColumn);
 
-    auto generator = std::make_unique<BytecodeGenerator>(vm, rootNode.get(), unlinkedCodeBlock, debuggerMode, profilerMode, variablesUnderTDZ);
-    error = generator->generate();
+    error = BytecodeGenerator::generate(vm, rootNode.get(), unlinkedCodeBlock, debuggerMode, profilerMode, variablesUnderTDZ);
+
     if (error.isValid())
         return nullptr;