1. 24 Jul, 2013 17 commits
    • oliver@apple.com's avatar
      fourthTier: Rationalized 'this' conversion, includes subsequent FTL branch fixes · e2fe4ceb
      oliver@apple.com authored
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
          This fixes a bunch of Sputnik tests, and some bad pointer access.
      
          The new model is that the callee always performs 'this' value conversion.
      
          My ultimate goal is to break up resolve_with_this into single-result
          opcodes. This step avoids having to add a special form of convert_this
          that distinguishes callers vs callees.
      
          Only the callee knows whether it uses 'this' and/or whether 'this'
          conversion should use StrictMode, so it's most natural to perform
          convert_this in the callee.
      
          * API/JSCallbackFunction.cpp:
          (JSC::JSCallbackFunction::call): Perform 'this' value conversion for
          our callee, since it may observe 'this'.
      
          * API/JSCallbackObjectFunctions.h:
          (JSC::::call): Ditto.
      
          * API/JSContextRef.cpp:
          (JSGlobalContextCreateInGroup): Use a proxy 'this' object in global scope
          even when we're not in the browser. This eliminates some odd cases where
          API clients used to be able to get a direct reference to an environment
          record. Now, any reference to an environment record unambiguously means
          that the VM resolved that record in the scope chain.
      
          (JSContextGetGlobalObject): Removed an incorrect comment. Now that JSC
          participates in the proxy 'this' object scheme, the behavior is not
          WebCore-only.
      
          * API/JSObjectRef.cpp:
          (JSObjectSetPrototype):
          (JSObjectCallAsFunction): Don't perform 'this' value conversion in the
          caller; the callee will do it if needed.
      
          * JavaScriptCore.order: Order!
      
          * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
          * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
          What are the chances that this will work?
      
          * bytecode/CodeBlock.cpp:
          (JSC::CodeBlock::dumpBytecode):
          (JSC::CodeBlock::CodeBlock): Renamed convert_this to to_this, to match our
          other conversion opcodes.
      
          * bytecode/CodeOrigin.h:
          (CodeOrigin):
          (InlineCallFrame):
          (JSC::CodeOrigin::codeOriginOwner): Use the more precise type for our
          executable, so compilation can discover where we're in strict mode.
      
          * bytecode/Opcode.h:
          (JSC::padOpcodeName): Updated for rename.
      
          * bytecompiler/BytecodeGenerator.cpp:
          (JSC::BytecodeGenerator::BytecodeGenerator): Always emit to_this when
          'this' is in use -- strict mode still needs to convert environment
          records to 'undefined'.
      
          * dfg/DFGAbstractState.cpp:
          (JSC::DFG::AbstractState::executeEffects):
          * dfg/DFGByteCodeParser.cpp:
          (JSC::DFG::ByteCodeParser::parseBlock):
          * dfg/DFGCapabilities.h:
          (JSC::DFG::canCompileOpcode): Updated for renames.
      
          * dfg/DFGFixupPhase.cpp:
          (JSC::DFG::FixupPhase::fixupNode): Tightened up this code to consider
          strict mode (a new requirement) and to consider the global object (which
          was always a requirement).
      
          * dfg/DFGGraph.h:
          (JSC::DFG::Graph::globalThisObjectFor):
          (JSC::DFG::Graph::executableFor):
          * dfg/DFGNodeType.h:
          * dfg/DFGOperations.cpp:
          * dfg/DFGOperations.h:
          * dfg/DFGPredictionPropagationPhase.cpp:
          (JSC::DFG::PredictionPropagationPhase::propagate):
          * dfg/DFGSpeculativeJIT32_64.cpp:
          (JSC::DFG::SpeculativeJIT::compile):
          * dfg/DFGSpeculativeJIT64.cpp:
          (JSC::DFG::SpeculativeJIT::compile): Ditto.
      
          * interpreter/Interpreter.cpp:
          (JSC::eval):
          (JSC::Interpreter::execute):
          (JSC::Interpreter::executeCall):
          * interpreter/Interpreter.h: Don't ASSERT about 'this' -- it's our job
          to fix it up if needed.
      
          * jit/JIT.cpp:
          (JSC::JIT::privateCompileMainPass):
          (JSC::JIT::privateCompileSlowCases):
          * jit/JIT.h:
          (JIT):
          * jit/JITOpcodes.cpp:
          (JSC::JIT::emit_op_to_this):
          (JSC::JIT::emitSlow_op_to_this):
          * jit/JITOpcodes32_64.cpp:
          (JSC::JIT::emit_op_to_this):
          (JSC::JIT::emitSlow_op_to_this):
          * jit/JITStubs.cpp:
          (JSC::DEFINE_STUB_FUNCTION):
          * jit/JITStubs.h: Removed special-case code for various kinds of
          conversions. The baseline fast path is now final objects only. It hurt
          my brain to think through how to keep the other fast paths working, and
          our benchmarks do not object.
      
          * llint/LLIntData.cpp:
          (JSC::LLInt::Data::performAssertions):
          * llint/LLIntSlowPaths.cpp:
          (JSC::LLInt::LLINT_SLOW_PATH_DECL):
          * llint/LLIntSlowPaths.h:
          (LLInt):
          * llint/LowLevelInterpreter.asm:
          * llint/LowLevelInterpreter32_64.asm:
          * llint/LowLevelInterpreter64.asm: Updated for renames. Removed some
          special case code, as in the JIT above.
      
          * profiler/ProfileGenerator.cpp:
          (JSC::ProfileGenerator::addParentForConsoleStart):
          * runtime/CallData.cpp:
          (JSC::call):
          * runtime/ClassInfo.h:
          (MethodTable):
          * runtime/Completion.cpp:
          (JSC::evaluate):
          * runtime/DatePrototype.cpp:
          (JSC::dateProtoFuncToJSON): The callee performs 'this' conversion, not
          the caller.
      
          * runtime/GetterSetter.cpp:
          (JSC::callGetter):
          (JSC::callSetter):
          * runtime/GetterSetter.h: Added helper functions for invoking getters
          and setters from C++ code, since this was duplicated in a bunch of
          places.
      
          * runtime/JSActivation.cpp:
          (JSC::JSActivation::toThis):
          * runtime/JSActivation.h:
          (JSActivation):
          * runtime/JSCJSValue.cpp:
          (JSC::JSValue::toThisSlowCase):
          (JSC::JSValue::putToPrimitive):
          * runtime/JSCJSValue.h:
          (JSValue):
          * runtime/JSCJSValueInlines.h:
          (JSC::JSValue::toThis):
          * runtime/JSCell.cpp:
          (JSC::JSCell::toThis):
          * runtime/JSCell.h:
          (JSCell):
          * runtime/JSGlobalObject.cpp:
          (JSC::JSGlobalObject::toThis):
          * runtime/JSGlobalObject.h:
          (JSGlobalObject): Filled out runtime support for converting 'this'
          values as needed, according to the appropriate strictness, using
          helper functions where getter/setter code was duplicated.
      
          * runtime/JSGlobalObjectFunctions.cpp:
          (JSC::globalFuncProtoGetter):
          (JSC::globalFuncProtoSetter): Perform 'this' value conversion, since we
          observe 'this'.
      
          * runtime/JSNameScope.cpp:
          (JSC::JSNameScope::toThis):
          * runtime/JSNameScope.h:
          (JSNameScope): Same as JSActivation.
      
          * runtime/JSObject.cpp:
          (JSC::JSObject::put):
          (JSC::JSObject::setPrototypeWithCycleCheck): Bug fix. Don't peform
          'this' value conversion in this helper function. The __proto__
          setter does this for us, since it's the function that logically observes
          'this' -- and we can ASSERT so. Also, the previous code used
          "globalExec()->thisValue()", which is a read past the beginning of a
          buffer! I don't think this ever worked on purpose.
      
          (JSC::JSObject::toThis):
          (JSC::JSObject::fillGetterPropertySlot):
          * runtime/JSObject.h:
          (JSC::JSObject::inlineGetOwnPropertySlot):
          * runtime/JSScope.cpp:
          (JSC::JSScope::resolveWithThis):
          * runtime/JSString.cpp:
          (JSC::JSString::toThis):
          * runtime/JSString.h:
          (JSString):
          * runtime/PropertySlot.cpp:
          (JSC::PropertySlot::functionGetter):
          * runtime/PropertySlot.h:
          (JSC):
          (JSC::PropertySlot::setGetterSlot):
          (JSC::PropertySlot::setCacheableGetterSlot):
          * runtime/SparseArrayValueMap.cpp:
          (JSC::SparseArrayEntry::get):
          (JSC::SparseArrayEntry::put):
          * runtime/StrictEvalActivation.cpp:
          (JSC::StrictEvalActivation::toThis):
          * runtime/StrictEvalActivation.h:
          (StrictEvalActivation): Ditto.
      
      Source/WebCore:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      Source/WebKit/mac:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      Source/WebKit2:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      LayoutTests:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153145 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e2fe4ceb
    • oliver@apple.com's avatar
      fourthTier: DFG tries to ref/deref StringImpls in a ton of places · 02039469
      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
      02039469
    • oliver@apple.com's avatar
      fourthTier: Structure transition table keys don't have to ref their StringImpl's · 36e01a77
      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
      36e01a77
    • oliver@apple.com's avatar
      fourthTier: Structure::addPropertyTransitionToExistingStructure should be thread-safe · cece4b66
      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
      cece4b66
    • oliver@apple.com's avatar
      fourthTier: Structure::getConcurrently() may be called from for uncacheable... · ac8aba9a
      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
      ac8aba9a
    • oliver@apple.com's avatar
      fourthTier: String::utf8() should also be available as StringImpl::utf8() so... · 1d1a380b
      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
      1d1a380b
    • oliver@apple.com's avatar
      fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime... · 634a76a2
      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
      634a76a2
    • oliver@apple.com's avatar
      fourthTier: SymbolTable should be thread-safe · f72e22e2
      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
      f72e22e2
    • oliver@apple.com's avatar
      fourthTier: Create an equivalent of Structure::get() that can work from a compilation thread · 22fdb104
      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
      22fdb104
    • oliver@apple.com's avatar
      fourthTier: It should be possible to query WatchpointSets, and add... · 9397e00c
      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
      9397e00c
    • oliver@apple.com's avatar
      fourthTier: value profiles and array profiles should be thread-safe enough to... · c14eb7d0
      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
      c14eb7d0
    • oliver@apple.com's avatar
      fourthTier: all inline caches should thread-safe enough to allow a concurrent... · 0c1b13e9
      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
      0c1b13e9
    • oliver@apple.com's avatar
      fourthTier: Landing the initial FTL logic in a single commit to avoid spurious · ea77149c
      oliver@apple.com authored
      broken builds.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ea77149c
    • oliver@apple.com's avatar
      fourthTier: DFG should be able to query Structure without modifying it · b3956443
      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
      b3956443
    • oliver@apple.com's avatar
      fourthTier: Everyone should know about the FTL · 56f0addc
      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
      56f0addc
    • oliver@apple.com's avatar
      fourthTier: JITCode should abstract exactly how the JIT code is structured and... · 9a1ae938
      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
      9a1ae938
    • fpizlo@apple.com's avatar
      It should be possible to hijack IndexingHeader for things other than lengths · 85eb7df9
      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
      85eb7df9
  2. 18 Jul, 2013 1 commit
    • commit-queue@webkit.org's avatar
      Fixed ASSERTION FAILED: callFrame == vm->topCallFrame in JSC::Interpreter::addStackTraceIfNecessary · e0c69d5e
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118498
      
      Patch by Chris Curtis <chris_curtis@apple.com> on 2013-07-18
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore:
      
      * jit/JITStubs.cpp:
      (throwExceptionFromOpCall):
      Created new throwExceptionFromOpCall that takes in a functor that contains
      a function pointer (to create the errorObject) instead of a JSValue. Inside
      of throwExceptionFromOpCall the topCallFrame is being rolled back in order
      to handle the error throw. By passing the function pointer in, we can defer
      the creation of the error object until after topCallFrame has been rolled
      back. This allows the error object to be created with the appropriate top
      frame.
      
      DEFINE_STUB_FUNCTION(void*, stack_check):
      DEFINE_STUB_FUNCTION(void*, op_call_arityCheck):
      DEFINE_STUB_FUNCTION(void*, op_construct_arityCheck):
      DEFINE_STUB_FUNCTION(EncodedJSValue, op_call_NotJSFunction):
      DEFINE_STUB_FUNCTION(EncodedJSValue, op_construct_NotJSConstruct):
      
      (JSC::ErrorFunctor::~ErrorFunctor):
      (JSC::ErrorWithExecFunctor::ErrorWithExecFunctor):
      (JSC::ErrorWithExecFunctor::operator()):
      (JSC::ErrorWithExecAndCalleeFunctor::ErrorWithExecAndCalleeFunctor):
      (JSC::ErrorWithExecAndCalleeFunctor::operator()):
      (JSC::ErrorWithExceptionFunctor::ErrorWithExceptionFunctor):
      (JSC::ErrorWithExceptionFunctor::operator()):
      (JSC::throwExceptionFromOpCall):
      
      In order to eliminate the need to duplicate code, an error functor was
      created for the 3 different throwExceptionFromOpCall handles.
      1. The exception needs to be created, and the function pointer takes 1
          parameter(callFrame->callerFrame()).
      2. The exception needs to be created, and the function pointer takes 2
          parameters (callFrame->callerFrame(), callFrame.calleeAsValue()).
      3. The exception is already created. In this case, At the time when
          the error functor is called, vm.exception is returned.
      
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * runtime/ExceptionHelpers.cpp:
      (JSC::errorDescriptionForValue):
      (JSC::createError):
      (JSC::createInvalidParameterError):
      (JSC::createNotAConstructorError):
      (JSC::createNotAFunctionError):
      (JSC::createNotAnObjectError):
      * runtime/ExceptionHelpers.h:
      
      The function toString() was being used to stringify an object for an exception
      message. If the user wrote a toString() for that object, then the system would
      continue to evaluate that code. A new helper function was created to prevent
      the system to continue execution and exception creation from that execution.
      
      LayoutTests:
      
      New Tests to see if JSC evaluates user code after exception creation
      
      * fast/js/not-a-constructor-to-string-expected.txt: Added.
      * fast/js/not-a-constructor-to-string.html: Added.
      * fast/js/not-a-function-to-string-expected.txt: Added.
      * fast/js/not-a-function-to-string.html: Added.
      
      Modified test output of the object that was being evaluated at the time of the
      error. Only the error message has changed.
      
      * fast/dom/MutationObserver/mutation-record-constructor-expected.txt:
      * fast/dom/NodeList/nodelist-item-call-as-function-expected.txt:
      * fast/dom/Range/getClientRects-expected.txt:
      * fast/dom/SelectorAPI/dumpNodeList-almost-strict-expected.txt:
      * fast/dom/SelectorAPI/dumpNodeList-expected.txt:
      * fast/dom/call-a-constructor-as-a-function-expected.txt:
      * fast/dom/setPrimitiveValue-exceptions-expected.txt:
      * fast/events/window-onerror-exception-in-attr-expected.txt:
      * fast/forms/select-namedItem-expected.txt:
      * fast/js/arguments-expected.txt:
      * fast/js/array-prototype-properties-expected.txt:
      * fast/js/basic-strict-mode-expected.txt:
      * fast/js/date-toisostring-expected.txt:
      * fast/js/delete-getters-setters-expected.txt:
      * fast/js/dfg-check-structure-elimination-for-non-cell-expected.txt:
      * fast/js/dfg-compare-final-object-to-final-object-or-other-when-both-proven-final-object-expected.txt:
      * fast/js/dfg-compare-final-object-to-final-object-or-other-when-proven-final-object-expected.txt:
      * fast/js/dfg-inline-arguments-use-from-all-the-places-broken-expected.txt:
      * fast/js/dfg-peephole-compare-final-object-to-final-object-or-other-when-both-proven-final-object-expected.txt:
      * fast/js/dfg-peephole-compare-final-object-to-final-object-or-other-when-proven-final-object-expected.txt:
      * fast/js/exception-expression-offset-expected.txt:
      * fast/js/exception-for-nonobject-expected.txt:
      * fast/js/exception-thrown-from-new-expected.txt:
      * fast/js/function-bind-expected.txt:
      * fast/js/instance-of-immediates-expected.txt:
      * fast/js/object-prototype-properties-expected.txt:
      * fast/regex/cross-frame-callable-expected.txt:
      * fast/xsl/transform-xhr-doc-expected.txt:
      * http/tests/security/aboutBlank/xss-DENIED-navigate-opener-document-write-expected.txt:
      * http/tests/security/aboutBlank/xss-DENIED-navigate-opener-javascript-url-expected.txt:
      * http/tests/security/aboutBlank/xss-DENIED-set-opener-expected.txt:
      * http/tests/security/document-all-expected.txt:
      * http/tests/security/srcdoc-in-sandbox-cannot-access-parent-expected.txt:
      * http/tests/security/window-named-proto-expected.txt:
      * inspector/console/console-exception-stack-traces-expected.txt:
      * platform/efl/css3/selectors3/xhtml/css3-modsel-15c-expected.txt:
      * platform/efl/css3/selectors3/xml/css3-modsel-15c-expected.txt:
      * platform/efl/fast/events/updateLayoutForHitTest-expected.txt:
      * platform/efl/tables/mozilla_expected_failures/bugs/bug92868_1-expected.txt:
      * platform/gtk/css3/selectors3/xhtml/css3-modsel-15c-expected.txt:
      * platform/gtk/css3/selectors3/xml/css3-modsel-15c-expected.txt:
      * platform/gtk/fast/events/updateLayoutForHitTest-expected.txt:
      * platform/gtk/svg/custom/createelement-expected.txt:
      * platform/gtk/tables/mozilla_expected_failures/bugs/bug92868_1-expected.txt:
      * platform/mac-wk2/editing/spelling/markers-expected.txt:
      * platform/mac-wk2/plugins/npruntime/object-from-destroyed-plugin-expected.txt: Added.
      * platform/mac-wk2/plugins/npruntime/object-from-destroyed-plugin-in-subframe-expected.txt: Added.
      * platform/mac/css3/selectors3/xhtml/css3-modsel-15c-expected.txt:
      * platform/mac/css3/selectors3/xml/css3-modsel-15c-expected.txt:
      * platform/mac/fast/events/updateLayoutForHitTest-expected.txt:
      * platform/mac/tables/mozilla_expected_failures/bugs/bug92868_1-expected.txt:
      * platform/qt/css3/selectors3/xhtml/css3-modsel-15c-expected.txt:
      * platform/qt/css3/selectors3/xml/css3-modsel-15c-expected.txt:
      * platform/qt/svg/custom/createelement-expected.txt:
      * platform/qt/tables/mozilla_expected_failures/bugs/bug92868_1-expected.txt:
      * platform/win/fast/dom/call-a-constructor-as-a-function-expected.txt:
      * plugins/npruntime/object-from-destroyed-plugin-expected.txt:
      * plugins/npruntime/object-from-destroyed-plugin-in-subframe-expected.txt:
      * plugins/npruntime/plugin-scriptable-object-invoke-default-expected.txt:
      * sputnik/Conformance/08_Types/8.6_The_Object_Type/8.6.2_Internal_Properties_and_Methods/S8.6.2_A7-expected.txt:
      * sputnik/Conformance/13_Function_Definition/S13_A17_T2-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/S15.1_A1_T1-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/S15.1_A1_T2-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/S15.1_A2_T1-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/15.2.4.2_Object.prototype.toString/S15.2.4.2_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/15.2.4.3_Object.prototype.toLocaleString/S15.2.4.3_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/15.2.4.4_Object.prototype.valueOf/S15.2.4.4_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/15.2.4.5_Object.prototype.hasOwnProperty/S15.2.4.5_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/15.2.4.6_Object.prototype.isPrototypeOf/S15.2.4.6_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/15.2.4.7_Object.prototype.propertyIsEnumerable/S15.2.4.7_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/S15.2.4_A3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.2_Object/15.2.4/S15.2.4_A4-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.3_Function/15.3.4/15.3.4.2_Function.prototype.toString/S15.3.4.2_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.3_Function/15.3.4/S15.3.4_A5-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.12_String.prototype.search/S15.5.4.12_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.13_String.prototype.slice/S15.5.4.13_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.15_String.prototype.substring/S15.5.4.15_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.17_String.prototype.toLocaleLowerCase/S15.5.4.17_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.7_String.prototype.indexOf/S15.5.4.7_A7-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.8_String.prototype.lastIndexOf/S15.5.4.8_A7-expected.txt:
      * svg/custom/createelement-expected.txt:
      * svg/custom/use-nested-missing-target-removed-expected.txt:
      * svg/dom/svgpath-out-of-bounds-getPathSeg-expected.txt:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152871 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e0c69d5e
  3. 17 Jul, 2013 1 commit
    • commit-queue@webkit.org's avatar
      Naming convention on createInvalidParamError is incorrect. · 3f53377b
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=118756
      
      Patch by Chris Curtis <chris_curtis@apple.com> on 2013-07-17
      Reviewed by Geoffrey Garen.
      
      Changed the naming of createInvalidParamError to createInvalidParameterError.
      This corrects the naming convention for the function listed in the WebKit code styling.
      
      * interpreter/Interpreter.cpp:
      (JSC::loadVarargs):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * runtime/CommonSlowPaths.h:
      (JSC::CommonSlowPaths::opIn):
      * runtime/ExceptionHelpers.cpp:
      (JSC::createInvalidParameterError):
      * runtime/ExceptionHelpers.h:
      * runtime/JSObject.cpp:
      (JSC::JSObject::hasInstance):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152784 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3f53377b
  4. 14 Jul, 2013 1 commit
  5. 11 Jul, 2013 1 commit
  6. 09 Jul, 2013 1 commit
    • mark.lam@apple.com's avatar
      Fix 30% JSBench regression (caused by adding column numbers to stack traces). · 5b45f90a
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118481.
      
      Reviewed by Mark Hahnenberg and Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      Previously, we already capture ExpressionRangeInfo that provides a divot for
      each bytecode that can potentially throw an exception (and therefore generate
      a stack trace). On first attempt to compute column numbers, we then do a walk
      of the source string to record all line start positions in a table associated
      with the SourceProvider. The column number can then be computed as
          divot - lineStartFor(bytecodeOffset).
      
      The computation of this lineStarts table is the source of the 30% JSBench
      performance regression.
      
      The new code now records lineStarts as the lexer and parser scans the source
      code. These lineStarts are then used to compute the column number for the
      given divot, and stored in the ExpressionRangeInfo. Similarly, we also capture
      the line number at the divot point and store that in the ExpressionRangeInfo.
      Hence, to look up line and column numbers, we now lookup the ExpressionRangeInfo
      for the bytecodeOffset, and then compute the line and column from the values
      stored in the expression info.
      
      The strategy:
      1. We want to minimize perturbations to the lexer and parser. Specifically,
         the changes added should not change how it scans code, and generate bytecode.
      2. We regard the divot as the source character position we are interested
         in. As such, we'll capture line and lineStart (for column) at the point
         when we capture the divot information. This ensures that the 3 values are
         consistent.
      
      How the change is done:
      1. Change the lexer to track lineStarts.
      2. Change the parser to capture line and lineStarts at the point of capturing
         divots.
      3. Change the parser and associated code to plumb these values all the way to
         the point that the correspoinding ExpressionRangeInfo is emitted.
      4. Propagate and record SourceCode firstLine and firstLineColumnOffset to the
         the necessary places so that we can add them as needed when reifying
         UnlinkedCodeBlocks into CodeBlocks.
      5. Compress the line and column number values in the ExpressionRangeInfo. In
         practice, we seldom have both large line and column numbers. Hence, we can
         encode both in an uint32_t most of the time. For the times when we encounter
         both large line and column numbers, we have a fallback to store the "fat"
         position info.
      6. Emit an ExpressionRangeInfo for UnaryOp nodes to get more line and column
         number coverage.
      7. Change the interpreter to use the new way of computing line and column.
      8. Delete old line and column computation code that is now unused.
      
      Misc details:
      - the old lexer was tracking both a startOffset and charPosition where
        charPosition equals startOffset - SourceCode.startOffset. We now use
        startOffset exclusively throughout the system for consistency.
        All offset values (including lineStart) are relative to the start of the
        SourceProvider string. These values will only be converted to be relative
        to the SourceCode.startOffset at the very last minute i.e. when the divot
        is stored into the ExpressionRangeInfo.
      
        This change to use the same offset system everywhere reduces confusion
        from having to convert back and forth between the 2 systems. It also
        enables a lot of assertions to be used.
      
      - Also fixed some bugs in the choice of divot positions to use. For example,
        both Eval and Function expressions previously used column numbers from
        the start of the expression but used the line number at the end of the
        expression. This is now fixed to use either the start or end positions
        as appropriate, but not a mix of line and columns from both.
      
      - Why use ints instead of unsigneds for offsets and lineStarts inside the
        lexer and parser?
        Some tests (e.g. fast/js/call-base-resolution.html and
        fast/js/eval-cross-window.html) has shown that lineStart offsets can be
        prior to the SourceCode.startOffset. Keeping the lexer offsets as ints
        simplifies computations and makes it easier to maintain the assertions
        that (startOffset >= lineStartOffset).
      
        However, column and line numbers are always unsigned when we publish
        them to the ExpressionRangeInfo. The ints are only used inside the
        lexer and parser ... well, and bytecode generator.
      
      - For all cases, lineStart is always captured where the divot is captured.
        However, some sputnik conformance tests have shown that we cannot honor
        line breaks for assignment statements like the following:
      
            eval("x\u000A*=\u000A-1;");
      
        In this case, the lineStart is expected to be captured at the start of
        the assignment expression instead of at the divot point in the middle.
        The assignment expression is the only special case for this.
      
      This patch has been tested against the full layout tests both with release
      and debug builds with no regression.
      
      * API/JSContextRef.cpp:
      (JSContextCreateBacktrace):
        - Updated to use the new StackFrame::computeLineAndColumn().
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
        - Added m_firstLineColumnOffset initialization.
        - Plumbed the firstLineColumnOffset into the SourceCode.
        - Initialized column for op_debug using the new way.
      (JSC::CodeBlock::lineNumberForBytecodeOffset):
        - Changed to compute line number using the ExpressionRangeInfo.
      (JSC::CodeBlock::columnNumberForBytecodeOffset): Added
        - Changed to compute column number using the ExpressionRangeInfo.
      (JSC::CodeBlock::expressionRangeForBytecodeOffset):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::firstLineColumnOffset):
      (JSC::GlobalCodeBlock::GlobalCodeBlock):
        - Plumbed firstLineColumnOffset through to the super class.
      (JSC::ProgramCodeBlock::ProgramCodeBlock):
        - Plumbed firstLineColumnOffset through to the super class.
      (JSC::EvalCodeBlock::EvalCodeBlock):
        - Plumbed firstLineColumnOffset through to the super class.
          But for EvalCodeBlocks, the firstLineColumnOffset is always 1
          because we're starting with a new source string with no start
          offset.
      (JSC::FunctionCodeBlock::FunctionCodeBlock):
        - Plumbed firstLineColumnOffset through to the super class.
      
      * bytecode/ExpressionRangeInfo.h:
        - Added modes for encoding line and column into a single 30-bit
          unsigned. The encoding is in 1 of 3 modes:
          1. FatLineMode: 22-bit line, 8-bit column
          2. FatColumnMode: 8-bit line, 22-bit column
          3. FatLineAndColumnMode: 32-bit line, 32-bit column
      (JSC::ExpressionRangeInfo::encodeFatLineMode): Added.
        - Encodes line and column into the 30-bit position using FatLine mode.
      (JSC::ExpressionRangeInfo::encodeFatColumnMode): Added.
        - Encodes line and column into the 30-bit position using FatColumn mode.
      (JSC::ExpressionRangeInfo::decodeFatLineMode): Added.
        - Decodes the FatLine mode 30-bit position into line and column.
      (JSC::ExpressionRangeInfo::decodeFatColumnMode): Added.
        - Decodes the FatColumn mode 30-bit position into line and column.
      
      * bytecode/UnlinkedCodeBlock.cpp:
      (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        - Plumbed startColumn through.
      (JSC::UnlinkedFunctionExecutable::link):
        - Plumbed startColumn through.
      (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
        - Computes a line number using the new way.
      (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
        - Added decoding of line and column.
        - Added handling of the case when we do not find a fitting expression
          range info for a specified bytecodeOffset. This only happens if the
          bytecodeOffset is below the first expression range info. In that
          case, we'll use the first expression range info entry.
      (JSC::UnlinkedCodeBlock::addExpressionInfo):
        - Added encoding of line and column.
      
      * bytecode/UnlinkedCodeBlock.h:
        - Added m_expressionInfoFatPositions in RareData.
      (JSC::UnlinkedFunctionExecutable::functionStartColumn):
      (JSC::UnlinkedCodeBlock::shrinkToFit):
        - Removed obsoleted m_lineInfo.
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitCall): Plumbed line and lineStart through.
      (JSC::BytecodeGenerator::emitCallEval): Plumbed line and lineStart through.
      (JSC::BytecodeGenerator::emitCallVarargs): Plumbed line and lineStart through.
      (JSC::BytecodeGenerator::emitConstruct): Plumbed line and lineStart through.
      (JSC::BytecodeGenerator::emitDebugHook): Plumbed lineStart through.
      * bytecompiler/BytecodeGenerator.h:
      (JSC::BytecodeGenerator::emitNode):
      (JSC::BytecodeGenerator::emitNodeInConditionContext):
        - Removed obsoleted m_lineInfo.
      (JSC::BytecodeGenerator::emitExpressionInfo):
        - Plumbed line and lineStart through.
        - Compute the line and column to be added to the expression range info.
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ThrowableExpressionData::emitThrowReferenceError):
      (JSC::ResolveNode::emitBytecode):
      (JSC::ArrayNode::toArgumentList):
      (JSC::BracketAccessorNode::emitBytecode):
      (JSC::DotAccessorNode::emitBytecode):
      (JSC::NewExprNode::emitBytecode):
      (JSC::EvalFunctionCallNode::emitBytecode):
      (JSC::FunctionCallValueNode::emitBytecode):
      (JSC::FunctionCallResolveNode::emitBytecode):
      (JSC::FunctionCallBracketNode::emitBytecode):
      (JSC::FunctionCallDotNode::emitBytecode):
      (JSC::CallFunctionCallDotNode::emitBytecode):
      (JSC::ApplyFunctionCallDotNode::emitBytecode):
      (JSC::PostfixNode::emitResolve):
      (JSC::PostfixNode::emitBracket):
      (JSC::PostfixNode::emitDot):
      (JSC::DeleteResolveNode::emitBytecode):
      (JSC::DeleteBracketNode::emitBytecode):
      (JSC::DeleteDotNode::emitBytecode):
      (JSC::PrefixNode::emitResolve):
      (JSC::PrefixNode::emitBracket):
      (JSC::PrefixNode::emitDot):
        - Plumbed line and lineStart through the above as needed.
      
      (JSC::UnaryOpNode::emitBytecode):
        - Added emission of an ExpressionRangeInfo for the UnaryOp node.
      
      (JSC::BinaryOpNode::emitStrcat):
      (JSC::ThrowableBinaryOpNode::emitBytecode):
      (JSC::InstanceOfNode::emitBytecode):
      (JSC::emitReadModifyAssignment):
      (JSC::ReadModifyResolveNode::emitBytecode):
      (JSC::AssignResolveNode::emitBytecode):
      (JSC::AssignDotNode::emitBytecode):
      (JSC::ReadModifyDotNode::emitBytecode):
      (JSC::AssignBracketNode::emitBytecode):
      (JSC::ReadModifyBracketNode::emitBytecode):
        - Plumbed line and lineStart through the above as needed.
      
      (JSC::ConstStatementNode::emitBytecode):
      (JSC::EmptyStatementNode::emitBytecode):
      (JSC::DebuggerStatementNode::emitBytecode):
      (JSC::ExprStatementNode::emitBytecode):
      (JSC::VarStatementNode::emitBytecode):
      (JSC::IfElseNode::emitBytecode):
      (JSC::DoWhileNode::emitBytecode):
      (JSC::WhileNode::emitBytecode):
      (JSC::ForNode::emitBytecode):
      (JSC::ForInNode::emitBytecode):
      (JSC::ContinueNode::emitBytecode):
      (JSC::BreakNode::emitBytecode):
      (JSC::ReturnNode::emitBytecode):
      (JSC::WithNode::emitBytecode):
      (JSC::SwitchNode::emitBytecode):
      (JSC::LabelNode::emitBytecode):
      (JSC::ThrowNode::emitBytecode):
      (JSC::TryNode::emitBytecode):
      (JSC::ProgramNode::emitBytecode):
      (JSC::EvalNode::emitBytecode):
      (JSC::FunctionBodyNode::emitBytecode):
        - Plumbed line and lineStart through the above as needed.
      
      * interpreter/Interpreter.cpp:
      (JSC::appendSourceToError):
        - Added line and column arguments for expressionRangeForBytecodeOffset().
      (JSC::StackFrame::computeLineAndColumn):
        - Replaces StackFrame::line() and StackFrame::column().
      (JSC::StackFrame::expressionInfo):
        - Added line and column arguments.
      (JSC::StackFrame::toString):
        - Changed to use the new StackFrame::computeLineAndColumn().
      (JSC::Interpreter::getStackTrace):
        - Added the needed firstLineColumnOffset arg for the StackFrame.
      
      * interpreter/Interpreter.h:
      * parser/ASTBuilder.h:
      (JSC::ASTBuilder::BinaryOpInfo::BinaryOpInfo):
      (JSC::ASTBuilder::AssignmentInfo::AssignmentInfo):
      (JSC::ASTBuilder::createResolve):
      (JSC::ASTBuilder::createBracketAccess):
      (JSC::ASTBuilder::createDotAccess):
      (JSC::ASTBuilder::createRegExp):
      (JSC::ASTBuilder::createNewExpr):
      (JSC::ASTBuilder::createAssignResolve):
      (JSC::ASTBuilder::createFunctionExpr):
      (JSC::ASTBuilder::createFunctionBody):
      (JSC::ASTBuilder::createGetterOrSetterProperty):
      (JSC::ASTBuilder::createFuncDeclStatement):
      (JSC::ASTBuilder::createBlockStatement):
      (JSC::ASTBuilder::createExprStatement):
      (JSC::ASTBuilder::createIfStatement):
      (JSC::ASTBuilder::createForLoop):
      (JSC::ASTBuilder::createForInLoop):
      (JSC::ASTBuilder::createVarStatement):
      (JSC::ASTBuilder::createReturnStatement):
      (JSC::ASTBuilder::createBreakStatement):
      (JSC::ASTBuilder::createContinueStatement):
      (JSC::ASTBuilder::createTryStatement):
      (JSC::ASTBuilder::createSwitchStatement):
      (JSC::ASTBuilder::createWhileStatement):
      (JSC::ASTBuilder::createDoWhileStatement):
      (JSC::ASTBuilder::createLabelStatement):
      (JSC::ASTBuilder::createWithStatement):
      (JSC::ASTBuilder::createThrowStatement):
      (JSC::ASTBuilder::createDebugger):
      (JSC::ASTBuilder::createConstStatement):
      (JSC::ASTBuilder::appendBinaryExpressionInfo):
      (JSC::ASTBuilder::appendUnaryToken):
      (JSC::ASTBuilder::unaryTokenStackLastStart):
      (JSC::ASTBuilder::unaryTokenStackLastLineStartPosition): Added.
      (JSC::ASTBuilder::assignmentStackAppend):
      (JSC::ASTBuilder::createAssignment):
      (JSC::ASTBuilder::setExceptionLocation):
      (JSC::ASTBuilder::makeDeleteNode):
      (JSC::ASTBuilder::makeFunctionCallNode):
      (JSC::ASTBuilder::makeBinaryNode):
      (JSC::ASTBuilder::makeAssignNode):
      (JSC::ASTBuilder::makePrefixNode):
      (JSC::ASTBuilder::makePostfixNode):.
        - Plumbed line, lineStart, and startColumn through the above as needed.
      
      * parser/Lexer.cpp:
      (JSC::::currentSourcePtr):
      (JSC::::setCode):
        - Added tracking for sourceoffset and lineStart.
      (JSC::::internalShift):
      (JSC::::parseIdentifier):
        - Added tracking for lineStart.
      (JSC::::parseIdentifierSlowCase):
      (JSC::::parseString):
        - Added tracking for lineStart.
      (JSC::::parseStringSlowCase):
      (JSC::::lex):
        - Added tracking for sourceoffset.
      (JSC::::sourceCode):
      * parser/Lexer.h:
      (JSC::Lexer::currentOffset):
      (JSC::Lexer::currentLineStartOffset):
      (JSC::Lexer::setOffset):
        - Added tracking for lineStart.
      (JSC::Lexer::offsetFromSourcePtr): Added. conversion function.
      (JSC::Lexer::sourcePtrFromOffset): Added. conversion function.
      (JSC::Lexer::setOffsetFromSourcePtr):
      (JSC::::lexExpectIdentifier):
        - Added tracking for sourceoffset and lineStart.
      
      * parser/NodeConstructors.h:
      (JSC::Node::Node):
      (JSC::ResolveNode::ResolveNode):
      (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
      (JSC::FunctionCallValueNode::FunctionCallValueNode):
      (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
      (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
      (JSC::FunctionCallDotNode::FunctionCallDotNode):
      (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
      (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
      (JSC::PostfixNode::PostfixNode):
      (JSC::DeleteResolveNode::DeleteResolveNode):
      (JSC::DeleteBracketNode::DeleteBracketNode):
      (JSC::DeleteDotNode::DeleteDotNode):
      (JSC::PrefixNode::PrefixNode):
      (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
      (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
      (JSC::AssignBracketNode::AssignBracketNode):
      (JSC::AssignDotNode::AssignDotNode):
      (JSC::ReadModifyDotNode::ReadModifyDotNode):
      (JSC::AssignErrorNode::AssignErrorNode):
      (JSC::WithNode::WithNode):
      (JSC::ForInNode::ForInNode):
        - Plumbed line and lineStart through the above as needed.
      * parser/Nodes.cpp:
      (JSC::StatementNode::setLoc): Plumbed lineStart.
      (JSC::ScopeNode::ScopeNode): Plumbed lineStart.
      (JSC::ProgramNode::ProgramNode): Plumbed startColumn.
      (JSC::ProgramNode::create): Plumbed startColumn.
      (JSC::EvalNode::create):
      (JSC::FunctionBodyNode::FunctionBodyNode): Plumbed startColumn.
      (JSC::FunctionBodyNode::create): Plumbed startColumn.
      * parser/Nodes.h:
      (JSC::Node::startOffset):
      (JSC::Node::lineStartOffset): Added.
      (JSC::StatementNode::firstLine):
      (JSC::StatementNode::lastLine):
      (JSC::ThrowableExpressionData::ThrowableExpressionData):
      (JSC::ThrowableExpressionData::setExceptionSourceCode):
      (JSC::ThrowableExpressionData::divotStartOffset):
      (JSC::ThrowableExpressionData::divotEndOffset):
      (JSC::ThrowableExpressionData::divotLine):
      (JSC::ThrowableExpressionData::divotLineStart):
      (JSC::ThrowableSubExpressionData::ThrowableSubExpressionData):
      (JSC::ThrowableSubExpressionData::setSubexpressionInfo):
      (JSC::ThrowableSubExpressionData::subexpressionDivot):
      (JSC::ThrowableSubExpressionData::subexpressionStartOffset):
      (JSC::ThrowableSubExpressionData::subexpressionEndOffset):
      (JSC::ThrowableSubExpressionData::subexpressionLine):
      (JSC::ThrowableSubExpressionData::subexpressionLineStart):
      (JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData):
      (JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo):
      (JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot):
      (JSC::ThrowablePrefixedSubExpressionData::subexpressionStartOffset):
      (JSC::ThrowablePrefixedSubExpressionData::subexpressionEndOffset):
      (JSC::ThrowablePrefixedSubExpressionData::subexpressionLine):
      (JSC::ThrowablePrefixedSubExpressionData::subexpressionLineStart):
      (JSC::ScopeNode::startStartOffset):
      (JSC::ScopeNode::startLineStartOffset):
      (JSC::ProgramNode::startColumn):
      (JSC::EvalNode::startColumn):
      (JSC::FunctionBodyNode::startColumn):
        - Plumbed line and lineStart through the above as needed.
      * parser/Parser.cpp:
      (JSC::::Parser):
      (JSC::::parseSourceElements):
      (JSC::::parseVarDeclarationList):
      (JSC::::parseConstDeclarationList):
      (JSC::::parseForStatement):
      (JSC::::parseBreakStatement):
      (JSC::::parseContinueStatement):
      (JSC::::parseReturnStatement):
      (JSC::::parseThrowStatement):
      (JSC::::parseWithStatement):
        - Plumbed line and lineStart through the above as needed.
      (JSC::::parseFunctionBody):
        - Plumbed startColumn.
      (JSC::::parseFunctionInfo):
      (JSC::::parseFunctionDeclaration):
      (JSC::LabelInfo::LabelInfo):
      (JSC::::parseExpressionOrLabelStatement):
      (JSC::::parseAssignmentExpression):
      (JSC::::parseBinaryExpression):
      (JSC::::parseProperty):
      (JSC::::parseObjectLiteral):
      (JSC::::parsePrimaryExpression):
      (JSC::::parseMemberExpression):
      (JSC::::parseUnaryExpression):
        - Plumbed line, lineStart, startColumn through the above as needed.
      * parser/Parser.h:
      (JSC::Parser::next):
      (JSC::Parser::nextExpectIdentifier):
      (JSC::Parser::tokenStart):
      (JSC::Parser::tokenColumn):
      (JSC::Parser::tokenEnd):
      (JSC::Parser::tokenLineStart):
      (JSC::Parser::lastTokenLine):
      (JSC::Parser::lastTokenLineStart):
      (JSC::::parse):
      * parser/ParserTokens.h:
      (JSC::JSTokenLocation::JSTokenLocation):
        - Plumbed lineStart.
      (JSC::JSTokenLocation::lineStartPosition):
      (JSC::JSTokenLocation::startPosition):
      (JSC::JSTokenLocation::endPosition):
      * parser/SourceCode.h:
      (JSC::SourceCode::SourceCode):
      (JSC::SourceCode::startColumn):
      (JSC::makeSource):
      (JSC::SourceCode::subExpression):
      * parser/SourceProvider.cpp: delete old code.
      * parser/SourceProvider.h: delete old code.
      * parser/SourceProviderCacheItem.h:
      (JSC::SourceProviderCacheItem::closeBraceToken):
      (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        - Plumbed lineStart.
      * parser/SyntaxChecker.h:
      (JSC::SyntaxChecker::makeFunctionCallNode):
      (JSC::SyntaxChecker::makeAssignNode):
      (JSC::SyntaxChecker::makePrefixNode):
      (JSC::SyntaxChecker::makePostfixNode):
      (JSC::SyntaxChecker::makeDeleteNode):
      (JSC::SyntaxChecker::createResolve):
      (JSC::SyntaxChecker::createBracketAccess):
      (JSC::SyntaxChecker::createDotAccess):
      (JSC::SyntaxChecker::createRegExp):
      (JSC::SyntaxChecker::createNewExpr):
      (JSC::SyntaxChecker::createAssignResolve):
      (JSC::SyntaxChecker::createFunctionExpr):
      (JSC::SyntaxChecker::createFunctionBody):
      (JSC::SyntaxChecker::createFuncDeclStatement):
      (JSC::SyntaxChecker::createForInLoop):
      (JSC::SyntaxChecker::createReturnStatement):
      (JSC::SyntaxChecker::createBreakStatement):
      (JSC::SyntaxChecker::createContinueStatement):
      (JSC::SyntaxChecker::createWithStatement):
      (JSC::SyntaxChecker::createLabelStatement):
      (JSC::SyntaxChecker::createThrowStatement):
      (JSC::SyntaxChecker::createGetterOrSetterProperty):
      (JSC::SyntaxChecker::appendBinaryExpressionInfo):
      (JSC::SyntaxChecker::operatorStackPop):
        - Made SyntaxChecker prototype changes to match ASTBuilder due to new
          args added for plumbing line, lineStart, and startColumn.
      * runtime/CodeCache.cpp:
      (JSC::CodeCache::generateBytecode):
      (JSC::CodeCache::getCodeBlock):
        - Plumbed startColumn.
      * runtime/Executable.cpp:
      (JSC::FunctionExecutable::FunctionExecutable):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::produceCodeBlockFor):
      (JSC::FunctionExecutable::fromGlobalCode):
        - Plumbed startColumn.
      * runtime/Executable.h:
      (JSC::ScriptExecutable::startColumn):
      (JSC::ScriptExecutable::recordParse):
      (JSC::FunctionExecutable::create):
        - Plumbed startColumn.
      
      Source/WebCore: 
      
      Test: fast/js/line-column-numbers.html
      
      Updated the bindings to use StackFrame::computeLineAndColumn(). The old
      StackFrame::line() and StackFrame::column() has been removed. The new
      algorithm always computes the 2 values together anyway. Hence it is more
      efficient to return them as a pair instead of doing the same computation
      twice for each half of the result.
      
      * bindings/js/ScriptCallStackFactory.cpp:
      (WebCore::createScriptCallStack):
      (WebCore::createScriptCallStackFromException):
      * bindings/js/ScriptSourceCode.h:
      (WebCore::ScriptSourceCode::ScriptSourceCode):
      
      LayoutTests: 
      
      The fix now computes line and column numbers more accurately. As a result,
      some of the test results need to be re-baselined. Among other fixes, one
      major source of difference is that the old code was incorrectly computing
      0-based column numbers. This has now been fixed to be 1-based.
      Note: line numbers were always 1-based.
      
      Also added a new test: fast/js/line-column-numbers.html, which tests line
      and column numbers for source code in various configurations.
      
      * editing/execCommand/outdent-blockquote-test1-expected.txt:
      * editing/execCommand/outdent-blockquote-test2-expected.txt:
      * editing/execCommand/outdent-blockquote-test3-expected.txt:
      * editing/execCommand/outdent-blockquote-test4-expected.txt:
      * editing/pasteboard/copy-paste-float-expected.txt:
      * editing/pasteboard/paste-blockquote-before-blockquote-expected.txt:
      * editing/pasteboard/paste-double-nested-blockquote-before-blockquote-expected.txt:
      * fast/dom/Window/window-resize-contents-expected.txt:
      * fast/events/remove-target-with-shadow-in-drag-expected.txt:
      * fast/js/line-column-numbers-expected.txt: Added.
      * fast/js/line-column-numbers.html: Added.
      * fast/js/script-tests/line-column-numbers.js: Added.
      (try.doThrow4b):
      (doThrow5b.try.innerFunc):
      (doThrow5b):
      (doThrow6b.try.innerFunc):
      (doThrow6b):
      (catch):
      (try.doThrow11b):
      (try.doThrow14b):
      * fast/js/stack-trace-expected.txt:
      * inspector/console/console-url-line-column-expected.txt:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152494 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5b45f90a
  7. 25 Jun, 2013 1 commit
    • rniwa@webkit.org's avatar
      JSString should remember AtomicString · 85e57d89
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=117386
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore:
      
      Added JSValue::toAtomicString and JSString::atomicString. These two functions allow WebCore to update
      JSString's m_value to set isAtomic flag and avoid the AtomicStringTable lookups in subsequent attempts
      to obtain the AtomicString of the same value.
      
      * runtime/JSCJSValue.h:
      * runtime/JSString.h:
      (JSC::JSString::atomicString):
      (JSC::JSValue::toAtomicString):
      
      Source/WebCore:
      
      Added "Atomic" attribute as a WebKit extension to WebIDL, and deployed it in Element.idl and Node.idl so that
      the binding code can use newly added JSValue::toAtomic to update JSString's m_value.
      
      * bindings/js/JSDOMBinding.cpp:
      (WebCore::valueToAtomicStringWithNullCheck): Added.
      (WebCore::valueToAtomicStringWithUndefinedOrNullCheck): Added.
      
      * bindings/js/JSDOMBinding.h:
      
      * bindings/scripts/CodeGeneratorJS.pm:
      (GetNativeTypeFromSignature): Return const AtomicString& when either Atomic attribute is specified or the type is
      Reflect. Note that setAttribute and getAttribute both use AtomicString for all arguments.
      (JSValueToNative): Use AtomicString equivalents when possible when converting DOMString to a WebCore object.
      
      * bindings/scripts/IDLAttributes.txt: Added "Atomic" attribute.
      
      * bindings/scripts/test/JS/JSTestObj.cpp: Baselined test cases.
      (WebCore::setJSTestObjReflectedStringAttr):
      (WebCore::setJSTestObjReflectedURLAttr):
      (WebCore::setJSTestObjReflectedCustomURLAttr):
      
      * dom/Document.idl:
      * dom/Element.idl:
      * dom/Node.idl:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151978 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      85e57d89
  8. 21 Jun, 2013 1 commit
    • mark.lam@apple.com's avatar
      Source/JavaScriptCore: Introducing the VMStackBounds class. · bd1385d3
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=117862.
      
      Reviewed by Geoffrey Garen.
      
      - Removed Interpreter::StackPolicy.
      - The new VMStackBounds will take over choosing the appropriate stack
        size requirements, and invoking the underlying WTF::StackBounds to
        to the real bounds check.
      - VMStackBounds will now be used universally throughout JSC instead of
        WTF::StackBounds.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      * bytecompiler/BytecodeGenerator.h:
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::execute):
      (JSC::Interpreter::executeCall):
      (JSC::Interpreter::executeConstruct):
      (JSC::Interpreter::prepareForRepeatCall):
      * interpreter/Interpreter.h:
      (JSC::Interpreter::isInErrorHandlingMode):
      * parser/Parser.cpp:
      (JSC::::Parser):
      * parser/Parser.h:
      * runtime/StringRecursionChecker.h:
      (JSC::StringRecursionChecker::performCheck):
      * runtime/VMStackBounds.h: Added.
      (JSC::VMStackBounds::VMStackBounds):
      (JSC::VMStackBounds::isSafeToRecurse):
      (JSC::VMStackBounds::requiredCapacity):
      
      LayoutTests: Reverting failure expectation for fast/xmlhttprequest/xmlhttprequest-recursive-sync-event.html.
      https://bugs.webkit.org/show_bug.cgi?id=117862.
      
      Reviewed by Geoffrey Garen.
      
      * platform/mac/TestExpectations:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151869 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bd1385d3
  9. 20 Jun, 2013 1 commit
    • mikhail.pozdnyakov@intel.com's avatar
      HashSet: reverse the order of the template arguments at alternate 'find',... · aa51fa60
      mikhail.pozdnyakov@intel.com authored
      HashSet: reverse the order of the template arguments at alternate 'find', 'contains' and 'add' methods
      https://bugs.webkit.org/show_bug.cgi?id=117830
      
      Reviewed by Anders Carlsson.
      
      The order of the template arguments at HashSet alternate 'find', 'contains' and
      'add' methods is reversed so that callers can just pass the translator
      and let the compiler deduce input argument type.
      
      Source/JavaScriptCore:
      
      * runtime/Identifier.h:
      (JSC::IdentifierTable::add):
      
      Source/WebCore:
      
      No new tests. No new functionality.
      
      * dom/QualifiedName.cpp:
      (WebCore::QualifiedName::QualifiedName):
      * platform/graphics/cg/SubimageCacheWithTimer.cpp:
      (WebCore::SubimageCacheWithTimer::getSubimage):
      * svg/SVGAElement.cpp:
      (WebCore::SVGAElement::isSupportedAttribute):
      * svg/SVGAnimateMotionElement.cpp:
      (WebCore::SVGAnimateMotionElement::isSupportedAttribute):
      * svg/SVGAnimateTransformElement.cpp:
      (WebCore::SVGAnimateTransformElement::isSupportedAttribute):
      * svg/SVGAnimationElement.cpp:
      (WebCore::SVGAnimationElement::isSupportedAttribute):
      * svg/SVGCircleElement.cpp:
      (WebCore::SVGCircleElement::isSupportedAttribute):
      * svg/SVGClipPathElement.cpp:
      (WebCore::SVGClipPathElement::isSupportedAttribute):
      * svg/SVGComponentTransferFunctionElement.cpp:
      (WebCore::SVGComponentTransferFunctionElement::isSupportedAttribute):
      * svg/SVGCursorElement.cpp:
      (WebCore::SVGCursorElement::isSupportedAttribute):
      * svg/SVGEllipseElement.cpp:
      (WebCore::SVGEllipseElement::isSupportedAttribute):
      * svg/SVGFEBlendElement.cpp:
      (WebCore::SVGFEBlendElement::isSupportedAttribute):
      * svg/SVGFEColorMatrixElement.cpp:
      (WebCore::SVGFEColorMatrixElement::isSupportedAttribute):
      * svg/SVGFEComponentTransferElement.cpp:
      (WebCore::SVGFEComponentTransferElement::isSupportedAttribute):
      * svg/SVGFECompositeElement.cpp:
      (WebCore::SVGFECompositeElement::isSupportedAttribute):
      * svg/SVGFEConvolveMatrixElement.cpp:
      (WebCore::SVGFEConvolveMatrixElement::isSupportedAttribute):
      * svg/SVGFEDiffuseLightingElement.cpp:
      (WebCore::SVGFEDiffuseLightingElement::isSupportedAttribute):
      * svg/SVGFEDisplacementMapElement.cpp:
      (WebCore::SVGFEDisplacementMapElement::isSupportedAttribute):
      * svg/SVGFEDropShadowElement.cpp:
      (WebCore::SVGFEDropShadowElement::isSupportedAttribute):
      * svg/SVGFEGaussianBlurElement.cpp:
      (WebCore::SVGFEGaussianBlurElement::isSupportedAttribute):
      * svg/SVGFEImageElement.cpp:
      (WebCore::SVGFEImageElement::isSupportedAttribute):
      * svg/SVGFELightElement.cpp:
      (WebCore::SVGFELightElement::isSupportedAttribute):
      * svg/SVGFEMergeNodeElement.cpp:
      (WebCore::SVGFEMergeNodeElement::isSupportedAttribute):
      * svg/SVGFEMorphologyElement.cpp:
      (WebCore::SVGFEMorphologyElement::isSupportedAttribute):
      * svg/SVGFEOffsetElement.cpp:
      (WebCore::SVGFEOffsetElement::isSupportedAttribute):
      * svg/SVGFESpecularLightingElement.cpp:
      (WebCore::SVGFESpecularLightingElement::isSupportedAttribute):
      * svg/SVGFETileElement.cpp:
      (WebCore::SVGFETileElement::isSupportedAttribute):
      * svg/SVGFETurbulenceElement.cpp:
      (WebCore::SVGFETurbulenceElement::isSupportedAttribute):
      * svg/SVGFilterElement.cpp:
      (WebCore::SVGFilterElement::isSupportedAttribute):
      (WebCore::SVGFilterElement::childShouldCreateRenderer):
      * svg/SVGFilterPrimitiveStandardAttributes.cpp:
      (WebCore::SVGFilterPrimitiveStandardAttributes::isSupportedAttribute):
      * svg/SVGForeignObjectElement.cpp:
      (WebCore::SVGForeignObjectElement::isSupportedAttribute):
      * svg/SVGGElement.cpp:
      (WebCore::SVGGElement::isSupportedAttribute):
      * svg/SVGGradientElement.cpp:
      (WebCore::SVGGradientElement::isSupportedAttribute):
      * svg/SVGImageElement.cpp:
      (WebCore::SVGImageElement::isSupportedAttribute):
      * svg/SVGLineElement.cpp:
      (WebCore::SVGLineElement::isSupportedAttribute):
      * svg/SVGLinearGradientElement.cpp:
      (WebCore::SVGLinearGradientElement::isSupportedAttribute):
      * svg/SVGMPathElement.cpp:
      (WebCore::SVGMPathElement::isSupportedAttribute):
      * svg/SVGMarkerElement.cpp:
      (WebCore::SVGMarkerElement::isSupportedAttribute):
      * svg/SVGMaskElement.cpp:
      (WebCore::SVGMaskElement::isSupportedAttribute):
      * svg/SVGPathElement.cpp:
      (WebCore::SVGPathElement::isSupportedAttribute):
      * svg/SVGPatternElement.cpp:
      (WebCore::SVGPatternElement::isSupportedAttribute):
      * svg/SVGPolyElement.cpp:
      (WebCore::SVGPolyElement::isSupportedAttribute):
      * svg/SVGRadialGradientElement.cpp:
      (WebCore::SVGRadialGradientElement::isSupportedAttribute):
      * svg/SVGRectElement.cpp:
      (WebCore::SVGRectElement::isSupportedAttribute):
      * svg/SVGScriptElement.cpp:
      (WebCore::SVGScriptElement::isSupportedAttribute):
      * svg/SVGStopElement.cpp:
      (WebCore::SVGStopElement::isSupportedAttribute):
      * svg/SVGStyleElement.cpp:
      (WebCore::SVGStyleElement::isSupportedAttribute):
      * svg/SVGStyledTransformableElement.cpp:
      (WebCore::SVGStyledTransformableElement::isSupportedAttribute):
      * svg/SVGSymbolElement.cpp:
      (WebCore::SVGSymbolElement::isSupportedAttribute):
      * svg/SVGTRefElement.cpp:
      (WebCore::SVGTRefElement::isSupportedAttribute):
      * svg/SVGTextContentElement.cpp:
      (WebCore::SVGTextContentElement::isSupportedAttribute):
      * svg/SVGTextElement.cpp:
      (WebCore::SVGTextElement::isSupportedAttribute):
      * svg/SVGTextPathElement.cpp:
      (WebCore::SVGTextPathElement::isSupportedAttribute):
      * svg/SVGTextPositioningElement.cpp:
      (WebCore::SVGTextPositioningElement::isSupportedAttribute):
      * svg/SVGUseElement.cpp:
      (WebCore::SVGUseElement::isSupportedAttribute):
      (WebCore::isDisallowedElement):
      * svg/SVGViewElement.cpp:
      (WebCore::SVGViewElement::isSupportedAttribute):
      * svg/animation/SVGSMILElement.cpp:
      (WebCore::SVGSMILElement::isSupportedAttribute):
      
      Source/WTF:
      
      * wtf/HashSet.h:
      * wtf/text/AtomicString.cpp:
      (WTF::addToStringTable):
      (WTF::findString):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151800 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      aa51fa60
  10. 14 Jun, 2013 1 commit
    • rniwa@webkit.org's avatar
      Function names on Object.prototype should be common identifiers · 62475f81
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=117614
      
      Reviewed by Darin Adler.
      
      Source/JavaScriptCore: 
      
      Patch written by Sam Weinig. Make Object's prototype function names common identififers since they're used frequently.
      
      * runtime/CommonIdentifiers.h:
      * runtime/FunctionConstructor.cpp:
      (JSC::constructFunction):
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::reset):
      * runtime/JSObject.h:
      * runtime/ObjectPrototype.cpp:
      (JSC::ObjectPrototype::finishCreation):
      * runtime/StringPrototype.cpp:
      (JSC::StringPrototype::finishCreation):
      
      Source/WebCore: 
      
      Use the added common identifiers.
      
      * bindings/js/JSDOMWindowBase.cpp:
      (WebCore::JSDOMWindowBase::finishCreation):
      (WebCore::JSDOMWindowBase::updateDocument):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151605 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      62475f81
  11. 13 Jun, 2013 1 commit
  12. 10 Jun, 2013 1 commit
  13. 04 Jun, 2013 1 commit
    • zandobersek@gmail.com's avatar
      [JSC] Test262 15.5.4.9_3 test is failing · 5dea8eb9
      zandobersek@gmail.com authored
      https://bugs.webkit.org/show_bug.cgi?id=116789
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      Bring the String.prototype.localeCompare behavior in line wit ES5 15.9.4.9.
      If method is not given enough arguments, the minimal amount of arguments must be assumed, with their value being undefined.
      The first argument to localeCompare, in its string form, is used as the 'that' string that's used in the comparison.
      Therefor, when calling str.localeCompare() or str.localeCompare(undefined), the first argument is `undefined` and the
      string "undefined" is used as the string to which value of str is compared.
      
      * runtime/StringPrototype.cpp:
      (JSC::stringProtoFuncLocaleCompare): Remove the early return in case of no given arguments to achieve the desired behavior.
      
      LayoutTests: 
      
      Add the 15.5.4.9_3 test from the test262 test suite to cover proper behavior of String.prototype.localeCompare
      when no arguments are passed to it. The test tests that str.localeCompare() and str.localeCompare(undefined) work
      the same way, i.e. using the string 'undefined' as the string with which str is compared (meaning that the first argument
      defaults to 'undefined' when not given).
      
      The test and the rationale behind it originates from bug #1245 in ECMAScript Bugzilla.
      https://bugs.ecmascript.org/show_bug.cgi?id=1245
      
      * fast/js/kde/StringObject-expected.txt: Update the baseline.
      * fast/js/kde/script-tests/StringObject.js: Update the expected return of the localeCompare test case with no arguments. -1 is
      expected as the missing argument defaults to 'undefined' and is then compared to the string on which localeCompare is called.
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.9_String.prototype.localeCompare/S15.5.4.9_3-expected.txt: Added.
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.9_String.prototype.localeCompare/S15.5.4.9_3.html: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151159 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5dea8eb9
  14. 03 Jun, 2013 1 commit
    • commit-queue@webkit.org's avatar
      [EFL] Implement GCActivityCallback · 21e8c5f0
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=95923
      
      Patch by Hojong Han <hojong.han@samsung.com> on 2013-06-03
      Reviewed by Geoffrey Garen.
      
      Implements the activity triggered garbage collector.
      Additional GCs can be triggered by platfrom timer.
      It has sort of compaction effect not to make JSC heap grow fast
      so that memory usage becomes lower than usual.
      
      * PlatformEfl.cmake: Added.
      * heap/HeapTimer.cpp:
      (JSC):
      (JSC::HeapTimer::HeapTimer):
      (JSC::HeapTimer::~HeapTimer):
      (JSC::HeapTimer::add):
      (JSC::HeapTimer::stop):
      (JSC::HeapTimer::timerEvent):
      * heap/HeapTimer.h:
      (HeapTimer):
      * jsc.cpp:
      (main):
      * runtime/GCActivityCallback.cpp:
      (JSC):
      (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
      (JSC::DefaultGCActivityCallback::scheduleTimer):
      (JSC::DefaultGCActivityCallback::cancelTimer):
      (JSC::DefaultGCActivityCallback::didAllocate):
      * runtime/GCActivityCallback.h:
      (GCActivityCallback):
      (JSC::GCActivityCallback::GCActivityCallback):
      (DefaultGCActivityCallback):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151149 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      21e8c5f0
  15. 28 May, 2013 2 commits
    • barraclough@apple.com's avatar
      String(new Date(2010,10,1)) is wrong in KRAT, YAKT · 2e1fc206
      barraclough@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106750
      
      Reviewed by Darin Adler.
      
      * runtime/JSDateMath.cpp:
      (JSC::msToGregorianDateTime):
          - Additional review comment fix.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150835 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2e1fc206
    • barraclough@apple.com's avatar
      String(new Date(2010,10,1)) is wrong in KRAT, YAKT · d4900677
      barraclough@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106750
      
      Reviewed by Darin Adler.
      
      First part of a fix, simplfy date handling code, instead of operating separately
      on the UTC-standard and standard-DST offsets, just generate a combined UTC-local
      offset (this is what we actually need, and what the OS gives us).
      
      ../JavaScriptCore: 
      
      * runtime/JSDateMath.cpp:
      (JSC::getLocalTimeOffset):
          - removed getUTCOffset, converted getDSTOffset -> getLocalTimeOffset
      (JSC::gregorianDateTimeToMS):
      (JSC::msToGregorianDateTime):
      (JSC::parseDateFromNullTerminatedCharacters):
          - call getLocalTimeOffset instead of getUTCOffset/getDSTOffset
      * runtime/VM.cpp:
      (JSC::VM::resetDateCache):
          - removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache
      * runtime/VM.h:
      (JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
      (JSC::LocalTimeOffsetCache::reset):
      (LocalTimeOffsetCache):
          - removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache
      
      ../WTF: 
      
      * wtf/DateMath.cpp:
      (WTF::calculateUTCOffset):
      (WTF::calculateDSTOffset):
          - made static, now not called from outside of this file.
      (WTF::calculateLocalTimeOffset):
          - This combines the 2038 related adjustment from calculateDSTOffset with the
            maxUnixTime adjustment from calculateDSTOffsetSimple. Then, if HAVE(TM_GMTOFF)
            just call getLocalTime, if not use calculateUTCOffset/calculateDSTOffset.
      (WTF::parseDateFromNullTerminatedCharacters):
          - call calculateLocalTimeOffset instead of calculateUTCOffset/calculateDSTOffset
      * wtf/DateMath.h:
      (WTF::LocalTimeOffset::LocalTimeOffset):
      (LocalTimeOffset):
      (WTF::LocalTimeOffset::operator==):
          - new struct type, a tuple of UTC-local offset & isDST flag.
          - replaced calculateUTCOffset/calculateDSTOffset with calculateLocalTimeOffset
      * wtf/GregorianDateTime.cpp:
      (WTF::GregorianDateTime::setToCurrentLocalTime):
          - call calculateLocalTimeOffset instead of calculateUTCOffset/calculateDSTOffset
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150833 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d4900677
  16. 24 May, 2013 1 commit
    • fpizlo@apple.com's avatar
      We broke !(0/0) · 2cc10477
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=116736
      
      Reviewed by Gavin Barraclough.
      
      Source/JavaScriptCore: 
      
      * parser/ASTBuilder.h:
      (JSC::ASTBuilder::createLogicalNot):
      * runtime/JSCJSValueInlines.h:
      (JSC::JSValue::pureToBoolean):
      
      Source/WTF: 
      
      * wtf/MathExtras.h:
      (isNotZeroAndOrdered):
      (isZeroOrUnordered):
      
      LayoutTests: 
      
      * fast/js/constant-fold-not-nan.html: Added.
      * fast/js/constant-fold-not-nan-expected.txt: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/constant-fold-not-nan.js: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150659 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2cc10477
  17. 15 May, 2013 1 commit
    • oliver@apple.com's avatar
      RefCountedArray needs to use vector initialisers for its backing store · 90a10c58
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=116194
      
      Reviewed by Gavin Barraclough.
      
      Source/JavaScriptCore:
      
      Use an out of line function to clear the exception stack to avoid
      needing to include otherwise unnecessary headers all over the place.
      
      Everything else is just being updated to use that.
      
      * bytecompiler/BytecodeGenerator.cpp:
      * interpreter/CallFrame.h:
      (JSC::ExecState::clearSupplementaryExceptionInfo):
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::addStackTraceIfNecessary):
      (JSC::Interpreter::throwException):
      * runtime/JSGlobalObject.cpp:
      (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):
      * runtime/VM.cpp:
      (JSC):
      (JSC::VM::clearExceptionStack):
      * runtime/VM.h:
      (VM):
      (JSC::VM::exceptionStack):
      
      Source/WebCore:
      
      Update to use new functions for operating on the exception stack.
      
      * bindings/js/ScriptCallStackFactory.cpp:
      (WebCore::createScriptCallStackFromException):
      
      Source/WTF:
      
      Use VectorOperations to operate on the backing store
      
      * wtf/RefCountedArray.h:
      (WTF::RefCountedArray::RefCountedArray):
      (WTF::RefCountedArray::operator=):
      (WTF::RefCountedArray::~RefCountedArray):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150160 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      90a10c58
  18. 13 May, 2013 1 commit
  19. 12 May, 2013 1 commit
    • andersca@apple.com's avatar
      Stop including UnusedParam.h · ed9bde7b
      andersca@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=116003
      
      Reviewed by Sam Weinig.
      
      UnusedParam.h is empty now so there's no need to include it anymore.
      
      Source/JavaScriptCore:
      
      * API/APICast.h:
      * API/tests/JSNode.c:
      * API/tests/JSNodeList.c:
      * API/tests/minidom.c:
      * API/tests/testapi.c:
      * assembler/AbstractMacroAssembler.h:
      * assembler/MacroAssemblerCodeRef.h:
      * bytecode/CodeBlock.cpp:
      * heap/HandleStack.h:
      * interpreter/JSStackInlines.h:
      * jit/CompactJITCodeMap.h:
      * jit/ExecutableAllocator.h:
      * parser/SourceProvider.h:
      * runtime/DatePrototype.cpp:
      * runtime/JSNotAnObject.cpp:
      * runtime/JSSegmentedVariableObject.h:
      * runtime/JSVariableObject.h:
      * runtime/Options.cpp:
      * runtime/PropertyOffset.h:
      
      Source/WebCore:
      
      * Modules/encryptedmedia/CDMPrivateAVFoundation.mm:
      * Modules/indexeddb/IDBFactoryBackendImpl.cpp:
      * Modules/indexeddb/IDBObjectStore.cpp:
      * Modules/webdatabase/DatabaseServer.cpp:
      * Modules/webdatabase/DatabaseThread.cpp:
      * bindings/js/JSDOMWindowBase.cpp:
      * bindings/objc/DOMObject.mm:
      * css/CSSCursorImageValue.cpp:
      * css/DeprecatedStyleBuilder.cpp:
      * dom/EventDispatcher.cpp:
      * dom/Node.cpp:
      * editing/AlternativeTextController.h:
      * editing/Editor.cpp:
      * html/HTMLPlugInElement.cpp:
      * html/canvas/CanvasRenderingContext2D.cpp:
      * html/canvas/OESVertexArrayObject.h:
      * html/parser/HTMLConstructionSite.cpp:
      * html/parser/HTMLTokenizer.cpp:
      * html/track/InbandTextTrack.cpp:
      * inspector/InspectorCanvasInstrumentation.h:
      * inspector/InspectorConsoleInstrumentation.h:
      * inspector/InspectorController.cpp:
      * inspector/InspectorCounters.h:
      * inspector/InspectorDatabaseInstrumentation.h:
      * inspector/InspectorInstrumentation.h:
      * loader/DocumentThreadableLoader.cpp:
      * loader/PingLoader.cpp:
      * loader/appcache/ApplicationCacheGroup.cpp:
      * loader/cache/CachedResourceLoader.cpp:
      * loader/mac/DocumentLoaderMac.cpp:
      * page/ChromeClient.h:
      * page/Console.cpp:
      * page/FrameView.cpp:
      * page/PageConsole.cpp:
      * page/animation/AnimationController.cpp:
      * page/animation/ImplicitAnimation.cpp:
      * page/animation/KeyframeAnimation.cpp:
      * platform/LocalizedStrings.cpp:
      * platform/ScrollAnimator.h:
      * platform/ThreadGlobalData.cpp:
      * platform/blackberry/AsyncFileSystemBlackBerry.cpp:
      * platform/graphics/Font.cpp:
      * platform/graphics/GlyphBuffer.h:
      * platform/graphics/Gradient.cpp:
      * platform/graphics/ShadowBlur.cpp:
      * platform/graphics/SimpleFontData.cpp:
      * platform/graphics/SimpleFontData.h:
      * platform/graphics/avfoundation/InbandTextTrackPrivateAVF.cpp:
      * platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
      * platform/graphics/avfoundation/cf/MediaPlayerPrivateAVFoundationCF.cpp:
      * platform/graphics/avfoundation/objc/InbandTextTrackPrivateAVFObjC.mm:
      * platform/graphics/avfoundation/objc/InbandTextTrackPrivateLegacyAVFObjC.mm:
      * platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
      * platform/graphics/blackberry/GradientBlackBerry.cpp:
      * platform/graphics/blackberry/GraphicsContextBlackBerry.cpp:
      * platform/graphics/ca/mac/PlatformCAAnimationMac.mm:
      * platform/graphics/ca/mac/PlatformCALayerMac.mm:
      * platform/graphics/ca/mac/WebTileLayer.mm:
      * platform/graphics/ca/win/PlatformCAAnimationWin.cpp:
      * platform/graphics/cg/GraphicsContextCG.cpp:
      * platform/graphics/cg/ImageBufferCG.cpp:
      * platform/graphics/cg/ImageSourceCG.cpp:
      * platform/graphics/clutter/PlatformClutterAnimation.cpp:
      * platform/graphics/filters/ValidatedCustomFilterOperation.cpp:
      * platform/graphics/gstreamer/GStreamerVersioning.cpp:
      * platform/graphics/mac/GraphicsContext3DMac.mm:
      * platform/graphics/mac/MediaPlayerPrivateQTKit.mm:
      * platform/graphics/mac/SimpleFontDataMac.mm:
      * platform/graphics/mac/WebGLLayer.mm:
      * platform/graphics/mac/WebLayer.mm:
      * platform/graphics/mac/WebTiledLayer.mm:
      * platform/graphics/opengl/GraphicsContext3DOpenGL.cpp:
      * platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp:
      * platform/graphics/qt/GraphicsContext3DQt.cpp:
      * platform/graphics/texmap/TextureMapper.h:
      * platform/graphics/wince/ImageBufferWinCE.cpp:
      * platform/mac/PasteboardMac.mm:
      * platform/mac/ScrollAnimatorMac.mm:
      * platform/mac/ScrollViewMac.mm:
      * platform/mac/ScrollbarThemeMac.mm:
      * platform/mac/SharedTimerMac.mm:
      * platform/mac/WebCoreFullScreenPlaceholderView.mm:
      * platform/mac/WebCoreObjCExtras.mm:
      * platform/mac/WebFontCache.mm:
      * platform/mac/WebVideoFullscreenController.mm:
      * platform/mac/WebVideoFullscreenHUDWindowController.mm:
      * platform/mac/WebWindowAnimation.mm:
      * platform/network/blackberry/CredentialStorageBlackBerry.cpp:
      * platform/network/cf/ResourceErrorCF.cpp:
      * platform/network/mac/CookieStorageMac.mm:
      * platform/network/mac/ResourceHandleMac.mm:
      * platform/network/win/ResourceHandleWin.cpp:
      * platform/text/TextEncodingDetectorICU.cpp:
      * rendering/RenderFlowThread.h:
      * rendering/RenderImage.cpp:
      * rendering/RenderLayer.cpp:
      * rendering/RenderObject.cpp:
      * rendering/RenderTreeAsText.cpp:
      * rendering/svg/RenderSVGResourceClipper.cpp:
      * rendering/svg/RenderSVGResourceFilter.cpp:
      * rendering/svg/RenderSVGResourceGradient.cpp:
      * rendering/svg/RenderSVGResourceMasker.cpp:
      * rendering/svg/SVGRenderSupport.cpp:
      * rendering/svg/SVGTextLayoutEngineSpacing.cpp:
      * workers/WorkerContext.cpp:
      * workers/WorkerScriptLoader.cpp:
      * xml/XMLHttpRequest.cpp:
      * xml/parser/XMLDocumentParserLibxml2.cpp:
      
      Source/WebKit/efl:
      
      * WebCoreSupport/DumpRenderTreeSupportEfl.cpp:
      * ewk/ewk_js.cpp:
      * ewk/ewk_security_origin.cpp:
      * ewk/ewk_view.cpp:
      * ewk/ewk_web_database.cpp:
      
      Source/WebKit/gtk:
      
      * webkit/webkitapplicationcache.cpp:
      
      Source/WebKit/mac:
      
      * Plugins/WebNetscapePluginEventHandlerCocoa.mm:
      * WebView/WebDashboardRegion.mm:
      * WebView/WebFullScreenController.mm:
      
      Source/WebKit/win:
      
      * WebSecurityOrigin.cpp:
      
      Source/WebKit2:
      
      * UIProcess/API/C/WKContext.cpp:
      * UIProcess/API/C/WKInspector.cpp:
      * UIProcess/API/C/WKPage.cpp:
      * UIProcess/API/efl/ewk_text_checker.cpp:
      * UIProcess/API/efl/ewk_view.cpp:
      * UIProcess/API/efl/tests/UnitTestUtils/EWK2UnitTestBase.cpp:
      * UIProcess/API/efl/tests/test_ewk2_view.cpp:
      * UIProcess/mac/WKFullScreenWindowController.mm:
      * WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
      * WebProcess/ResourceCache/WebResourceCacheManager.cpp:
      
      Source/WTF:
      
      * wtf/Atomics.h:
      * wtf/BoundsCheckedPointer.h:
      * wtf/DateMath.h:
      * wtf/FastMalloc.cpp:
      * wtf/NumberOfCores.cpp:
      * wtf/OSAllocator.h:
      * wtf/OSAllocatorPosix.cpp:
      * wtf/PageAllocation.h:
      * wtf/RefCounted.h:
      * wtf/TCSystemAlloc.cpp:
      * wtf/ThreadingPthreads.cpp:
      * wtf/Vector.h:
      * wtf/dtoa/cached-powers.cc:
      * wtf/dtoa/fixed-dtoa.cc:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149980 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ed9bde7b
  20. 09 May, 2013 2 commits
    • ch.dumez@sisa.samsung.com's avatar
      Unreviewed build fix after r149836. · a9a1b17b
      ch.dumez@sisa.samsung.com authored
      It broke at least EFL and GTK builds. Move new static members initialization
      outside the class. Those need to have a definition outside the class because
      their address is used (e.g. CodeCacheMap::nonGlobalWorkingSetMaxEntries).
      
      * runtime/CodeCache.cpp:
      (JSC):
      * runtime/CodeCache.h:
      (CodeCacheMap):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149850 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a9a1b17b
    • oliver@apple.com's avatar
      Code cache stores bogus var references for functions in eval code · 0c14001a
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115747
      
      Reviewed by Mark Hahnenberg.
      
      Source/JavaScriptCore:
      
      Non-global eval now uses a per-CodeBlock cache, and only use it
      when we're at the top of a function's scope.  This means that we
      will no longer cache the parsing of a single string across
      multiple functions, and we won't cache when we're nested inside
      constructs like |with| and |catch| where previously we would, which
      is good because caching in those cases is unsound.
      
      * bytecode/EvalCodeCache.h:
      (JSC):
      (JSC::EvalCodeCache::getSlow):
      (JSC::EvalCodeCache::get):
      * bytecode/UnlinkedCodeBlock.h:
      (JSC::UnlinkedCodeBlock::codeCacheForEval):
      (UnlinkedCodeBlock):
      (RareData):
      * debugger/Debugger.cpp:
      (JSC::evaluateInGlobalCallFrame):
      * debugger/DebuggerCallFrame.cpp:
      (JSC::DebuggerCallFrame::evaluate):
      * interpreter/Interpreter.cpp:
      (JSC::eval):
      * runtime/CodeCache.cpp:
      (JSC::CodeCache::CodeCache):
      (JSC::CodeCache::generateBytecode):
      (JSC):
      (JSC::CodeCache::getCodeBlock):
      * runtime/CodeCache.h:
      (JSC::CodeCacheMap::CodeCacheMap):
      (CodeCacheMap):
      (JSC::CodeCacheMap::canPruneQuickly):
      (JSC::CodeCacheMap::prune):
      (JSC::CodeCache::create):
      (CodeCache):
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::EvalExecutable):
      (JSC::EvalExecutable::compileInternal):
      * runtime/Executable.h:
      (JSC::EvalExecutable::create):
      (EvalExecutable):
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::createEvalCodeBlock):
      * runtime/JSGlobalObject.h:
      (JSGlobalObject):
      * runtime/JSGlobalObjectFunctions.cpp:
      (JSC::globalFuncEval):
      * runtime/VM.cpp:
      (JSC::VM::VM):
      * runtime/VM.h:
      (VM):
      
      LayoutTests:
      
      Many tests
      
      * fast/js/eval-cache-scoped-lookup-expected.txt: Added.
      * fast/js/eval-cache-scoped-lookup.html: Added.
      * fast/js/script-tests/eval-cache-scoped-lookup.js: Added.
      (first):
      (a.string_appeared_here.second):
      (third):
      (fifth):
      (sixth):
      (seventh):
      (eighth):
      (nineth):
      (tenth):
      (eleventh):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149836 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0c14001a
  21. 07 May, 2013 1 commit
    • andersca@apple.com's avatar
      Remove AlwaysInline.h from WTF · bf475cae
      andersca@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115727
      
      Reviewed by Brent Fulgham.
      
      The macro that used to be in AlwaysInline.h is now in Compiler.h so there's no reason
      to keep AlwaysInline.h around anymore.
      
      Source/JavaScriptCore:
      
      * jit/JSInterfaceJIT.h:
      * parser/Lexer.h:
      * runtime/JSCJSValue.h:
      * runtime/SymbolTable.h:
      
      Source/WebCore:
      
      * WebCore.vcproj/WebCore.vcproj:
      * bindings/js/JSDOMWindowCustom.h:
      * bindings/scripts/CodeGeneratorJS.pm:
      (GenerateHeader):
      * platform/graphics/filters/FEConvolveMatrix.h:
      * rendering/InlineIterator.h:
      * rendering/InlineTextBox.cpp:
      * rendering/RenderBlockLineLayout.cpp:
      * rendering/RenderText.cpp:
      
      Source/WTF:
      
      * WTF.vcproj/WTF.vcproj:
      * WTF.vcxproj/WTF.vcxproj:
      * WTF.vcxproj/WTF.vcxproj.filters:
      * WTF.xcodeproj/project.pbxproj:
      * wtf/AlwaysInline.h: Removed.
      * wtf/BloomFilter.h:
      * wtf/FastMalloc.cpp:
      * wtf/PassRefPtr.h:
      * wtf/dtoa.cpp:
      * wtf/gobject/GRefPtr.h:
      
      Tools:
      
      * DumpRenderTree/qt/DumpRenderTreeMain.cpp:
      * WebKitTestRunner/InjectedBundle/qt/InjectedBundleQt.cpp:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149673 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bf475cae
  22. 06 May, 2013 1 commit