- 24 Jul, 2013 40 commits
-
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115582 Reviewed by Geoffrey Garen. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ByteCodeParser): (ByteCodeParser): (JSC::DFG::parse): * dfg/DFGByteCodeParser.h: (DFG): * dfg/DFGDriver.cpp: (JSC::DFG::compile): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
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): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153143 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115300 Source/JavaScriptCore: Reviewed by Geoffrey Garen. Change any code transitively called from DFG compilation to use StringImpl* directly instead of String, Identifier, or PropertyName. I use the convention of passing "StringImpl* uid" instead of an Identifier or PropertyName. Switch over any code transitively called from DFG compilation to use CStrings whenever possible for all of its debug dumping. This makes it possible to compile things without hitting the ref/deref assertion in StringImpl. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::inferredName): (JSC::CodeBlock::sourceCodeForTools): (JSC::CodeBlock::sourceCodeOnOneLine): (JSC::constantName): (JSC::idName): (JSC::CodeBlock::registerName): (JSC::regexpToSourceString): (JSC::regexpName): (JSC::pointerToSourceString): (JSC::CodeBlock::printUnaryOp): (JSC::CodeBlock::printBinaryOp): (JSC::CodeBlock::printConditionalJump): (JSC::CodeBlock::printGetByIdOp): (JSC::dumpStructure): (JSC::CodeBlock::printCallOp): (JSC::CodeBlock::printPutByIdOp): (JSC::CodeBlock::printStructure): (JSC::CodeBlock::printStructures): (JSC::CodeBlock::dumpBytecode): * bytecode/CodeBlock.h: (CodeBlock): * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): * bytecode/CodeOrigin.cpp: (JSC::InlineCallFrame::inferredName): * bytecode/CodeOrigin.h: (InlineCallFrame): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/GetByIdStatus.h: (JSC): (GetByIdStatus): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * bytecode/PutByIdStatus.h: (JSC): (PutByIdStatus): * bytecode/ReduceWhitespace.cpp: (JSC::reduceWhitespace): * bytecode/ReduceWhitespace.h: (JSC): * bytecode/ResolveGlobalStatus.cpp: (JSC::computeForStructure): (JSC::ResolveGlobalStatus::computeFor): * bytecode/ResolveGlobalStatus.h: (JSC): (ResolveGlobalStatus): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): * dfg/DFGByteCodeParser.cpp: (ByteCodeParser): (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDesiredIdentifiers.cpp: Added. (DFG): (JSC::DFG::DesiredIdentifiers::DesiredIdentifiers): (JSC::DFG::DesiredIdentifiers::~DesiredIdentifiers): (JSC::DFG::DesiredIdentifiers::addLazily): (JSC::DFG::DesiredIdentifiers::reallyAdd): * dfg/DFGDesiredIdentifiers.h: Added. (DFG): (DesiredIdentifiers): (JSC::DFG::DesiredIdentifiers::numberOfIdentifiers): (JSC::DFG::DesiredIdentifiers::at): (JSC::DFG::DesiredIdentifiers::operator[]): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (Graph): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGRepatch.cpp: (JSC::DFG::tryBuildGetByIDList): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::identifierUID): (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compile): * parser/SourceCode.cpp: Added. (JSC): (JSC::SourceCode::toUTF8): * parser/SourceCode.h: (SourceCode): * profiler/ProfilerBytecodes.cpp: (JSC::Profiler::Bytecodes::toJS): * profiler/ProfilerBytecodes.h: (JSC::Profiler::Bytecodes::inferredName): (JSC::Profiler::Bytecodes::sourceCode): (Bytecodes): * runtime/Identifier.h: (JSC::Identifier::utf8): (JSC): * runtime/Structure.cpp: (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addPropertyTransitionToExistingStructure): (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): (JSC::Structure::getConcurrently): (JSC::Structure::prototypeChainMayInterceptStoreTo): (JSC): * runtime/Structure.h: (Structure): * runtime/StructureInlines.h: (JSC::Structure::getConcurrently): Source/WTF: Reviewed by Geoffrey Garen. Make it possible to do more things directly to StringImpl*'s, including being able to directly do utf8 conversion on a substring without creating the substring first. Add assertions to StringImpl that it isn't being ref/deref'd from the compilation thread. * wtf/PrintStream.cpp: (WTF::printInternal): (WTF): * wtf/PrintStream.h: (WTF): (WTF::printInternal): * wtf/StringPrintStream.h: (WTF): (WTF::toCString): * wtf/text/StringImpl.cpp: (WTF::StringImpl::utf8ForRange): (WTF::StringImpl::utf8): (WTF): * wtf/text/StringImpl.h: (StringImpl): (WTF::StringImpl::hasAtLeastOneRef): (WTF::StringImpl::ref): (WTF::StringImpl::deref): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153142 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115525 Reviewed by Geoffrey Garen. The structure transition table basically maps string to structure. The string is always also stored, and ref'd, in the structure in Structure::m_nameInPrevious. m_nameInPrevious is never mutated, and never cleared. The string cannot die unless the structure dies. If the structure dies, then that entry in the transition map becomes a zombie anyway and we will detect this separately. So, we don't need to use RefPtr<StringImpl>. We can just use StringImpl*. This also fixes a goof where we were getting the StringImpl's hash rather than using a pointer hash. Not only is the latter faster, but it prevents my change from leading to crashes: with my change we can have zombie keys, not just zombie values. They will exist only until the next map mutation, which will clear them. Lookups will work fine because the lookup routine will reject zombies. But it does mean that the HashMap will have to deal with dangling StringImpl*'s; all it takes to make this work is to ensure that the HashMap itself never dereferences them. Using a pointer hash rather than StringImpl::existingHash() accomplishes this. This also ensures that we don't accidentally call ref() or deref() from the compilation thread, if the compilation thread inspects the transition table. And no, we wouldn't have been able to use the HashMap<RefPtr<...>, ...> specialization, because the transition table is actually HashMap<pair<RefPtr<StringImpl>, unsigned>, ...>: hence that specialization doesn't kick in. We could have written a new specialization or something, but that seemed like a lot of work given that we don't need the table to be ref'ing the strings anyways. * runtime/Structure.cpp: (JSC::StructureTransitionTable::add): * runtime/StructureTransitionTable.h: (StructureTransitionTable): (Hash): (JSC::StructureTransitionTable::Hash::hash): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153141 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115468 Reviewed by Geoffrey Garen. This makes the main thread modify the transition table while holding a lock. Note that the GC might modify its weak pointers without locking, but the GC will lock out the compilation thread anyway. The map will then only reshape in response to add() and set(), which happen while holding a lock. This allows the compilation thread to now query transition tables safely, provided it holds a lock when doing so. Also changed LLVM asm printer initialization to just initialize the X86 one. It makes sense for us to just initialize the asm printer(s) that we actually use; you could imagine us being linked to a system LLVM that has cross-compilation support; there is no point in the WebKit or JSC process doing work to initialize all of those targets. That part was rubber stamped by Mark Hahnenberg. * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): * runtime/Structure.cpp: (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addPropertyTransitionToExistingStructure): (JSC): (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): (JSC::Structure::addPropertyTransition): (JSC::Structure::nonPropertyTransition): * runtime/Structure.h: (Structure): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153140 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: Structure::getConcurrently() may be called from for uncacheable dictionaries, and this is safe https://bugs.webkit.org/show_bug.cgi?id=115464 Reviewed by Oliver Hunt and Geoffrey Garen. This can happen for example transitively from JSObject::put(). getCurrently() does work for uncacheable dictionaries; it just has the obvious race that right after it returns, the result it returned may no longer be right. This isn't an issue if it was called on the main thread, and may not be an issue in some other situations. So, we should just remove the assertion, since the only thing it buys us is crashes. * runtime/Structure.cpp: (JSC::Structure::getConcurrently): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153139 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
Rubber stamped by Mark Rowe. * Scripts/copy-webkitlibraries-to-product-directory: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153138 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
Rubber stamped by Mark Rowe. * Configurations/JavaScriptCore.xcconfig: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153137 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
Rubber stamped by Mark Hahnenberg. * LLVMIncludesMountainLion.tar.bz2: * LLVMLibrariesMountainLion.tar.bz2: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153136 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: String::utf8() should also be available as StringImpl::utf8() so that you don't have to ref() a StringImpl just to get its utf8() https://bugs.webkit.org/show_bug.cgi?id=115393 Reviewed by Geoffrey Garen. Source/JavaScriptCore: * runtime/JSGlobalObjectFunctions.cpp: (JSC::encode): Source/WebCore: No new tests because no new behavior. * Modules/websockets/WebSocket.cpp: (WebCore::WebSocket::close): * Modules/websockets/WebSocketChannel.cpp: (WebCore::WebSocketChannel::send): * html/MediaFragmentURIParser.cpp: (WebCore::MediaFragmentURIParser::parseFragments): Source/WTF: * WTF.xcodeproj/project.pbxproj: * wtf/text/ConversionMode.h: Added. (WTF): * wtf/text/StringImpl.cpp: (WTF): (WTF::putUTF8Triple): (WTF::StringImpl::utf8): * wtf/text/StringImpl.h: (StringImpl): * wtf/text/WTFString.cpp: (WTF): (WTF::String::utf8): * wtf/text/WTFString.h: (String): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153135 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime are not being called during compilation https://bugs.webkit.org/show_bug.cgi?id=115297 Source/JavaScriptCore: Reviewed by Geoffrey Garen. Put in assertions that we're not doing bad things in compilation threads. Also factored compilation into compile+link so that even though we don't yet have concurrent compilation, we can be explicit about which parts of DFG work are meant to be concurrent, and which aren't. Also fix a handful of bugs found by these assertions. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ResolveGlobalStatus.cpp: (JSC::computeForStructure): * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::add): (JSC::InlineWatchpointSet::inflateSlow): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::~JITCompiler): (DFG): (JSC::DFG::JITCompiler::compileBody): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::linkFunction): * dfg/DFGJITCompiler.h: (JITCompiler): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLCompile.h: (FTL): * ftl/FTLLink.cpp: Added. (FTL): (JSC::FTL::compileEntry): (JSC::FTL::link): * ftl/FTLLink.h: Added. (FTL): * ftl/FTLState.cpp: (JSC::FTL::State::State): * ftl/FTLState.h: (FTL): (State): * runtime/Structure.cpp: (JSC::Structure::get): (JSC::Structure::prototypeChainMayInterceptStoreTo): * runtime/Structure.h: (JSC::Structure::materializePropertyMapIfNecessary): * runtime/StructureInlines.h: (JSC::Structure::get): Source/WTF: Reviewed by Geoffrey Garen. Taught WTF the notion of compilation threads. This allows all parts of our stack to assert that we're not being called from a JSC compilation thread. This is in WTF because it will probably end up being used in StringImpl and WTFString. * WTF.xcodeproj/project.pbxproj: * wtf/CompilationThread.cpp: Added. (WTF): (WTF::initializeCompilationThreadsOnce): (WTF::initializeCompilationThreads): (WTF::isCompilationThread): (WTF::exchangeIsCompilationThread): * wtf/CompilationThread.h: Added. (WTF): (CompilationScope): (WTF::CompilationScope::CompilationScope): (WTF::CompilationScope::~CompilationScope): (WTF::CompilationScope::leaveEarly): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153134 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=113624 Reviewed by Geoffrey Garen. Made all of the operations that the FTL already supports, also support doubles. OSR exit already basically had everything it needed, so no changes there. This mostly just glues together bits of DFG IR to LLVM IR, in a straight-forward way. * ftl/FTLAbbreviations.h: (FTL): (JSC::FTL::doubleType): (JSC::FTL::constReal): (JSC::FTL::buildPhi): (JSC::FTL::addIncoming): (JSC::FTL::buildFAdd): (JSC::FTL::buildFSub): (JSC::FTL::buildFMul): (JSC::FTL::buildFNeg): (JSC::FTL::buildSIToFP): (JSC::FTL::buildUIToFP): (JSC::FTL::buildBitCast): (JSC::FTL::buildFCmp): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCommonValues.cpp: (JSC::FTL::CommonValues::CommonValues): * ftl/FTLCommonValues.h: (CommonValues): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileGetLocal): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileAdd): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::lowDouble): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::isCellOrMisc): (JSC::FTL::LowerDFGToLLVM::unboxDouble): (JSC::FTL::LowerDFGToLLVM::boxDouble): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::speculateNumber): (JSC::FTL::LowerDFGToLLVM::speculateRealNumber): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): * ftl/FTLOutput.h: (JSC::FTL::Output::constDouble): (Output): (JSC::FTL::Output::phi): (JSC::FTL::Output::doubleAdd): (JSC::FTL::Output::doubleSub): (JSC::FTL::Output::doubleMul): (JSC::FTL::Output::doubleNeg): (JSC::FTL::Output::intToFP): (JSC::FTL::Output::intToDouble): (JSC::FTL::Output::unsignedToFP): (JSC::FTL::Output::unsignedToDouble): (JSC::FTL::Output::bitCast): (JSC::FTL::Output::loadDouble): (JSC::FTL::Output::storeDouble): (JSC::FTL::Output::doubleEqual): (JSC::FTL::Output::doubleNotEqualOrUnordered): (JSC::FTL::Output::doubleLessThan): (JSC::FTL::Output::doubleLessThanOrEqual): (JSC::FTL::Output::doubleGreaterThan): (JSC::FTL::Output::doubleGreaterThanOrEqual): (JSC::FTL::Output::doubleEqualOrUnordered): (JSC::FTL::Output::doubleNotEqual): (JSC::FTL::Output::doubleLessThanOrUnordered): (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): (JSC::FTL::Output::testIsZero64): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153133 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115301 Reviewed by Geoffrey Garen. Makes SymbolTable thread-safe. Relies on SymbolTableEntry already being immutable, other than the WatchpointSet; but the WatchpointSet already has a righteous concurrency protocol. So, this patch just protects the SymbolTable's HashMap. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::nameForRegister): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): * runtime/Executable.cpp: (JSC::ProgramExecutable::addGlobalVar): * runtime/JSActivation.cpp: (JSC::JSActivation::getOwnNonIndexPropertyNames): (JSC::JSActivation::symbolTablePutWithAttributes): * runtime/JSSymbolTableObject.cpp: (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): (JSC::SymbolTable::~SymbolTable): * runtime/SymbolTable.h: (JSC::SymbolTable::find): (JSC::SymbolTable::get): (JSC::SymbolTable::inlineGet): (JSC::SymbolTable::begin): (JSC::SymbolTable::end): (JSC::SymbolTable::size): (JSC::SymbolTable::add): (JSC::SymbolTable::set): (JSC::SymbolTable::contains): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153132 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=115299 Reviewed by Anders Carlsson. The compiler often does things like: 1c) Observe something that would imply that a WatchpointSet ought to be invalid 2c) Check that it is invalid The main thread often does things like: 1m) Fire the watchpoint set 2m) Do some other thing that would cause the compiler to assume that the WatchpointSet ought to be invalid An example is structure transitions, where (1c) is the compiler noticing that a put_by_id inline cache is in a transition state, with the source structure being S; (2c) is the compiler asserting that S's watchpoint set is invalid; (1m) is the main thread firing S's watchpoint set before it does the first transition away from S; and (2m) is the main thread caching the put_by_id transition away from S. This is totally fine, except that (1c) and (2c), and (1m) and (2m) could be reordered. Probably, in most cases, this ought to do enough things that the main thread probably already has some fencing. But the compiler thread definitely doesn't have fencing. In any case, we should play it safe and just have additional fencing in all of the relevant places. We already have some idioms to put load-load and store-store fences in the right places. But this change just makes WatchpointSet take care of this for us, thus reducing the chances of us getting this wrong. * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::notifyWriteSlow): * bytecode/Watchpoint.h: (WatchpointSet): (JSC::WatchpointSet::isStillValid): (JSC::WatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::notifyWrite): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153131 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: CFA should defend against results seeming inconsistent due to a watchpoint firing during compilation https://bugs.webkit.org/show_bug.cgi?id=115083 Reviewed by Geoffrey Garen. This ruggedizes our racyness with respect to watchpoints. We want to be able to assert, in some places, that a watchpoint-based optimization has only occurred if the watchpoint set was still valid. But currently we *can* soundly do watchpoint-based optimizations even for invalid watchpoints, so long as we recorded in the IR that we had done so; this will then lead to the code being insta-jettisoned after compilation completes. Obviously, we don't want this to happen often - but we do want to allow it precisely in the case of watchpoint races. This adds the ability to assert that we hadn't over-watchpointed ourselves, with and exemption for races. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::setFuturePossibleStructure): (JSC::DFG::AbstractValue::filterFuturePossibleStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): * dfg/DFGDesiredWatchpoints.h: (GenericDesiredWatchpoints): (JSC::DFG::GenericDesiredWatchpoints::isStillValid): (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::GenericDesiredWatchpoints::isValidOrMixed): (JSC::DFG::DesiredWatchpoints::isStillValid): (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isValidOrMixed): (DesiredWatchpoints): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): * dfg/DFGGraph.h: (JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid): (Graph): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addLazily): (JITCompiler): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid): (JSC::DFG::SpeculativeJIT::speculationWatchpointForMasqueradesAsUndefined): (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLState.h: (State): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153130 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: AbstractValue methods that deal with watchpoints should have access to Graph, so that in debug mode, Graph can track the history of watchpoint states and detect races https://bugs.webkit.org/show_bug.cgi?id=115084 Reviewed by Geoffrey Garen. The idea is that as part of https://bugs.webkit.org/show_bug.cgi?id=115083, I'll have Graph record the initial state of a watchpoint at the time that we decide to take advantage of it; then I will use this to disable any watchpoint-related assertions in debug mode. Note that this "watchpoint cache" will only be maintained in debug mode, so there will be no release performance implications. But to do this, I need to ensure that all of the places that reason about watchpoints have access to Graph. For example, I'll want AbstractValue::setFuturePossibleStructure to record the state of the watchpoint in Graph so that subsequent assertions can check if the watchpoint's state had changed since that decision was made. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::initialize): (JSC::DFG::AbstractState::executeEffects): (JSC::DFG::AbstractState::mergeStateAtTail): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::trySetConstant): * dfg/DFGAbstractValue.cpp: Added. (DFG): (JSC::DFG::AbstractValue::setMostSpecific): (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::filter): (JSC::DFG::AbstractValue::setFuturePossibleStructure): (JSC::DFG::AbstractValue::filterFuturePossibleStructure): (JSC::DFG::AbstractValue::dump): * dfg/DFGAbstractValue.h: (DFG): (AbstractValue): (JSC::DFG::AbstractValue::setType): (JSC::DFG::AbstractValue::filterByValue): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153129 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114987 Reviewed by Geoffrey Garen. This completes the work started by r148570. That patch made it possible to do Structure::get() without modifying Structure. This patch takes this further, and makes this thread-safe (for non-uncacheable-dictionaries) via Structure::getConcurrently(). This method not only doesn't modify Structure, but also ensures that any concurrent attempts to add to, remove from, or steal the table from that structure doesn't mess up the result of the call. The call may return invalidOffset even if a property is *just* about to be added, but it will never do the reverse: if it returns a property then you can be sure that the structure really does have that property and always will have it. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): * runtime/PropertyMapHashTable.h: (PropertyTable): (JSC::PropertyTable::findConcurrently): (JSC): (JSC::PropertyTable::add): (JSC::PropertyTable::remove): (JSC::PropertyTable::reinsert): (JSC::PropertyTable::rehash): * runtime/PropertyTable.cpp: (JSC::PropertyTable::PropertyTable): * runtime/Structure.cpp: (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::getConcurrently): * runtime/Structure.h: (Structure): * runtime/StructureInlines.h: (JSC::Structure::getConcurrently): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153128 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114933 Reviewed by Andy Estes. This makes it easy to get set up for tandem LLVM builds. * Scripts/copy-webkitlibraries-to-product-directory: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153127 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: WebKit's build system should relink JavaScriptCore if LLVM's libraries changed but its headers didn't https://bugs.webkit.org/show_bug.cgi?id=114926 Source/JavaScriptCore: Reviewed by Geoffrey Garen. Use a phony file that includes a phony header to force JavaScriptCore to be relinked if necessary. The external LLVM-importing scripts will touch the header if the libraries are known to have changed. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/WebKitLLVMLibraryAnchor.cpp: Added. Tools: Reviewed by Geoffrey Garen. If the LLVM libraries change, then touch a phony header, which will force relink of JavaScriptCore. * Scripts/copy-webkitlibraries-to-product-directory: (unpackIfNecessary): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153126 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114925 Reviewed by Geoffrey Garen. This enables building LLVM along with WebKit, so that build-jsc and build-webkit will also optionally build LLVM and quickly symlink LLVM's built products into the right places. Most WebKit and JSC hackers will want to rely on the checked-in already-built versions of LLVM in WebKitLibraries. But developing both systems in tandem is an increasingly common use-case for me, and it may become a common use case for a handful of others. Currently, this is really painful: you first have to build LLVM, then you have to export-llvm-build (which takes a while), and then you have to make sure that your LLVM_LIBRARY_PACKAGE and LLVM_INCLUDE_PACKAGE variables are set to point to the thing you exported. The whole process loses track of dependencies very quickly: making a tiny change in LLVM requires packaging, and then unpackaging, a large number of potentially large headers and static libraries. Not only is this slow but it then causes the WebKit build system to rebuild anything that transitively includes any LLVM header, which is now quite a few files. While this sort of use pattern is still worthwhile if you're trying to package a binary drop and test it, it's not great if you're just trying to do experimental development that involves making small changes in both trees. This change fixes this use case while keeping the old use cases intact. You can do tandem development using one of two modes: Your own LLVM directory: just set LLVM_SOURCE_PATH to the *absolute* path of the LLVM directory you're using. Once this is done, any invocation of a WebKit build via build-jsc or build-webkit will also build LLVM, and then quickly symlink things into place without perturbing dependency tracking. Internal LLVM directory: if you check out llvm into a directory called 'llvm' right off of the WebKit source tree, then the build system will automatically use this. Here's how this takes care of dependencies: Headers: the include/llvm and include/llvm-c directories are symlinked into $productsDir/usr/local/include. And then everything just works. Libraries: the build system detects, by reading LLVM's Makefile.config, which mode LLVM is built in (like Release+Asserts or Debug+Asserts) and symlinks the .a files into $productsDir/<thingy>. It will ranlib those libraries only if they have changed, by checking both the modification time and also whether the last time we had a symlink, that symlink was from the same directory. This helps if you switch to an *older* LLVM build (using LLVM_SOURCE_PATH) but that build wasn't yet ranlib'd. One problem that this does not yet solve is that xcodebuild will not relink JavaScriptCore if the only thing that changed was the libraries. I will work on this problem separately: https://bugs.webkit.org/show_bug.cgi?id=114926. * Scripts/copy-webkitlibraries-to-product-directory: (unpackIfNecessary): (fileContains): (fileContentsEquals): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153125 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: It should be possible to query WatchpointSets, and add Watchpoints, even if the compiler is running in another thread https://bugs.webkit.org/show_bug.cgi?id=114909 Source/JavaScriptCore: Reviewed by Oliver Hunt. The idea here is that a concurrent compiler will use watchpoint sets as follows: During concurrent compilation: It will create Watchpoints, and query WatchpointSets only for the purpose of profiling. That is, it will use decide whether it is profitable to compile the code "as if" the watchpoint sets are valid. During synchronous linking: By "linking" I don't necessarily mean the LinkBuffer stuff, but just the very bitter end of compilation where we make the JIT code callable. This can happen after LinkBuffer stuff. Anyway, this will have to happen synchronously, and at that point we can (a) check that all WatchpointSets that we assumed were valid are still valid and (b) if they are then we add the watchpoints to those sets. If any of the sets are invalid, we give up on this compilation and try again later. The querying of WatchpointSets is engineered to say that the set is still valid if it is so *right now*, but this is done in a racy way and so it may say so spuriously: we may, with hopefully low probability, have a set that says it is valid even though it was just invalidated. The goal is only to ensure that (i) a set never claims to be invalid if it is actually valid, (ii) a set doesn't claim to be valid if it was invalidated before compilation even began, and (iii) querying the validity of a set doesn't cause us to crash. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Watchpoint.cpp: (JSC::InlineWatchpointSet::inflateSlow): * bytecode/Watchpoint.h: (WatchpointSet): (InlineWatchpointSet): (JSC::InlineWatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::isThin): (JSC::InlineWatchpointSet::isFat): (JSC::InlineWatchpointSet::fat): * dfg/DFGDesiredWatchpoints.cpp: Added. (DFG): (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints): (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints): (JSC::DFG::DesiredWatchpoints::addLazily): (JSC::DFG::DesiredWatchpoints::reallyAdd): (JSC::DFG::DesiredWatchpoints::areStillValid): * dfg/DFGDesiredWatchpoints.h: Added. (DFG): (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet): (WatchpointForGenericWatchpointSet): (GenericDesiredWatchpoints): (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints): (JSC::DFG::GenericDesiredWatchpoints::addLazily): (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): (JSC::DFG::GenericDesiredWatchpoints::areStillValid): (DesiredWatchpoints): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addLazily): (JITCompiler): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLCompile.h: (FTL): * ftl/FTLState.h: (State): * runtime/JSFunction.h: (JSFunction): (JSC::JSFunction::allocationProfileWatchpointSet): * runtime/Structure.h: (Structure): (JSC::Structure::transitionWatchpointSet): Source/WTF: Reviewed by Oliver Hunt. Harden our notions of memory fences, now that we're doing racy algorithms. * wtf/Atomics.h: (WTF): (WTF::compilerFence): (WTF::armV7_dmb): (WTF::armV7_dmb_st): (WTF::loadLoadFence): (WTF::loadStoreFence): (WTF::storeLoadFence): (WTF::storeStoreFence): (WTF::memoryBarrierAfterLock): (WTF::memoryBarrierBeforeUnlock): (WTF::x86_mfence): Conflicts: Source/WTF/wtf/Atomics.h git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153124 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread https://bugs.webkit.org/show_bug.cgi?id=114906 Source/JavaScriptCore: Reviewed by Oliver Hunt. This introduces thread safety to value profiles, array profiles, and array allocation profiles. We already have three separate operations that happen on profiles: (1) writing, which the JIT, LLInt, and OSR exit do; (2) updating, which happens during GC, from OSR entry slow-paths, and in the DFG; and (3) reading, which happens in the DFG. For example, the JIT/LLInt and OSR exit write to ValueProfile::m_buckets, which gets synthesized into ValueProfile::m_prediction (and other fields) during update, and the latter gets read by the DFG. Note that (2) must also happen in the DFG since only the DFG knows which code blocks it will inline, and those blocks' profiles may not have otherwise been updated via any other mechanism. I refer to these three operations as writing, updating, and reading. Consequently, both profile updating and profile reading may happen asynchronously, if the JIT is asynchronous. The locking protocol for profiles works as follows: - Writing does not require locking, but is only allowed on the main thread. We require that these fields can be stored atomically by the profiling code, even without locks. For value profiles, this only works on 64-bit platforms, currently. For array profiles, which consist of multiple separate fields, this means that an asynchronous update of the profile may see slight inconsistencies (like a structure that doesn't quite match the array modes bits), but these should be harmless: at worst, the DFG will specialize too much and we'll have OSR exits. - Updating a value profile requires holding a lock, but must assume that the fields written by the profiling code in JIT/LLInt may be written to without locking. - Reading a value profile requires holding a lock. The one major exception to these rules is the ArrayAllocationProfile, which requires no locking. We do this because it's used so often and in places where we don't necessarily have access to the owning CodeBlock, so if we did want it to be locked it would have to have its own lock. Also, I believe that it is sound to just make this profile racy and not worry about locking at all. All that was needed were some changes to ensure that we explicitly read some raced-over fields only once. Two additional interesting things in this change: - To make it easy to see which profile methods require locking, they take a const CodeBlockLocker& as an argument. I saw this idiom for identifying which methods require which locks to be held being used in LLVM, and I quite like it. - Lazy operand value profiles, which are created lazily and at any time, require the CodeBlockLock to be held when they are being created. Writes to them are lockless and main-thread-only, but as with other profiles, updates and reads require locking. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ArrayAllocationProfile.cpp: (JSC::ArrayAllocationProfile::updateIndexingType): * bytecode/ArrayAllocationProfile.h: (JSC::ArrayAllocationProfile::selectIndexingType): * bytecode/ArrayProfile.cpp: (JSC::ArrayProfile::computeUpdatedPrediction): (JSC::ArrayProfile::briefDescription): * bytecode/ArrayProfile.h: (ArrayProfile): (JSC::ArrayProfile::expectedStructure): (JSC::ArrayProfile::structureIsPolymorphic): (JSC::ArrayProfile::hasDefiniteStructure): (JSC::ArrayProfile::observedArrayModes): (JSC::ArrayProfile::mayInterceptIndexedAccesses): (JSC::ArrayProfile::mayStoreToHole): (JSC::ArrayProfile::outOfBounds): (JSC::ArrayProfile::usesOriginalArrayStructures): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpValueProfiling): (JSC::CodeBlock::dumpArrayProfiling): (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::updateAllArrayPredictions): * bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): (JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow): (CodeBlock): * bytecode/CodeBlockLock.h: Added. (JSC): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/LazyOperandValueProfile.cpp: (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): (JSC::CompressedLazyOperandValueProfileHolder::add): (JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser): (JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser): (JSC): (JSC::LazyOperandValueProfileParser::initialize): (JSC::LazyOperandValueProfileParser::prediction): * bytecode/LazyOperandValueProfile.h: (CompressedLazyOperandValueProfileHolder): (LazyOperandValueProfileParser): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecode/ResolveGlobalStatus.cpp: (JSC::ResolveGlobalStatus::computeFor): * bytecode/ValueProfile.h: (JSC::ValueProfileBase::briefDescription): (ValueProfileBase): (JSC::ValueProfileBase::computeUpdatedPrediction): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): * dfg/DFGArrayMode.h: (ArrayMode): (JSC::DFG::ArrayMode::withProfile): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::getArrayMode): (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOSRExitPreparation.cpp: (JSC::DFG::prepareCodeOriginForOSRExit): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * jit/JITInlines.h: (JSC::JIT::chooseArrayMode): * jit/JITStubs.cpp: (JSC::tryCachePutByID): (JSC::tryCacheGetByID): (JSC::DEFINE_STUB_FUNCTION): (JSC::lazyLinkFor): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setUpCall): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/JSScope.cpp: (JSC::JSScope::resolveContainingScopeInternal): (JSC::JSScope::resolvePut): Source/WTF: Reviewed by Oliver Hunt. Add ability to abstract whether or not the CodeBlock requires locking at all, since some platforms may not support the byte spin-locking and/or may not want to, if they turn off concurrent JIT. * WTF.xcodeproj/project.pbxproj: * wtf/ByteSpinLock.h: * wtf/NoLock.h: Added. (WTF): (NoLock): (WTF::NoLock::lock): (WTF::NoLock::unlock): (WTF::NoLock::isHeld): * wtf/Platform.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153123 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely https://bugs.webkit.org/show_bug.cgi?id=114762 Source/JavaScriptCore: Reviewed by Mark Hahnenberg. For most inline caches this is easy: the inline cache has a clean temporal separation between doing the requested action (which may take an unbounded amount of time, may recurse, and may do arbitrary things) and recording the relevant information in the cache. So, we just put locks around the recording bit. That part is always O(1) and does not recurse. The lock we use is per-CodeBlock to achieve a good balance between locking granularity and low space overhead. So a concurrent compilation thread will only block if an inline cache ping-pongs in the code block being compiled (or inlined) and never when other inline caches do things. For resolve operations, it's a bit tricky. The global resolve bit works like any other IC in that it has the clean temporal separation. But the operations vector itself doesn't have this separation, since we will be filling it in tandem with actions that may take a long time. This patch gets around this by having a m_ready bit in the ResolveOperations and PutToBaseOperation. This is set while holding the CodeBlock's lock. If the DFG observes the m_ready bit not set (while holding the lock) then it conservatively assumes that the resolve hasn't happened yet and just plants a ForceOSRExit. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.h: (CodeBlock): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecode/ResolveGlobalStatus.cpp: (JSC::ResolveGlobalStatus::computeFor): * bytecode/ResolveOperation.h: (JSC::ResolveOperations::ResolveOperations): (ResolveOperations): (JSC::PutToBaseOperation::PutToBaseOperation): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITStubs.cpp: (JSC::tryCachePutByID): (JSC::tryCacheGetByID): (JSC::DEFINE_STUB_FUNCTION): (JSC::lazyLinkFor): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setUpCall): * runtime/JSScope.cpp: (JSC::JSScope::resolveContainingScopeInternal): (JSC::JSScope::resolveContainingScope): (JSC::JSScope::resolvePut): Source/WTF: Reviewed by Mark Hahnenberg. Implemented a new spinlock that is optimized for compactness, by using just a byte. This will be useful as we start using fine-grained locking on a bunch of places. At some point I'll make these byte-sized spinlocks into adaptive mutexes, but for now I think it's fine to do the evil thing and use spinning particularly since we only use them for short critical sections. * WTF.xcodeproj/project.pbxproj: * wtf/Atomics.h: (WTF): (WTF::weakCompareAndSwap): * wtf/ByteSpinLock.h: Added. (WTF): (ByteSpinLock): (WTF::ByteSpinLock::ByteSpinLock): (WTF::ByteSpinLock::lock): (WTF::ByteSpinLock::unlock): (WTF::ByteSpinLock::isHeld): * wtf/ThreadingPrimitives.h: (WTF::pauseBriefly): (WTF): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153122 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
broken builds. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114708 Reviewed by Oliver Hunt. This is work towards allowing the DFG, and FTL, to run on a separate thread. The idea is that the most evil thing that the DFG does that has thread-safety issues is fiddling with Structures by calling Structure::get(). This can lead to rematerialization of property tables, which is definitely not thread-safe due to how StringImpl works. So, this patch completely side-steps the problem by creating a new version of Structure::get, called Structure::getWithoutMaterializing, which may choose to do an O(n) search if necessary to avoid materialization. I believe this should be fine - the DFG does't call into these code path often enough for this to matter, and most of the time, the Structure that we call this on will already have a property table because some inline cache would have already called ::get() on that Structure. Also cleaned up the materialization logic: we can stop the search as soon as we find any Structure with a property table rather than searching all the way for a pinned one. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * runtime/Structure.cpp: (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::materializePropertyMap): (JSC::Structure::getWithoutMaterializing): (JSC): * runtime/Structure.h: (Structure): * runtime/StructureInlines.h: (JSC::Structure::getWithoutMaterializing): (JSC): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153120 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114306 Reviewed by Mark Hahnenberg. Just abstract out some things that the FTL will want to use as well. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: (OSRExitCompiler): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: Added. (DFG): (JSC::DFG::handleExitCounts): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: Added. (DFG): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153119 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114300 Reviewed by Mark Hahnenberg. * dfg/DFGFPRInfo.h: (FPRInfo): (JSC::DFG::FPRInfo::toArgumentRegister): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153118 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=114073 Reviewed by Mark Hahnenberg. * dfg/DFGGPRInfo.h: (GPRInfo): (JSC::DFG::GPRInfo::toArgumentRegister): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153117 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode https://bugs.webkit.org/show_bug.cgi?id=113905 Reviewed by Geoffrey Garen. This removes one pointer from CodeBlock. It also gives us a framework for having JITType-specific data in CodeBlock, by putting it into the appropriate JITCode class (either DFG::JITCode or FTL::JITCode). And it allows us to have DFG and FTL share some common data, via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and always accessible via JITCode::dfgCommon(). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::visitAggregate): (JSC::CodeBlock::performTracingFixpointIteration): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::stronglyVisitWeakReferences): (JSC::CodeBlock::shrinkToFit): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): (JSC::DFGCodeBlocks::mark): * dfg/DFGAssemblyHelpers.h: * dfg/DFGCommonData.cpp: Added. (DFG): (JSC::DFG::CommonData::notifyCompilingStructureTransition): (JSC::DFG::CommonData::shrinkToFit): * dfg/DFGCommonData.h: Added. (JSC): (DFG): (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition): (WeakReferenceTransition): (CommonData): (JSC::DFG::CommonData::CommonData): * dfg/DFGDriver.cpp: (JSC::DFG::compile): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGDriver.h: (DFG): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGGraph.h: (Graph): * dfg/DFGJITCode.cpp: Added. (DFG): (JSC::DFG::JITCode::JITCode): (JSC::DFG::JITCode::~JITCode): (JSC::DFG::JITCode::dfgCommon): (JSC::DFG::JITCode::dfg): (JSC::DFG::JITCode::shrinkToFit): * dfg/DFGJITCode.h: Added. (DFG): (JITCode): (JSC::DFG::JITCode::appendOSREntryData): (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex): (JSC::DFG::JITCode::appendOSRExit): (JSC::DFG::JITCode::lastOSRExit): (JSC::DFG::JITCode::appendSpeculationRecovery): (JSC::DFG::JITCode::appendWatchpoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): (JSC::DFG::JITCompiler::addWeakReference): (JSC::DFG::JITCompiler::noticeOSREntry): (JSC::DFG::JITCompiler::jitCode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::speculationWatchpoint): (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableEventStream.cpp: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::JITCode): (JSC::FTL::JITCode::~JITCode): (FTL): (JSC::FTL::JITCode::initializeCode): (JSC::FTL::JITCode::addressForCall): (JSC::FTL::JITCode::executableAddressAtOffset): (JSC::FTL::JITCode::dataAddressAtOffset): (JSC::FTL::JITCode::offsetOf): (JSC::FTL::JITCode::size): (JSC::FTL::JITCode::contains): (JSC::FTL::JITCode::ftl): (JSC::FTL::JITCode::dfgCommon): * ftl/FTLJITCode.h: (JITCode): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint): (JSC::FTL::LowerDFGToLLVM::compilePutStructure): (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure): (JSC::FTL::LowerDFGToLLVM::addWeakReference): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::weakPointer): * ftl/FTLState.cpp: (FTL): (JSC::FTL::State::State): (JSC::FTL::State::dumpState): * ftl/FTLState.h: (State): * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::~DFGCodeBlocks): (JSC::DFGCodeBlocks::jettison): (JSC::DFGCodeBlocks::clearMarks): (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks): (JSC::DFGCodeBlocks::traceMarkedCodeBlocks): * jit/JITCode.cpp: (JSC::JITCode::dfgCommon): (JSC): (JSC::JITCode::dfg): (JSC::JITCode::ftl): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::initializeCodeRef): (JSC::DirectJITCode::addressForCall): (JSC::DirectJITCode::executableAddressAtOffset): (JSC::DirectJITCode::dataAddressAtOffset): (JSC::DirectJITCode::offsetOf): (JSC::DirectJITCode::size): (JSC::DirectJITCode::contains): * jit/JITCode.h: (DFG): (FTL): (JSC): (JITCode): (DirectJITCode): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153116 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=113897 Reviewed by Mark Hahnenberg. In order to get OSR exit to work right, we need the distinction between DFG and FTL to be clear even after compilation finishes, since they will have subtly different OSR stories and likely use different data structures. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): (JSC::ProgramCodeBlock::compileOptimized): (JSC::EvalCodeBlock::compileOptimized): (JSC::FunctionCodeBlock::compileOptimized): (JSC::CodeBlock::adjustedExitCountThreshold): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::hasOptimizedReplacement): (JSC::ExecState::isInlineCallFrame): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::JITCode): * ftl/FTLState.cpp: (JSC::FTL::State::dumpState): * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::jettison): * interpreter/Interpreter.cpp: (JSC::getLineNumberForCallFrame): (JSC::getCallerInfo): * jit/JITCode.cpp: (WTF::printInternal): * jit/JITCode.h: (JSC::JITCode::topTierJIT): (JSC::JITCode::nextTierJIT): (JITCode): (JSC::JITCode::isJIT): (JSC::JITCode::isLowerTier): (JSC::JITCode::isHigherTier): (JSC::JITCode::isLowerOrSameTier): (JSC::JITCode::isHigherOrSameTier): (JSC::JITCode::isOptimizingJIT): * jit/JITDriver.h: (JSC::jitCompileIfAppropriate): (JSC::jitCompileFunctionIfAppropriate): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * runtime/Executable.cpp: (JSC::EvalExecutable::compileOptimized): (JSC::samplingDescription): (JSC::ProgramExecutable::compileOptimized): (JSC::FunctionExecutable::compileOptimizedForCall): (JSC::FunctionExecutable::compileOptimizedForConstruct): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153115 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=113894 Reviewed by Mark Hahnenberg. 1) We previously had two different ways of convertingToForward, one path for where we had a ValueRecovery for the current node and one where we didn't. But the paths were doing exactly the same thing except that if you have a ValueRecovery, you also find the last applicable mov hint and do some extra things. This patch combines the two paths and bases both of them on the previous no-ValueRecovery path, which was simpler to begin with. 2) This moves the logic into DFG::OSRExit, which further simplifies the code and makes the logic available to the FTL. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::convertToForward): (DFG): * dfg/DFGOSRExit.h: (DFG): (OSRExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153114 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
oliver@apple.com authored
fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated https://bugs.webkit.org/show_bug.cgi?id=113437 Reviewed by Mark Hahnenberg. JITCode is now a virtual base class, which will allow different JITs to have radically different memory allocation and management conventions in the future. It will also make it easier to store JIT-specific meta-data in CodeBlock just by putting it into an appropriate JITCode subclass. For now there is one subclass, DirectJITCode, which just behaves like JITCode used to behave. * assembler/RepatchBuffer.h: (JSC::RepatchBuffer::RepatchBuffer): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): (JSC::CodeBlock::bytecodeOffset): (JSC::CodeBlock::codeOriginForReturn): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::getJITCode): (JSC::CodeBlock::getJITType): (CodeBlock): * dfg/DFGDriver.cpp: (JSC::DFG::compile): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGDriver.h: (DFG): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::codeLocationForRepatch): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JIT.h: (JSC::JIT::compile): (JIT): * jit/JITCode.cpp: (JSC): (JSC::JITCode::JITCode): (JSC::JITCode::~JITCode): (JSC::JITCode::execute): (JSC::JITCode::hostFunction): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::~DirectJITCode): (JSC::DirectJITCode::addressForCall): (JSC::DirectJITCode::executableAddressAtOffset): (JSC::DirectJITCode::dataAddressAtOffset): (JSC::DirectJITCode::offsetOf): (JSC::DirectJITCode::size): (JSC::DirectJITCode::contains): * jit/JITCode.h: (JSC): (JITCode): (JSC::JITCode::bottomTierJIT): (JSC::JITCode::topTierJIT): (JSC::JITCode::nextTierJIT): (JSC::JITCode::isOptimizingJIT): (JSC::JITCode::isBaselineCode): (JSC::JITCode::jitType): (JSC::JITCode::jitTypeFor): (JSC::JITCode::executableAddress): (JSC::JITCode::start): (JSC::JITCode::end): (DirectJITCode): * jit/JITDriver.h: (JSC::jitCompileIfAppropriate): (JSC::jitCompileFunctionIfAppropriate): * jit/JITStubs.cpp: (JSC::lazyLinkFor): (JSC::DEFINE_STUB_FUNCTION): * jit/ThunkGenerators.cpp: (JSC::virtualForGenerator): * llint/LLIntEntrypoints.cpp: (JSC::LLInt::getFunctionEntrypoint): (JSC::LLInt::getEvalEntrypoint): (JSC::LLInt::getProgramEntrypoint): * llint/LLIntEntrypoints.h: (JSC): (LLInt): (JSC::LLInt::getEntrypoint): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Executable.cpp: (JSC::EvalExecutable::compileInternal): (JSC::ProgramExecutable::compileInternal): (JSC::FunctionExecutable::compileForCallInternal): (JSC::FunctionExecutable::compileForConstructInternal): * runtime/Executable.h: (JSC::ExecutableBase::generatedJITCodeForCall): (JSC::ExecutableBase::generatedJITCodeForConstruct): (JSC::ExecutableBase::generatedJITCodeFor): (ExecutableBase): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::NativeExecutable::create): (JSC::NativeExecutable::finishCreation): (JSC::EvalExecutable::generatedJITCode): (JSC::ProgramExecutable::generatedJITCode): * runtime/ExecutionHarness.h: (JSC::prepareForExecution): (JSC::prepareFunctionForExecution): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153113 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
simon.fraser@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=119072 Reviewed by Beth Dakin. MediaControlTextTrackContainerElement::createTextTrackRepresentationImage() is called to paint captions into a layer used for fullscreen video. It did the painting using a subtree paint, but starting at the root RenderView's layer. This is problematic, because the caption painting is subject to clipping for columns, and any enclosing overflow:hidden container. Fix this by starting the paint at the MediaControlTextTrackContainerElement's renderer's layer. By doing this we don't have to worry about an offset, so no translation is required. Also make sure we update layer before grabbing the renderer (in case layout destroys it). * html/shadow/MediaControlElements.cpp: (WebCore::MediaControlTextTrackContainerElement::createTextTrackRepresentationImage): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153112 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
dbates@webkit.org authored
Add DRT test to ensure don't override z-index for overflow: scroll, -webkit-overflow-scrolling: touch https://bugs.webkit.org/show_bug.cgi?id=119071 Reviewed by Simon Fraser. Add a DRT test to ensure we don't regress the fix for <https://bugs.webkit.org/show_bug.cgi?id=119066>. * compositing/overflow/should-not-override-z-index-for-element-with-non-auto-z-index-and-overflow-scroll-and-touch-expected.txt: Added. * compositing/overflow/should-not-override-z-index-for-element-with-non-auto-z-index-and-overflow-scroll-and-touch.html: Added. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153111 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
ruth_fong@apple.com authored
<rdar://problem/14528039> and https://bugs.webkit.org/show_bug.cgi?id=119025 Reviewed by Brady Eidson. Renamed WebColorChooserProxy to WebColorPicker since the name WebColorChoooserProxy implies that it represents the same object as WebColorChooser, which is not true. Also, renamed createColorChooserProxy to createColorPicker in WebPageProxy and platform-equivalent versions of it. * CMakeLists.txt: * GNUmakefile.list.am: * Target.pri: * UIProcess/API/gtk/PageClientImpl.cpp: (WebKit::PageClientImpl::createColorPicker): * UIProcess/API/gtk/PageClientImpl.h: * UIProcess/API/mac/PageClientImpl.h: * UIProcess/API/mac/PageClientImpl.mm: (WebKit::PageClientImpl::createColorPicker): * UIProcess/API/qt/raw/qrawwebview.cpp: (QRawWebViewPrivate::createColorPicker): * UIProcess/API/qt/raw/qrawwebview_p_p.h: * UIProcess/CoordinatedGraphics/WebView.cpp: (WebKit::WebView::createColorPicker): * UIProcess/CoordinatedGraphics/WebView.h: * UIProcess/PageClient.h: * UIProcess/WebColorChooserProxy.cpp: Removed. * UIProcess/WebColorChooserProxy.h: Removed. * UIProcess/WebColorPicker.cpp: Copied from Source/WebKit2/UIProcess/WebColorChooserProxy.cpp. (WebKit::WebColorPicker::WebColorPicker): (WebKit::WebColorPicker::~WebColorPicker): (WebKit::WebColorPicker::endChooser): (WebKit::WebColorPicker::setSelectedColor): * UIProcess/WebColorPicker.h: Copied from Source/WebKit2/UIProcess/WebColorChooserProxy.h. (WebKit::WebColorPicker::create): * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::close): (WebKit::WebPageProxy::showColorChooser): (WebKit::WebPageProxy::setColorChooserColor): (WebKit::WebPageProxy::endColorChooser): (WebKit::WebPageProxy::didEndColorChooser): (WebKit::WebPageProxy::resetStateAfterProcessExited): * UIProcess/WebPageProxy.h: Renamed m_colorChooser to m_colorPicker. * UIProcess/qt/QtPageClient.cpp: (WebKit::QtPageClient::createColorPicker): * UIProcess/qt/QtPageClient.h: * UIProcess/qt/WebColorChooserProxyQt.cpp: Removed. * UIProcess/qt/WebColorChooserProxyQt.h: Removed. * UIProcess/qt/WebColorPickerQt.cpp: Added. (WebKit::ColorChooserContextObject::ColorChooserContextObject): (WebKit::ColorChooserContextObject::currentColor): (WebKit::ColorChooserContextObject::elementRect): (WebKit::ColorChooserContextObject::accept): (WebKit::ColorChooserContextObject::reject): (WebKit::WebColorPickerQt::WebColorPickerQt): (WebKit::WebColorPickerQt::~WebColorPickerQt): (WebKit::WebColorPickerQt::createItem): (WebKit::WebColorPickerQt::createContext): (WebKit::WebColorPickerQt::setSelectedColor): (WebKit::WebColorPickerQt::notifyColorSelected): (WebKit::WebColorPickerQt::endChooser): * UIProcess/qt/WebColorPickerQt.h: Added. (WebKit::WebColorPickerQt::create): * WebKit2.xcodeproj/project.pbxproj: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153108 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
andersca@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=119069 <rdar://problem/14494064> Reviewed by Andreas Kling. Source/WebKit2: * UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::processIdentifier): Check if the page is closed instead of checking whether we have a process - We'll always have a process. (WebKit::WebPageProxy::isValid): Make this const. * UIProcess/WebPageProxy.h: Tools: Add a test. * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * TestWebKitAPI/Tests/WebKit2/mac/GetPIDAfterAbortedProcessLaunch.cpp: Added. (TestWebKitAPI::didFinishLoadForFrame): (TestWebKitAPI::TEST): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153107 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
kseo@webkit.org authored
https://bugs.webkit.org/show_bug.cgi?id=110136 Reviewed by Gustavo Noronha Silva. Original patch by Balazs Kelemen <kbalazs@webkit.org>. Added a common entry point for non-Mac Unix ports. * NetworkProcess/unix/NetworkProcessMainUnix.cpp: Added. (WebKit::NetworkProcessMain): * NetworkProcess/unix/NetworkProcessMainUnix.h: Added. * unix/NetworkMainUnix.cpp: Added. (main): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153106 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
simon.fraser@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=119066 <rdar://problem/14499184> Reviewed by Daniel Bates. Following <http://trac.webkit.org/changeset/152335> (bug #118337) we set the z-index to 0 on every element with CSS "overflow: scroll" and "-webkit-overflow-scrolling: touch" regardless of whether the element has non-auto z-index. Instead we should only set the z-index to 0 for such elements that have an auto z-index. * css/StyleResolver.cpp: (WebCore::StyleResolver::adjustRenderStyle): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
fpizlo@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=119065 Reviewed by Mark Hahnenberg. Made the body of IndexingHeader be a union. Modified the offlineasm so that you can say IndexingHeader::u.lengths.publicLength. Previously those dots would cause parse errors. Now an identifier in offlineasm can have a dot anywhere except the first character. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/parser.rb: * runtime/IndexingHeader.h: (JSC::IndexingHeader::offsetOfPublicLength): (JSC::IndexingHeader::offsetOfVectorLength): (JSC::IndexingHeader::IndexingHeader): (JSC::IndexingHeader::vectorLength): (JSC::IndexingHeader::setVectorLength): (JSC::IndexingHeader::publicLength): (JSC::IndexingHeader::setPublicLength): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153104 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
rniwa@webkit.org authored
https://bugs.webkit.org/show_bug.cgi?id=118627 Reviewed by Oliver Hunt. Merge https://chromium.googlesource.com/chromium/blink/+/b6471d077e012b05ccba14d0ce8e6d616106c8e6 Unfortunately, there is no test case for this bug. * editing/ApplyStyleCommand.cpp: (WebCore::ApplyStyleCommand::removeInlineStyle): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153102 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-