1. 02 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Stores to local captured variables should be intercepted · 0309686b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124883
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      Previously, in bytecode, you could assign to a captured variable just as you would
      assign to any other kind of variable. This complicates closure variable constant
      inference because we don't have any place where we can intercept stores to captured
      variables in the LLInt.
              
      This patch institutes a policy that only certain instructions can store to captured
      variables. If you interpret those instructions and you are required to notifyWrite()
      then you need to check if the relevant variable is captured. Those instructions are
      tracked in CodeBlock.cpp's VerifyCapturedDef. The main one is simply op_captured_mov.
      In the future, we'll probably modify those instructions to have a pointer directly to
      the VariableWatchpointSet; but for now we just introduce the captured instructions as
      placeholders.
              
      In order to validate that the placeholders are inserted correctly, this patch improves
      the CodeBlock validation to be able to inspect every def in the bytecode. To do that,
      this patch refactors the liveness analysis' use/def calculator to be reusable; it now
      takes a functor for each use or def.
              
      In the process of refactoring the liveness analysis, I noticed that op_enter was
      claiming to def all callee registers. That's wrong; it only defs the non-temporary
      variables. Making that change revealed preexisting bugs in the liveness analysis, since
      now the validator would pick up cases where the bytecode claimed to use a temporary and
      the def calculator never noticed the definition (or the converse - where the bytecode
      was actually not using a temporary but the liveness analysis thought that it was a
      use). This patch fixes a few of those bugs.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::stepOverInstruction):
      * bytecode/BytecodeUseDef.h: Added.
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      (JSC::CodeBlock::isCaptured):
      (JSC::CodeBlock::validate):
      * bytecode/CodeBlock.h:
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      (JSC::BytecodeGenerator::resolveCallee):
      (JSC::BytecodeGenerator::emitMove):
      (JSC::BytecodeGenerator::isCaptured):
      (JSC::BytecodeGenerator::local):
      (JSC::BytecodeGenerator::constLocal):
      (JSC::BytecodeGenerator::emitNewFunction):
      (JSC::BytecodeGenerator::emitLazyNewFunction):
      (JSC::BytecodeGenerator::emitNewFunctionInternal):
      * bytecompiler/BytecodeGenerator.h:
      (JSC::Local::Local):
      (JSC::Local::isCaptured):
      (JSC::Local::captureMode):
      (JSC::BytecodeGenerator::captureMode):
      (JSC::BytecodeGenerator::emitNode):
      (JSC::BytecodeGenerator::pushOptimisedForIn):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::PostfixNode::emitResolve):
      (JSC::PrefixNode::emitResolve):
      (JSC::ReadModifyResolveNode::emitBytecode):
      (JSC::AssignResolveNode::emitBytecode):
      (JSC::ConstDeclNode::emitCodeSingle):
      (JSC::ForInNode::emitBytecode):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/SymbolTable.h:
      (JSC::SymbolTable::isCaptured):
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * js/regress/captured-assignments-expected.txt: Added.
      * js/regress/captured-assignments.html: Added.
      * js/regress/script-tests/captured-assignments.js: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159943 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0309686b
  2. 26 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Restructure global variable constant inference so that it could work for any... · 8646834a
      fpizlo@apple.com authored
      Restructure global variable constant inference so that it could work for any kind of symbol table variable
      https://bugs.webkit.org/show_bug.cgi?id=124760
      
      Reviewed by Oliver Hunt.
              
      This changes the way global variable constant inference works so that it can be reused
      for closure variable constant inference. Some of the premises that originally motivated
      this patch are somewhat wrong, but it led to some simplifications anyway and I suspect
      that we'll be able to fix those premises in the future. The main point of this patch is
      to make it easy to reuse global variable constant inference for closure variable
      constant inference, and this will be possible provided we can also either (a) infer
      one-shot closures (easy) or (b) infer closure variables that are always assigned prior
      to first use.
              
      One of the things that this patch is meant to enable is constant inference for closure
      variables that may be part of a multi-shot closure. Closure variables may be
      instantiated multiple times, like:
              
          function foo() {
              var WIDTH = 45;
              function bar() {
                  ... use WIDTH ...
              }
              ...
          }
              
      Even if foo() is called many times and WIDTH is assigned to multiple times, that
      doesn't change the fact that it's a constant. The goal of closure variable constant
      inference is to catch any case where a closure variable has been assigned at least once
      and its value has never changed. This patch doesn't implement that, but it does change
      global variable constant inference to have most of the powers needed to do that. Note
      that most likely we will use this functionality only to implement constant inference
      for one-shot closures, but the resulting machinery is still simpler than what we had
      before.
              
      This involves three changes:
              
          - The watchpoint object now contains the inferred value. This involves creating a
            new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object
            for closure variables.
              
          - Writing to a variable that is watchpointed still involves these three states that
            we proceed through monotonically (Uninitialized->Initialized->Invalidated) but
            now, the Initialized->Invalidated state transition only happens if we change the
            variable's value, rather than store to the variable. Repeatedly storing the same
            value won't change the variable's state.
              
          - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer
            need fancy fencing to get a consistent view of the watchpoint in the JIT. The
            state of the VariableWatchpointSet for the purposes of constant folding is
            entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is
            JSValue() then you cannot fold (either because the set is uninitialized or
            because it's invalidated - doesn't matter which); on the other hand if the value
            is anything other than JSValue() then you can fold, and that's the value you fold
            to. Simple!
              
      This also changes the way that DFG IR deals with variable watchpoints. It's now
      oblivious to global variables. You install a watchpoint using VariableWatchpoint and
      you notify write using NotifyWrite. Easy!
              
      Note that this will requires some more tweaks because of the fact that op_enter will
      store Undefined into every captured variable. Hence it won't even work for one-shot
      closures. One-shot closures are easily fixed by introducing another state (so we'll
      have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will
      require static analysis. One-shot closures are clearly a higher priority.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/Instruction.h:
      * bytecode/VariableWatchpointSet.h: Added.
      (JSC::VariableWatchpointSet::VariableWatchpointSet):
      (JSC::VariableWatchpointSet::~VariableWatchpointSet):
      (JSC::VariableWatchpointSet::inferredValue):
      (JSC::VariableWatchpointSet::notifyWrite):
      (JSC::VariableWatchpointSet::invalidate):
      (JSC::VariableWatchpointSet::finalizeUnconditionally):
      (JSC::VariableWatchpointSet::addressOfInferredValue):
      * bytecode/Watchpoint.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasRegisterPointer):
      (JSC::DFG::Node::hasVariableWatchpointSet):
      (JSC::DFG::Node::variableWatchpointSet):
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileArithMod):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
      * jit/JIT.h:
      * jit/JITOperations.h:
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitNotifyWrite):
      (JSC::JIT::emitPutGlobalVar):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitNotifyWrite):
      (JSC::JIT::emitPutGlobalVar):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::addGlobalVar):
      (JSC::JSGlobalObject::addFunction):
      * runtime/JSGlobalObject.h:
      * runtime/JSScope.h:
      (JSC::ResolveOp::ResolveOp):
      * runtime/JSSymbolTableObject.h:
      (JSC::symbolTablePut):
      (JSC::symbolTablePutWithAttributes):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::inferredValue):
      (JSC::SymbolTableEntry::prepareToWatch):
      (JSC::SymbolTableEntry::addWatchpoint):
      (JSC::SymbolTableEntry::notifyWriteSlow):
      (JSC::SymbolTable::visitChildren):
      (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup):
      (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup):
      (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally):
      * runtime/SymbolTable.h:
      (JSC::SymbolTableEntry::watchpointSet):
      (JSC::SymbolTableEntry::notifyWrite):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159798 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8646834a
  3. 21 Nov, 2013 1 commit
  4. 20 Nov, 2013 1 commit
    • mark.lam@apple.com's avatar
      Introducing VMEntryScope to update the VM stack limit. · 30721257
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124634.
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      1. Introduced USE(SEPARATE_C_AND_JS_STACK) (defined in Platform.h).
         Currently, it is hardcoded to use separate C and JS stacks. Once we
         switch to using the C stack for JS frames, we'll need to fix this to
         only be enabled when ENABLE(LLINT_C_LOOP).
      
      2. Stack limits are now tracked in the VM.
      
         Logically, there are 2 stack limits:
         a. m_stackLimit for the native C stack, and
         b. m_jsStackLimit for the JS stack.
      
         If USE(SEPARATE_C_AND_JS_STACK), then the 2 limits are the same
         value, and are implemented as 2 fields in a union.
      
      3. The VM native stackLimit is set as follows:
         a. Initially, the VM sets it to the limit of the stack of the thread that
            instantiated the VM. This allows the parser and bytecode generator to
            run before we enter the VM to execute JS code.
      
         b. Upon entry into the VM to execute JS code (via one of the
            Interpreter::execute...() functions), we instantiate a VMEntryScope
            that sets the VM's stackLimit to the limit of the current thread's
            stack. The VMEntryScope will automatically restore the previous
            entryScope and stack limit upon destruction.
      
         If USE(SEPARATE_C_AND_JS_STACK), the JSStack's methods will set the VM's
         jsStackLimit whenever it grows or shrinks.
      
      4. The VM now provides a isSafeToRecurse() function that compares the
         current stack pointer against its native stackLimit. This subsumes and
         obsoletes the VMStackBounds class.
      
      5. The VMEntryScope class also subsumes DynamicGlobalObjectScope for
         tracking the JSGlobalObject that we last entered the VM with.
      
      6. Renamed dynamicGlobalObject() to vmEntryGlobalObject() since that is
         the value that the function retrieves.
      
      7. Changed JIT and LLINT code to do stack checks against the jsStackLimit
         in the VM class instead of the JSStack.
      
      * API/JSBase.cpp:
      (JSEvaluateScript):
      (JSCheckScriptSyntax):
      * API/JSContextRef.cpp:
      (JSGlobalContextRetain):
      (JSGlobalContextRelease):
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      * bytecompiler/BytecodeGenerator.h:
      (JSC::BytecodeGenerator::emitNode):
      (JSC::BytecodeGenerator::emitNodeInConditionContext):
      * debugger/Debugger.cpp:
      (JSC::Debugger::detach):
      (JSC::Debugger::recompileAllJSFunctions):
      (JSC::Debugger::pauseIfNeeded):
      * debugger/DebuggerCallFrame.cpp:
      (JSC::DebuggerCallFrame::vmEntryGlobalObject):
      * debugger/DebuggerCallFrame.h:
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::compileFunction):
      * dfg/DFGOSREntry.cpp:
      * ftl/FTLLink.cpp:
      (JSC::FTL::link):
      * ftl/FTLOSREntry.cpp:
      * heap/Heap.cpp:
      (JSC::Heap::lastChanceToFinalize):
      (JSC::Heap::deleteAllCompiledCode):
      * interpreter/CachedCall.h:
      (JSC::CachedCall::CachedCall):
      * interpreter/CallFrame.cpp:
      (JSC::CallFrame::vmEntryGlobalObject):
      * interpreter/CallFrame.h:
      * interpreter/Interpreter.cpp:
      (JSC::unwindCallFrame):
      (JSC::Interpreter::unwind):
      (JSC::Interpreter::execute):
      (JSC::Interpreter::executeCall):
      (JSC::Interpreter::executeConstruct):
      (JSC::Interpreter::prepareForRepeatCall):
      (JSC::Interpreter::debug):
      * interpreter/JSStack.cpp:
      (JSC::JSStack::JSStack):
      (JSC::JSStack::growSlowCase):
      * interpreter/JSStack.h:
      * interpreter/JSStackInlines.h:
      (JSC::JSStack::shrink):
      (JSC::JSStack::grow):
      - Moved these inlined functions here from JSStack.h. It reduces some
        #include dependencies of JSSTack.h which had previously resulted
        in some EWS bots' unhappiness with this patch.
      (JSC::JSStack::updateStackLimit):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile):
      * jit/JITCall.cpp:
      (JSC::JIT::compileLoadVarargs):
      * jit/JITCall32_64.cpp:
      (JSC::JIT::compileLoadVarargs):
      * jit/JITOperations.cpp:
      * llint/LLIntSlowPaths.cpp:
      * llint/LowLevelInterpreter.asm:
      * parser/Parser.cpp:
      (JSC::::Parser):
      * parser/Parser.h:
      (JSC::Parser::canRecurse):
      * runtime/CommonSlowPaths.h:
      * runtime/Completion.cpp:
      (JSC::evaluate):
      * runtime/FunctionConstructor.cpp:
      (JSC::constructFunctionSkippingEvalEnabledCheck):
      * runtime/JSGlobalObject.cpp:
      * runtime/JSGlobalObject.h:
      * runtime/StringRecursionChecker.h:
      (JSC::StringRecursionChecker::performCheck):
      * runtime/VM.cpp:
      (JSC::VM::VM):
      (JSC::VM::releaseExecutableMemory):
      (JSC::VM::throwException):
      * runtime/VM.h:
      (JSC::VM::addressOfJSStackLimit):
      (JSC::VM::jsStackLimit):
      (JSC::VM::setJSStackLimit):
      (JSC::VM::stackLimit):
      (JSC::VM::setStackLimit):
      (JSC::VM::isSafeToRecurse):
      * runtime/VMEntryScope.cpp: Added.
      (JSC::VMEntryScope::VMEntryScope):
      (JSC::VMEntryScope::~VMEntryScope):
      (JSC::VMEntryScope::requiredCapacity):
      * runtime/VMEntryScope.h: Added.
      (JSC::VMEntryScope::globalObject):
      * runtime/VMStackBounds.h: Removed.
      
      Source/WebCore: 
      
      No new tests.
      
      Renamed dynamicGlobalObject() to vmEntryGlobalObject().
      Replaced uses of DynamicGlobalObjectScope with VMEntryScope.
      
      * ForwardingHeaders/runtime/VMEntryScope.h: Added.
      * WebCore.vcxproj/WebCore.vcxproj:
      * WebCore.vcxproj/WebCore.vcxproj.filters:
      * bindings/js/JSCryptoAlgorithmBuilder.cpp:
      (WebCore::JSCryptoAlgorithmBuilder::add):
      * bindings/js/JSCustomXPathNSResolver.cpp:
      (WebCore::JSCustomXPathNSResolver::create):
      * bindings/js/JSDOMBinding.cpp:
      (WebCore::firstDOMWindow):
      * bindings/js/JSErrorHandler.cpp:
      (WebCore::JSErrorHandler::handleEvent):
      * bindings/js/JSEventListener.cpp:
      (WebCore::JSEventListener::handleEvent):
      * bindings/js/JavaScriptCallFrame.h:
      (WebCore::JavaScriptCallFrame::vmEntryGlobalObject):
      * bindings/js/PageScriptDebugServer.cpp:
      (WebCore::PageScriptDebugServer::recompileAllJSFunctions):
      * bindings/js/ScriptDebugServer.cpp:
      (WebCore::ScriptDebugServer::evaluateBreakpointAction):
      (WebCore::ScriptDebugServer::handlePause):
      * bindings/js/WorkerScriptDebugServer.cpp:
      (WebCore::WorkerScriptDebugServer::recompileAllJSFunctions):
      * bindings/objc/WebScriptObject.mm:
      (WebCore::addExceptionToConsole):
      * bridge/c/c_utility.cpp:
      (JSC::Bindings::convertValueToNPVariant):
      * bridge/objc/objc_instance.mm:
      (ObjcInstance::moveGlobalExceptionToExecState):
      * bridge/objc/objc_runtime.mm:
      (JSC::Bindings::convertValueToObjcObject):
      * bridge/objc/objc_utility.mm:
      (JSC::Bindings::convertValueToObjcValue):
      
      Source/WebKit/mac: 
      
      * WebView/WebScriptDebugger.mm:
      (WebScriptDebugger::sourceParsed):
      
      Source/WTF: 
      
      * wtf/Platform.h:
      * wtf/StackBounds.h:
      (WTF::StackBounds::StackBounds):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159605 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      30721257
  5. 19 Nov, 2013 1 commit
    • mark.lam@apple.com's avatar
      Add tracking of endColumn for Executables. · fa35e785
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124245.
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      1. Fixed computation of columns to take into account the startColumn from
         <script> tags. Previously, we were only computing the column relative
         to the char after the <script> tag. Now, the column number that JSC
         computes is always the column number you'll see when viewing the source
         in a text editor (assuming the first column position is 1, not 0).
      
      2. Previously, unlinkedExecutables kept the a base-1 startColumn for
         ProgramExecutables and EvalExecutables, but uses base-0 columns for
         FunctionExecutables. This has been fixed so that they all use base-0
         columns. When the executable gets linked, the column is adjusted into
         a base-1 value.
      
      3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
         m_unlinkedFunctionNameStart because it actually points to the start
         column in the name part of the function declaration.
      
         Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
         because it points to the first character in the function body. This is
         usually '{' except for functions created from "global code" which
         excludes its braces. See FunctionExecutable::fromGlobalCode().
      
             The exclusion of braces for the global code case is needed so that
         computed start and end columns will more readily map to what a JS
         developer would expect them to be. Otherwise, the first column of the
         function source will not be 1 (includes prepended characters added in
         constructFunctionSkippingEvalEnabledCheck()).
      
         Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
         end column of the UnlinkedFunctionExecutable.
      
      4. For unlinked executables, end column values are either:
         a. Relative to the start of the last line if (last line != first line).
         b. Relative to the start column position if (last line == first line).
      
         The second case is needed so that we can add an appropriate adjustment
         to the end column value (just like we do for the start column) when we
         link the executable.
      
      5. This is not new to this patch, but it worth noting that the lineCount
         values used through this patch has the following meaning:
         - a lineCount of 0 means the source for this code block is on 1 line.
         - a lineCount of N means there are N + l lines of source.
      
         This interpretation is janky, but was present before this patch. We can
         clean that up later in another patch.
      
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      - In order to implement WebCore::Internals::parserMetaData(), we need to
        move some seemingly unrelated header files from the Project section to
        the Private section so that they can be #include'd by the forwarding
        CodeBlock.h from WebCore.
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::sourceCodeForTools):
      (JSC::CodeBlock::CodeBlock):
      * bytecode/UnlinkedCodeBlock.cpp:
      (JSC::generateFunctionCodeBlock):
      (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
      - m_isFromGlobalCode is needed to support the exclusion of the open brace /
        prepended code for functions created from "global code".
      (JSC::UnlinkedFunctionExecutable::link):
      (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
      (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
      * bytecode/UnlinkedCodeBlock.h:
      (JSC::UnlinkedFunctionExecutable::create):
      (JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
      (JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
      (JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
      (JSC::UnlinkedFunctionExecutable::recordParse):
      (JSC::UnlinkedCodeBlock::recordParse):
      (JSC::UnlinkedCodeBlock::endColumn):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::FunctionBodyNode::emitBytecode):
      * parser/ASTBuilder.h:
      (JSC::ASTBuilder::createFunctionBody):
      (JSC::ASTBuilder::setFunctionNameStart):
      * parser/Lexer.cpp:
      (JSC::::shiftLineTerminator):
      - Removed an unused SourceCode Lexer<T>::sourceCode() function.
      * parser/Lexer.h:
      (JSC::Lexer::positionBeforeLastNewline):
      (JSC::Lexer::prevTerminator):
      - Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
        to exclude the close brace / appended code for functions created from "global
        code".
      * parser/Nodes.cpp:
      (JSC::ProgramNode::ProgramNode):
      (JSC::ProgramNode::create):
      (JSC::EvalNode::EvalNode):
      (JSC::EvalNode::create):
      (JSC::FunctionBodyNode::FunctionBodyNode):
      (JSC::FunctionBodyNode::create):
      (JSC::FunctionBodyNode::setEndPosition):
      - setEndPosition() is needed to fixed up the end position so that we can
        exclude the close brace / appended code for functions created from "global
        code".
      * parser/Nodes.h:
      (JSC::ProgramNode::startColumn):
      (JSC::ProgramNode::endColumn):
      (JSC::EvalNode::startColumn):
      (JSC::EvalNode::endColumn):
      (JSC::FunctionBodyNode::setFunctionNameStart):
      (JSC::FunctionBodyNode::functionNameStart):
      (JSC::FunctionBodyNode::endColumn):
      * parser/Parser.cpp:
      (JSC::::parseFunctionBody):
      (JSC::::parseFunctionInfo):
      * parser/Parser.h:
      (JSC::Parser::positionBeforeLastNewline):
      (JSC::::parse):
      - Subtracted 1 from startColumn here to keep the node column values consistently
        base-0. See note 2 above.
      (JSC::parse):
      * parser/SourceProviderCacheItem.h:
      (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
      * parser/SyntaxChecker.h:
      (JSC::SyntaxChecker::createFunctionBody):
      (JSC::SyntaxChecker::setFunctionNameStart):
      * runtime/CodeCache.cpp:
      (JSC::CodeCache::getGlobalCodeBlock):
      (JSC::CodeCache::getProgramCodeBlock):
      (JSC::CodeCache::getEvalCodeBlock):
      (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
      * runtime/CodeCache.h:
      * runtime/Executable.cpp:
      (JSC::ScriptExecutable::newCodeBlockFor):
      (JSC::FunctionExecutable::FunctionExecutable):
      (JSC::ProgramExecutable::initializeGlobalProperties):
      (JSC::FunctionExecutable::fromGlobalCode):
      * runtime/Executable.h:
      (JSC::ExecutableBase::isEvalExecutable):
      (JSC::ExecutableBase::isProgramExecutable):
      (JSC::ScriptExecutable::ScriptExecutable):
      (JSC::ScriptExecutable::endColumn):
      (JSC::ScriptExecutable::recordParse):
      (JSC::FunctionExecutable::create):
      (JSC::FunctionExecutable::bodyIncludesBraces):
      * runtime/FunctionConstructor.cpp:
      (JSC::constructFunctionSkippingEvalEnabledCheck):
      * runtime/FunctionPrototype.cpp:
      (JSC::insertSemicolonIfNeeded):
      (JSC::functionProtoFuncToString):
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::createProgramCodeBlock):
      (JSC::JSGlobalObject::createEvalCodeBlock):
      
      Source/WebCore: 
      
      Test: js/dom/script-start-end-locations.html
      
      * ForwardingHeaders/bytecode: Added.
      * ForwardingHeaders/bytecode/CodeBlock.h: Added.
      * WebCore.exp.in:
      * testing/Internals.cpp:
      (WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
      (WebCore::GetCallerCodeBlockFunctor::operator()):
      (WebCore::GetCallerCodeBlockFunctor::codeBlock):
      (WebCore::Internals::parserMetaData):
      * testing/Internals.h:
      * testing/Internals.idl:
      
      Source/WebKit: 
      
      * WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
      - Added an exported symbol to make the Win32 build happy. The Win64 symbol
        is currently a copy of the Win32 one. It'll need to be updated if the
        mangled symbol is different for Win64.
      
      LayoutTests: 
      
      * fast/events/window-onerror2-expected.txt:
      * inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
      * js/dom/script-start-end-locations-expected.txt: Added.
      * js/dom/script-start-end-locations.html: Added.
      * js/dom/script-tests/script-start-end-locations.js: Added.
      * js/dom/stack-trace-expected.txt:
      * js/dom/stack-trace.html:
      - Changed tabs to spaces. The tabs were making it hard to visually confirm
        the exected column values for 2 functions.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fa35e785
  6. 17 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      FTL should have an explicit notion of bytecode liveness · 002405c0
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124181
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      This makes FTL OSR exit use bytecode liveness analysis to determine which variables
      to include values for. The decision of how to get the values of variables is based on
      forward propagation of MovHints and SetLocals.
              
      This fixes a bunch of bugs (like https://bugs.webkit.org/show_bug.cgi?id=124138 but
      also others that I noticed when I started writing more targetted tests) and allows us
      to remove some sketchy code.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/BytecodeBasicBlock.h:
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::isValidRegisterForLiveness):
      (JSC::setForOperand):
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      (JSC::stepOverInstruction):
      (JSC::computeLocalLivenessForBytecodeOffset):
      (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
      (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
      (JSC::getLivenessInfo):
      (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
      (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
      * bytecode/BytecodeLivenessAnalysis.h:
      * bytecode/BytecodeLivenessAnalysisInlines.h: Added.
      (JSC::operandIsAlwaysLive):
      (JSC::operandThatIsNotAlwaysLiveIsLive):
      (JSC::operandIsLive):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::captureCount):
      (JSC::CodeBlock::captureStart):
      (JSC::CodeBlock::captureEnd):
      * bytecode/CodeOrigin.cpp:
      (JSC::InlineCallFrame::dumpInContext):
      * bytecode/FullBytecodeLiveness.h: Added.
      (JSC::FullBytecodeLiveness::FullBytecodeLiveness):
      (JSC::FullBytecodeLiveness::getOut):
      (JSC::FullBytecodeLiveness::operandIsLive):
      (JSC::FullBytecodeLiveness::getLiveness):
      * dfg/DFGAvailability.cpp: Added.
      (JSC::DFG::Availability::dump):
      (JSC::DFG::Availability::dumpInContext):
      * dfg/DFGAvailability.h: Added.
      (JSC::DFG::Availability::Availability):
      (JSC::DFG::Availability::unavailable):
      (JSC::DFG::Availability::withFlush):
      (JSC::DFG::Availability::withNode):
      (JSC::DFG::Availability::withUnavailableNode):
      (JSC::DFG::Availability::nodeIsUndecided):
      (JSC::DFG::Availability::nodeIsUnavailable):
      (JSC::DFG::Availability::hasNode):
      (JSC::DFG::Availability::node):
      (JSC::DFG::Availability::flushedAt):
      (JSC::DFG::Availability::operator!):
      (JSC::DFG::Availability::operator==):
      (JSC::DFG::Availability::merge):
      (JSC::DFG::Availability::mergeNodes):
      (JSC::DFG::Availability::unavailableMarker):
      * dfg/DFGBasicBlock.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGDisassembler.cpp:
      (JSC::DFG::Disassembler::Disassembler):
      * dfg/DFGFlushFormat.cpp:
      (WTF::printInternal):
      * dfg/DFGFlushFormat.h:
      (JSC::DFG::resultFor):
      (JSC::DFG::useKindFor):
      (JSC::DFG::dataFormatFor):
      * dfg/DFGFlushedAt.cpp:
      (JSC::DFG::FlushedAt::dump):
      * dfg/DFGFlushedAt.h:
      (JSC::DFG::FlushedAt::FlushedAt):
      (JSC::DFG::FlushedAt::merge):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      (JSC::DFG::Graph::livenessFor):
      (JSC::DFG::Graph::isLiveInBytecode):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::baselineCodeBlockFor):
      * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
      (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
      * dfg/DFGOSRAvailabilityAnalysisPhase.h:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGResurrectionForValidationPhase.cpp: Added.
      (JSC::DFG::ResurrectionForValidationPhase::ResurrectionForValidationPhase):
      (JSC::DFG::ResurrectionForValidationPhase::run):
      (JSC::DFG::performResurrectionForValidation):
      * dfg/DFGResurrectionForValidationPhase.h: Added.
      * dfg/DFGSSAConversionPhase.cpp:
      (JSC::DFG::SSAConversionPhase::run):
      * dfg/DFGValueSource.h:
      (JSC::DFG::ValueSource::forFlushFormat):
      * dfg/DFGVariableAccessData.h:
      * ftl/FTLExitValue.cpp:
      (JSC::FTL::ExitValue::dumpInContext):
      * ftl/FTLInlineCacheSize.cpp:
      (JSC::FTL::sizeOfGetById):
      * ftl/FTLLocation.cpp:
      (JSC::FTL::Location::gpr):
      (JSC::FTL::Location::fpr):
      (JSC::FTL::Location::directGPR):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
      (JSC::FTL::LowerDFGToLLVM::compileBlock):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
      (JSC::FTL::LowerDFGToLLVM::compilePutById):
      (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      (JSC::FTL::LowerDFGToLLVM::observeMovHint):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::alloca):
      * ftl/FTLValueSource.cpp: Removed.
      * ftl/FTLValueSource.h: Removed.
      * llvm/LLVMAPIFunctions.h:
      * runtime/DumpContext.cpp:
      (JSC::DumpContext::DumpContext):
      * runtime/DumpContext.h:
      * runtime/Options.h:
      * runtime/SymbolTable.h:
      (JSC::SharedSymbolTable::captureStart):
      (JSC::SharedSymbolTable::captureEnd):
      (JSC::SharedSymbolTable::captureCount):
      
      Tools: 
      
      Reviewed by Mark Hahnenberg.
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg or Sam Weinig.
              
      I totally added this test after the rest of the patch was r+'d. Under the right tier-up
      modes this triggers one of the bugs that the rest of the patch is trying to avoid.
      
      * js/regress/script-tests/weird-inlining-const-prop.js: Added.
      (foo):
      (bar):
      (fuzz):
      (testImpl):
      (test):
      * js/regress/weird-inlining-const-prop-expected.txt: Added.
      * js/regress/weird-inlining-const-prop.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159394 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      002405c0
  7. 15 Nov, 2013 2 commits
    • mhahnenberg@apple.com's avatar
      Remove VTableSpectrum · 5906583d
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124427
      
      Reviewed by Filip Pizlo.
      
      Source/JavaScriptCore:
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * heap/Heap.cpp:
      (JSC::Heap::lastChanceToFinalize):
      * heap/Heap.h:
      * heap/MarkedBlock.cpp:
      (JSC::MarkedBlock::callDestructor):
      * heap/SlotVisitor.cpp:
      (JSC::visitChildren):
      * heap/SlotVisitor.h:
      * heap/VTableSpectrum.cpp: Removed.
      * heap/VTableSpectrum.h: Removed.
      
      Source/WebKit/blackberry:
      
      * WebCoreSupport/AboutDataEnableFeatures.in:
      
      Source/WTF:
      
      * wtf/Platform.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159360 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5906583d
    • mhahnenberg@apple.com's avatar
      -dealloc callbacks from wrapped Objective-C objects can happen at bad times · ac6f1fd4
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123821
      
      Reviewed by Darin Adler.
      
      Currently with the JSC Obj-C API, JS wrappers for client Obj-C objects retain their associated Obj-C 
      object. When they are swept, they release their Obj-C objects which can trigger a call to that 
      object's -dealloc method. These -dealloc methods can then call back into the same VM, which is not 
      allowed during sweeping or VM shutdown.
      
      We can handle this case by creating our own pool of Obj-C objects to be released when it is safe to do so.
      This is accomplished by using DelayedReleaseScope, an RAII-style object that will retain all objects
      that are unsafe to release until the end of the DelayedReleaseScope.
      
      * API/APIShims.h:
      (JSC::APICallbackShim::APICallbackShim):
      (JSC::APICallbackShim::vmForDropAllLocks):
      (JSC::APICallbackShim::execForDropAllLocks):
      * API/JSAPIWrapperObject.mm:
      (JSAPIWrapperObjectHandleOwner::finalize):
      * API/ObjCCallbackFunction.mm:
      (JSC::ObjCCallbackFunctionImpl::destroy):
      (JSC::ObjCCallbackFunction::destroy):
      * API/tests/testapi.mm:
      (-[TinyDOMNode initWithVirtualMachine:]):
      (-[TinyDOMNode dealloc]):
      (-[TinyDOMNode appendChild:]):
      (-[TinyDOMNode removeChildAtIndex:]):
      (-[EvilAllocationObject initWithContext:]):
      (-[EvilAllocationObject dealloc]):
      (-[EvilAllocationObject doEvilThingsWithContext:]):
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * heap/DelayedReleaseScope.h: Added.
      (JSC::DelayedReleaseScope::DelayedReleaseScope):
      (JSC::DelayedReleaseScope::~DelayedReleaseScope):
      (JSC::DelayedReleaseScope::releaseSoon):
      (JSC::MarkedSpace::releaseSoon):
      * heap/Heap.cpp:
      (JSC::Heap::collectAllGarbage):
      * heap/Heap.h:
      (JSC::Heap::releaseSoon):
      * heap/MarkedAllocator.cpp:
      (JSC::MarkedAllocator::allocateSlowCase):
      * heap/MarkedSpace.cpp:
      (JSC::MarkedSpace::MarkedSpace):
      (JSC::MarkedSpace::lastChanceToFinalize):
      (JSC::MarkedSpace::sweep):
      * heap/MarkedSpace.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159351 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ac6f1fd4
  8. 13 Nov, 2013 1 commit
    • aestes@apple.com's avatar
      Fix the ARM64 build after recent JavaScriptCore changes · 4f809911
      aestes@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124315
      
      Reviewed by Michael Saboff.
      
      Based on patches by myself, Filip Pizlo, Benjamin Poulain, and Michael Saboff.
      
      * Configurations/JavaScriptCore.xcconfig: Hid the symbol for
      std::bad_function_call.
      * JavaScriptCore.xcodeproj/project.pbxproj: Marked
      MacroAssemblerARM64.h and ARM64Assembler.h as Private headers.
      * assembler/ARM64Assembler.h:
      (JSC::ARM64Assembler::executableOffsetFor):
      * assembler/MacroAssemblerARM64.h: Removed ARM64's executableCopy(),
      which was removed from other assembler backends in r157690.
      (JSC::MacroAssemblerARM64::shouldBlindForSpecificArch): Added.
      (JSC::MacroAssemblerARM64::lshift64): Added.
      (JSC::MacroAssemblerARM64::mul64): Added.
      (JSC::MacroAssemblerARM64::rshift64): Added.
      (JSC::MacroAssemblerARM64::convertInt64ToDouble): Added.
      (JSC::MacroAssemblerARM64::branchMul64): Added.
      (JSC::MacroAssemblerARM64::branchNeg64): Added.
      (JSC::MacroAssemblerARM64::scratchRegisterForBlinding): Added.
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileArithDiv): Changed
      SpeculateIntegerOperand to SpeculateInt32Operand,
      nodeCanIgnoreNegativeZero() to bytecodeCanIgnoreNegativeZero(), and
      nodeUsedAsNumber() to bytecodeUsesAsNumber().
      (JSC::DFG::SpeculativeJIT::compileArithMod): Changed
      nodeCanIgnoreNegativeZero() to bytecodeCanIgnoreNegativeZero().
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159261 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4f809911
  9. 12 Nov, 2013 1 commit
    • mhahnenberg@apple.com's avatar
      CodeBlocks should be able to determine bytecode liveness · 3811e215
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118546
      
      Reviewed by Filip Pizlo.
      
      This will simplify some things in the DFG related to OSR exits and determining 
      which bytecode variables are live at which points during execution. It will
      also be useful for making our conservative GC scan more precise. Currently it 
      doesn't properly account for liveness while the DFG is running, so it will be 
      off by default behing a runtime Options flag.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/BytecodeBasicBlock.cpp: Added.
      (JSC::isBranch): Used to determine the end of basic blocks.
      (JSC::isUnconditionalBranch): Used to determine when a branch at the end of a 
      basic block can't possibly fall through to the next basic block in program order.
      (JSC::isTerminal): Also used to detect the end of a block.
      (JSC::isThrow):
      (JSC::isJumpTarget): Used to correctly separate basic blocks. Any jump destination 
      must be the head of its own basic block.
      (JSC::linkBlocks): Links two blocks together in a bi-direcitonal fashion.
      (JSC::computeBytecodeBasicBlocks): Creates a set of basic blocks given a particular 
      CodeBlock and links them together.
      * bytecode/BytecodeBasicBlock.h: Added.
      (JSC::BytecodeBasicBlock::isEntryBlock): Entry blocks are a special basic blocks 
      that indicate the beginning of the function.
      (JSC::BytecodeBasicBlock::isExitBlock): Exit blocks are a special basic block that 
      all blocks that exit the function have as a successor. Entry and exit blocks allows 
      the various code paths to be more regular.
      (JSC::BytecodeBasicBlock::leaderBytecodeOffset): The leader bytecode offset is the 
      bytecode offset of the first instruction in the block.
      (JSC::BytecodeBasicBlock::totalBytecodeLength): The total length of all the bytecodes 
      in this block.
      (JSC::BytecodeBasicBlock::bytecodeOffsets): The bytecode offsets in this particular 
      basic block. This Vector allows us to iterate over the bytecodes in reverse order 
      which wouldn't be possible normally since they are of variable size.
      (JSC::BytecodeBasicBlock::addPredecessor): Links a block to a specified predecessor. 
      Only creates one direction of the link.
      (JSC::BytecodeBasicBlock::addSuccessor): Same as addPredecessor, but for successors.
      (JSC::BytecodeBasicBlock::predecessors): Getter for predecessors.
      (JSC::BytecodeBasicBlock::successors): Getter for successors.
      (JSC::BytecodeBasicBlock::in): Getter for the liveness info at the head of the block.
      (JSC::BytecodeBasicBlock::out): Getter for the liveness info at  the tail of the block.
      (JSC::BytecodeBasicBlock::BytecodeBasicBlock):
      (JSC::BytecodeBasicBlock::addBytecodeLength): When creating basic blocks we call 
      this function when we want to add the next bytecode in program order to this block.
      * bytecode/BytecodeLivenessAnalysis.cpp: Added.
      (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
      (JSC::numberOfCapturedVariables): Convenience wrapper. Returns the
      number of captured variables for a particular CodeBlock, or 0 if 
      the CodeBlock has no SymbolTable.
      (JSC::captureStart): Ditto, but for captureStart().
      (JSC::captureEnd): Ditto, but for captureEnd().
      (JSC::isValidRegisterForLiveness): Returns true if the liveness analysis should 
      track the liveness of a particular operand. We ignore constants, arguments, and 
      captured variables. We ignore arguments because they're live for the duration of 
      a function call. We ignore captured variables because we also treat them as live 
      for the duration of the function. This could probably be improved to be more precise, 
      but it didn't seem worth it for now.
      (JSC::setForOperand): Convenience wrapper that sets the bit in the provided bit 
      vector for the provided operand. It handles skipping over captured variables.
      (JSC::computeUsesForBytecodeOffset): Computes which operands are used by a particular bytecode.
      (JSC::computeDefsForBytecodeOffset): Computes which operands are defined by a particular 
      bytecode. Typically this is just the left-most operand.
      (JSC::findBasicBlockWithLeaderOffset): 
      (JSC::findBasicBlockForBytecodeOffset): Scans over basic blocks to find the block 
      which contains a particular bytecode offset.
      (JSC::computeLocalLivenessForBytecodeOffset): Computes block-local liveness from the 
      bottom of the block until a specified bytecode offset is reached. 
      (JSC::computeLocalLivenessForBlock): Computes liveness for the entire block and 
      stores the resulting liveness at the head.
      (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): Runs backward flow liveness 
      analysis to fixpoint.
      (JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): 
      Slow path to get liveness info for non-captured, non-argument variable.
      (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): 
      (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset): Returns the liveness 
      info for both captured and non-captured vars at a particular bytecode offset.
      (JSC::BytecodeLivenessAnalysis::dumpResults): Dumps the output of the liveness analysis. 
      Controlled by new flag in Options.h/.cpp.
      (JSC::BytecodeLivenessAnalysis::compute): Creates bytecode basic blocks and runs 
      full liveness analysis.
      * bytecode/BytecodeLivenessAnalysis.h: Added.
      (JSC::BytecodeLivenessAnalysis::hasBeenComputed):
      (JSC::BytecodeLivenessAnalysis::computeIfNecessary):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::livenessAnalysis):
      * bytecode/PreciseJumpTargets.cpp: Refactored to be able to get the jump targets for 
      a particular bytecode offset for use during bytecode basic block construction.
      (JSC::getJumpTargetsForBytecodeOffset):
      (JSC::computePreciseJumpTargets):
      (JSC::findJumpTargetsForBytecodeOffset):
      * bytecode/PreciseJumpTargets.h:
      * runtime/Options.cpp:
      (JSC::Options::initialize):
      * runtime/Options.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159136 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3811e215
  10. 10 Nov, 2013 1 commit
    • oliver@apple.com's avatar
      Implement Set iterators · 96cafa31
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124129
      
      Reviewed by Antti Koivisto.
      
      Source/JavaScriptCore:
      
      Add Set iterator classes and implementations
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * runtime/CommonIdentifiers.h:
      * runtime/JSGlobalObject.cpp:
      * runtime/JSGlobalObject.h:
      * runtime/JSSetIterator.cpp: Added.
      (JSC::JSSetIterator::finishCreation):
      (JSC::JSSetIterator::visitChildren):
      (JSC::JSSetIterator::createPair):
      * runtime/JSSetIterator.h: Added.
      (JSC::JSSetIterator::createStructure):
      (JSC::JSSetIterator::create):
      (JSC::JSSetIterator::next):
      (JSC::JSSetIterator::JSSetIterator):
      * runtime/SetIteratorConstructor.cpp: Added.
      (JSC::SetIteratorConstructor::finishCreation):
      * runtime/SetIteratorConstructor.h: Added.
      (JSC::SetIteratorConstructor::create):
      (JSC::SetIteratorConstructor::createStructure):
      (JSC::SetIteratorConstructor::SetIteratorConstructor):
      * runtime/SetIteratorPrototype.cpp: Added.
      (JSC::SetIteratorPrototype::finishCreation):
      (JSC::SetIteratorPrototypeFuncIterator):
      (JSC::SetIteratorPrototypeFuncNext):
      * runtime/SetIteratorPrototype.h: Added.
      (JSC::SetIteratorPrototype::create):
      (JSC::SetIteratorPrototype::createStructure):
      (JSC::SetIteratorPrototype::SetIteratorPrototype):
      * runtime/SetPrototype.cpp:
      (JSC::SetPrototype::finishCreation):
      (JSC::setProtoFuncValues):
      (JSC::setProtoFuncEntries):
      (JSC::setProtoFuncKeys):
      
      LayoutTests:
      
      Move Set tests to more sensible location and add iterator tests
      
      * js/basic-set-expected.txt: Renamed from LayoutTests/js/dom/basic-set-expected.txt.
      * js/basic-set.html: Renamed from LayoutTests/js/dom/basic-set.html.
      * js/script-tests/basic-set.js: Renamed from LayoutTests/js/dom/script-tests/basic-set.js.
      (set new):
      (otherString.string_appeared_here.set add):
      (try.set forEach):
      (set forEach):
      (set gc):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159031 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      96cafa31
  11. 09 Nov, 2013 1 commit
    • oliver@apple.com's avatar
      Add Map Iterators · 2d11c160
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124109
      
      Reviewed by Andreas Kling.
      
      Source/JavaScriptCore:
      
      Added new Map iterator implementation.  This is a mostly boilerplate patch
      however there's a a little bit of additional logic added to the MapData iterator
      to deal with the possibility of map mutation between creation of the iterator
      and use of it.  We'll be able to improve the performance of this substantially
      by using intrinsics, however I'm pondering coming up with a better way to define
      these thunks without requiring so much duplicated logic.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * runtime/CommonIdentifiers.h:
      * runtime/JSGlobalObject.cpp:
      * runtime/JSGlobalObject.h:
      * runtime/JSMapIterator.cpp: Added.
      (JSC::JSMapIterator::finishCreation):
      (JSC::JSMapIterator::visitChildren):
      (JSC::JSMapIterator::createPair):
      * runtime/JSMapIterator.h: Added.
      (JSC::JSMapIterator::createStructure):
      (JSC::JSMapIterator::create):
      (JSC::JSMapIterator::next):
      (JSC::JSMapIterator::JSMapIterator):
      * runtime/MapData.h:
      (JSC::MapData::const_iterator::ensureSlot):
      * runtime/MapIteratorConstructor.cpp: Added.
      (JSC::MapIteratorConstructor::finishCreation):
      * runtime/MapIteratorConstructor.h: Added.
      (JSC::MapIteratorConstructor::create):
      (JSC::MapIteratorConstructor::createStructure):
      (JSC::MapIteratorConstructor::MapIteratorConstructor):
      * runtime/MapIteratorPrototype.cpp: Added.
      (JSC::MapIteratorPrototype::finishCreation):
      (JSC::MapIteratorPrototypeFuncIterator):
      (JSC::MapIteratorPrototypeFuncNext):
      * runtime/MapIteratorPrototype.h: Added.
      (JSC::MapIteratorPrototype::create):
      (JSC::MapIteratorPrototype::createStructure):
      (JSC::MapIteratorPrototype::MapIteratorPrototype):
      * runtime/MapPrototype.cpp:
      (JSC::MapPrototype::finishCreation):
      (JSC::mapProtoFuncValues):
      (JSC::mapProtoFuncEntries):
      (JSC::mapProtoFuncKeys):
      
      LayoutTests:
      
      Moved map tests to a more sensible location, and added new iteration tests.
      
      * js/basic-map-expected.txt: Renamed from LayoutTests/js/dom/basic-map-expected.txt.
      * js/basic-map.html: Renamed from LayoutTests/js/dom/basic-map.html.
      * js/script-tests/basic-map.js: Renamed from LayoutTests/js/dom/script-tests/basic-map.js.
      (set shouldBe):
      (set var):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159008 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2d11c160
  12. 08 Nov, 2013 2 commits
    • fpizlo@apple.com's avatar
      Remove dead FTL C ABI support · 89cdcd54
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124100
      
      Reviewed by Jer Noble.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * ftl/FTLCArgumentGetter.cpp: Removed.
      * ftl/FTLCArgumentGetter.h: Removed.
      * ftl/FTLOSRExitCompiler.cpp:
      * jit/FPRInfo.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158994 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      89cdcd54
    • mark.lam@apple.com's avatar
      Move breakpoint (and exception break) functionality into JSC::Debugger. · 26c53408
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=121796.
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      - In ScriptDebugServer and JSC::Debugger, SourceID and BreakpointID are
        now numeric tokens.
      
      - JSC::Debugger now tracks user defined breakpoints in a JSC::Breakpoint
        record. Previously, this info is tracked in the ScriptBreakpoint record
        in ScriptDebugServer. The only element of ScriptBreakpoint that is not
        being tracked by JSC::Breakpoint is the ScriptBreakpointAction.
           The ScriptBreakpointAction is still tracked by the ScriptDebugServer
        in a list keyed on the corresponding BreakpointID.
           The ScriptBreakpoint record is now only used as a means of passing
        breakpoint paramaters to the ScriptDebugServer.
      
      - ScriptDebugServer now no longer accesses the JSC::CallFrame* directly.
        It always goes through the DebuggerCallFrame.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * debugger/Breakpoint.h: Added.
      (JSC::Breakpoint::Breakpoint):
      - Breakpoint class to track info for each breakpoint in JSC::Debugger.
      * debugger/Debugger.cpp:
      (JSC::DebuggerCallFrameScope::DebuggerCallFrameScope):
      (JSC::DebuggerCallFrameScope::~DebuggerCallFrameScope):
      (JSC::Debugger::Debugger):
      (JSC::Debugger::detach):
      (JSC::Debugger::updateNeedForOpDebugCallbacks):
      (JSC::Debugger::setBreakpoint):
      (JSC::Debugger::removeBreakpoint):
      (JSC::Debugger::hasBreakpoint):
      (JSC::Debugger::clearBreakpoints):
      (JSC::Debugger::setBreakpointsActivated):
      (JSC::Debugger::setPauseOnExceptionsState):
      (JSC::Debugger::setPauseOnNextStatement):
      (JSC::Debugger::breakProgram):
      (JSC::Debugger::continueProgram):
      (JSC::Debugger::stepIntoStatement):
      (JSC::Debugger::stepOverStatement):
      (JSC::Debugger::stepOutOfFunction):
      (JSC::Debugger::updateCallFrame):
      (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
      (JSC::Debugger::pauseIfNeeded):
      (JSC::Debugger::exception):
      (JSC::Debugger::atStatement):
      (JSC::Debugger::callEvent):
      (JSC::Debugger::returnEvent):
      (JSC::Debugger::willExecuteProgram):
      (JSC::Debugger::didExecuteProgram):
      (JSC::Debugger::didReachBreakpoint):
      (JSC::Debugger::currentDebuggerCallFrame):
      * debugger/Debugger.h:
      * debugger/DebuggerCallFrame.cpp:
      (JSC::DebuggerCallFrame::sourceID):
      (JSC::DebuggerCallFrame::sourceIDForCallFrame):
      * debugger/DebuggerCallFrame.h:
      * debugger/DebuggerPrimitives.h: Added.
      - define SourceID, noSourceID, BreakpointID, and noBreakpointID.
      
      Source/WebCore: 
      
      No new tests.
      
      - In ScriptDebugServer and JSC::Debugger, SourceID and BreakpointID are
        now numeric tokens.
      
      - JSC::Debugger now tracks user defined breakpoints in a JSC::Breakpoint
        record. Previously, this info is tracked in the ScriptBreakpoint record
        in ScriptDebugServer. The only element of ScriptBreakpoint that is not
        being tracked by JSC::Breakpoint is the ScriptBreakpointAction.
           The ScriptBreakpointAction is still tracked by the ScriptDebugServer
        in a list keyed on the corresponding BreakpointID.
           The ScriptBreakpoint record is now only used as a means of passing
        breakpoint paramaters to the ScriptDebugServer.
      
      - ScriptDebugServer now no longer accesses the JSC::CallFrame* directly.
        It always goes through the DebuggerCallFrame.
      
      * GNUmakefile.list.am:
      * WebCore.vcxproj/WebCore.vcxproj:
      * WebCore.vcxproj/WebCore.vcxproj.filters:
      * WebCore.xcodeproj/project.pbxproj:
      * bindings/js/BreakpointID.h: Added.
      * bindings/js/ScriptDebugServer.cpp:
      (WebCore::ScriptDebugServer::ScriptDebugServer):
      (WebCore::ScriptDebugServer::setBreakpoint):
      (WebCore::ScriptDebugServer::removeBreakpoint):
      (WebCore::ScriptDebugServer::clearBreakpoints):
      (WebCore::ScriptDebugServer::dispatchDidPause):
      (WebCore::ScriptDebugServer::dispatchDidContinue):
      (WebCore::ScriptDebugServer::dispatchDidParseSource):
      (WebCore::ScriptDebugServer::notifyDoneProcessingDebuggerEvents):
      (WebCore::ScriptDebugServer::needPauseHandling):
      (WebCore::ScriptDebugServer::handleBreakpointHit):
      (WebCore::ScriptDebugServer::handleExceptionInBreakpointCondition):
      (WebCore::ScriptDebugServer::handlePause):
      * bindings/js/ScriptDebugServer.h:
      * bindings/js/SourceID.h: Added.
      * bindings/js/WorkerScriptDebugServer.cpp:
      (WebCore::WorkerScriptDebugServer::WorkerScriptDebugServer):
      * bindings/js/WorkerScriptDebugServer.h:
      * inspector/InspectorDebuggerAgent.cpp:
      (WebCore::InspectorDebuggerAgent::InspectorDebuggerAgent):
      (WebCore::parseLocation):
      (WebCore::InspectorDebuggerAgent::setBreakpoint):
      (WebCore::InspectorDebuggerAgent::continueToLocation):
      (WebCore::InspectorDebuggerAgent::resolveBreakpoint):
      (WebCore::InspectorDebuggerAgent::searchInContent):
      (WebCore::InspectorDebuggerAgent::getScriptSource):
      (WebCore::InspectorDebuggerAgent::didParseSource):
      (WebCore::InspectorDebuggerAgent::didPause):
      (WebCore::InspectorDebuggerAgent::clear):
      * inspector/InspectorDebuggerAgent.h:
      * inspector/ScriptDebugListener.h:
      
      Source/WebKit/mac: 
      
      * WebView/WebScriptDebugger.h:
      * WebView/WebScriptDebugger.mm:
      (WebScriptDebugger::WebScriptDebugger):
      (WebScriptDebugger::handlePause):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158937 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      26c53408
  13. 06 Nov, 2013 2 commits
    • oliver@apple.com's avatar
      Support iteration of the Arguments object · 125f4cff
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123835
      
      Reviewed by Mark Lam.
      
      Source/JavaScriptCore:
      
      Add an ArgumentsIterator object, and associated classes so that we can support
      iteration of the arguments object.
      
      This is a largely mechanical patch.  The only gnarliness is in the
      logic to avoid reifying the Arguments object in for(... of arguments)
      scenarios.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitEnumeration):
      * runtime/Arguments.cpp:
      (JSC::Arguments::getOwnPropertySlot):
      (JSC::argumentsFuncIterator):
      * runtime/Arguments.h:
      * runtime/ArgumentsIteratorConstructor.cpp: Added.
      (JSC::ArgumentsIteratorConstructor::finishCreation):
      * runtime/ArgumentsIteratorConstructor.h: Added.
      (JSC::ArgumentsIteratorConstructor::create):
      (JSC::ArgumentsIteratorConstructor::createStructure):
      (JSC::ArgumentsIteratorConstructor::ArgumentsIteratorConstructor):
      * runtime/ArgumentsIteratorPrototype.cpp: Added.
      (JSC::ArgumentsIteratorPrototype::finishCreation):
      (JSC::argumentsIteratorPrototypeFuncIterator):
      (JSC::argumentsIteratorPrototypeFuncNext):
      * runtime/ArgumentsIteratorPrototype.h: Added.
      (JSC::ArgumentsIteratorPrototype::create):
      (JSC::ArgumentsIteratorPrototype::createStructure):
      (JSC::ArgumentsIteratorPrototype::ArgumentsIteratorPrototype):
      * runtime/CommonIdentifiers.h:
      * runtime/JSArgumentsIterator.cpp: Added.
      (JSC::JSArgumentsIterator::finishCreation):
      * runtime/JSArgumentsIterator.h: Added.
      (JSC::JSArgumentsIterator::createStructure):
      (JSC::JSArgumentsIterator::create):
      (JSC::JSArgumentsIterator::next):
      (JSC::JSArgumentsIterator::JSArgumentsIterator):
      * runtime/JSArrayIterator.cpp:
      (JSC::createIteratorResult):
      * runtime/JSGlobalObject.cpp:
      * runtime/JSGlobalObject.h:
      
      LayoutTests:
      
      Add test cases
      
      * js/arguments-iterator-expected.txt: Added.
      * js/arguments-iterator.html: Added.
      * js/script-tests/arguments-iterator.js: Added.
      (shouldThrow.test):
      (testAlias):
      (testStrict):
      (testReifiedArguments):
      (testOverwrittenArguments):
      (testNullArguments):
      (testNonArrayLikeArguments):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      125f4cff
    • msaboff@apple.com's avatar
      Change ctiTrampoline into a thunk · adc50523
      msaboff@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123844
      
      Reviewed by Filip Pizlo.
      
      Converted ctiTrampoline and ctiOpThrowNotCaught into thunks named callToJavaScript
      and returnFromJavaScript.  Cleaned up and in some cases removed JITStubsXXX.h files
      after removing ctiTrampoline and ctiOpThrowNotCaught.  Added callJavaScriptJITFunction
      to VM that is a function pointer to the callToJavaScript thunk.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compileImpl):
      * jit/JITCode.cpp:
      (JSC::JITCode::execute):
      * jit/JITExceptions.cpp:
      (JSC::genericUnwind):
      * jit/JITStubs.cpp:
      * jit/JITStubs.h:
      * jit/JITStubsARM.h:
      * jit/JITStubsARM64.h: Removed.
      * jit/JITStubsARMv7.h:
      * jit/JITStubsMIPS.h: Removed.
      * jit/JITStubsMSVC64.asm:
      * jit/JITStubsSH4.h: Removed.
      * jit/JITStubsX86.h:
      * jit/JITStubsX86_64.h:
      * jit/JSInterfaceJIT.h:
      * jit/ThunkGenerators.cpp:
      (JSC::returnFromJavaScript):
      (JSC::callToJavaScript):
      * jit/ThunkGenerators.h:
      * runtime/VM.cpp:
      (JSC::VM::VM):
      * runtime/VM.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158751 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      adc50523
  14. 31 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      Remove CachedTranscendentalFunction because caching math functions is an ugly idea · b3336c7b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123574
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      This is performance-neutral because I also make Math.cos/sin intrinsic. This means that
      we gain the "overhead" of actually computing sin and cos but we lose the overhead of
      going through the native call thunks.
              
      Caching transcendental functions is a really ugly idea. It works for SunSpider because
      that benchmark makes very predictable calls into Math.sin. But I don't believe that this
      is representative of any kind of reality, and so for sensible uses of Math.sin/cos all
      that this was doing was adding more call overhead and some hashing overhead.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleIntrinsic):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/JITOperations.h:
      * runtime/CachedTranscendentalFunction.h: Removed.
      * runtime/DateInstanceCache.h:
      * runtime/Intrinsic.h:
      * runtime/MathObject.cpp:
      (JSC::MathObject::finishCreation):
      (JSC::mathProtoFuncCos):
      (JSC::mathProtoFuncSin):
      * runtime/VM.h:
      
      Tools: 
      
      Reviewed by Mark Hahnenberg.
      
      Make it easier to see that a test doesn't have an -expected file.
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * js/dfg-cos-constant-expected.txt: Added.
      * js/dfg-cos-constant.html: Added.
      * js/dfg-sin-constant-expected.txt: Added.
      * js/dfg-sin-constant.html: Added.
      * js/script-tests/dfg-cos-constant.js: Added.
      (foo):
      * js/script-tests/dfg-sin-constant.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158384 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b3336c7b
  15. 30 Oct, 2013 2 commits
    • ap@apple.com's avatar
      Add a way to fulfill promises from DOM code · ae921fd2
      ap@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123466
      
      Reviewed by Sam Weinig.
      
      Source/JavaScriptCore:
      
      * JavaScriptCore.xcodeproj/project.pbxproj: Make JSPromise.h and JSPromiseResolver.h
      private headers for WebCore to use.
      
      * runtime/JSPromise.h:
      * runtime/JSPromiseResolver.h:
      Export functions that JSDOMPromise will use.
      
      Source/WebCore:
      
      This is not perfect, as it strongly ties DOM code to JavaScript. In the future, we
      can make it better e.g. by subclassing, so that only a base interface would be exposed.
      
      * GNUmakefile.list.am:
      * WebCore.vcxproj/WebCore.vcxproj:
      * WebCore.vcxproj/WebCore.vcxproj.filters:
      * bindings/js/JSBindingsAllInOne.cpp:
      * WebCore.xcodeproj/project.pbxproj:
      Added JSDOMPromise.
      
      * bindings/js/JSDOMPromise.cpp: Added.
      
      * bindings/js/JSDOMPromise.h: Added.
      (WebCore::PromiseWrapper::create):
      (WebCore::PromiseWrapper::fulfill): A random set of specializations that I needed
      in WebCrypto code so far.
      (WebCore::PromiseWrapper::reject): Ditto.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158317 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ae921fd2
    • fpizlo@apple.com's avatar
      Add InvalidationPoints to the DFG and use them for all watchpoints · d84425d1
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123472
      
      Reviewed by Mark Hahnenberg.
              
      This makes a fundamental change to how watchpoints work in the DFG.
              
      Previously, a watchpoint was an instruction whose execution semantics were something
      like:
              
          if (watchpoint->invalidated)
              exit
              
      We would implement this without any branch by using jump replacement.
              
      This is a very good optimization. But it's a bit awkward once you get a lot of
      watchpoints: semantically we will have lots of these branches in the code, which the
      compiler needs to reason about even though they don't actually result in any emitted
      code.
              
      Separately, we also had a mechanism for jettisoning a CodeBlock. This mechanism would
      be invoked if a CodeBlock exited a lot. It would ensure that a CodeBlock wouldn't be
      called into again, but it would do nothing for CodeBlocks that were already on the
      stack.
              
      This change flips jettisoning and watchpoint invalidation on their heads. Now, the jump
      replacement has nothing to do with watchpoints; instead it's something that happens if
      you ever jettison a CodeBlock. Jump replacement is now an all-or-nothing operation over
      all of the potential call-return safe-exit-points in a CodeBlock. We call these
      "InvalidationPoint"s. A watchpoint instruction is now "lowered" by having the DFG
      collect all of the watchpoint sets that the CodeBlock cares about, and then registering
      a CodeBlockJettisoningWatchpoint with all of them. That is, if the watchpoint fires, it
      jettisons the CodeBlock, which in turn ensures that the CodeBlock can't be called into
      (because the entrypoint now points to baseline code) and can't be returned into
      (because returning exits to baseline before the next bytecode instruction).
              
      This will allow for a sensible lowering of watchpoints to LLVM IR. It will also allow
      for jettison() to be used effectively for things like breakpointing and single-stepping
      in the debugger.
              
      Well, basically, this mechanism just takes us into the HotSpot-style world where anyone
      can, at any time and for any reason, request that an optimized CodeBlock is rendered
      immediately invalid. You can use this for many cool things, I'm sure.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/AbstractMacroAssembler.h:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::jettison):
      * bytecode/CodeBlock.h:
      * bytecode/CodeBlockJettisoningWatchpoint.cpp: Added.
      (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
      * bytecode/CodeBlockJettisoningWatchpoint.h: Added.
      (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint):
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      * bytecode/ExitKind.h:
      * bytecode/ProfiledCodeBlockJettisoningWatchpoint.cpp: Added.
      (JSC::ProfiledCodeBlockJettisoningWatchpoint::fireInternal):
      * bytecode/ProfiledCodeBlockJettisoningWatchpoint.h: Added.
      (JSC::ProfiledCodeBlockJettisoningWatchpoint::ProfiledCodeBlockJettisoningWatchpoint):
      * dfg/DFGAbstractHeap.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGClobberize.cpp:
      (JSC::DFG::writesOverlap):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      (JSC::DFG::AbstractHeapOverlaps::AbstractHeapOverlaps):
      (JSC::DFG::AbstractHeapOverlaps::operator()):
      (JSC::DFG::AbstractHeapOverlaps::result):
      * dfg/DFGCommonData.cpp:
      (JSC::DFG::CommonData::invalidate):
      * dfg/DFGCommonData.h:
      (JSC::DFG::CommonData::CommonData):
      * dfg/DFGDesiredWatchpoints.cpp:
      (JSC::DFG::DesiredWatchpoints::addLazily):
      (JSC::DFG::DesiredWatchpoints::reallyAdd):
      * dfg/DFGDesiredWatchpoints.h:
      (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet):
      (JSC::DFG::GenericDesiredWatchpoints::addLazily):
      (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
      (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGInvalidationPointInjectionPhase.cpp: Added.
      (JSC::DFG::InvalidationPointInjectionPhase::InvalidationPointInjectionPhase):
      (JSC::DFG::InvalidationPointInjectionPhase::run):
      (JSC::DFG::InvalidationPointInjectionPhase::handle):
      (JSC::DFG::InvalidationPointInjectionPhase::insertInvalidationCheck):
      (JSC::DFG::performInvalidationPointInjection):
      * dfg/DFGInvalidationPointInjectionPhase.h: Added.
      * dfg/DFGJITCode.h:
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::linkOSRExits):
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      * dfg/DFGJumpReplacement.cpp: Added.
      (JSC::DFG::JumpReplacement::fire):
      * dfg/DFGJumpReplacement.h: Added.
      (JSC::DFG::JumpReplacement::JumpReplacement):
      * dfg/DFGNodeType.h:
      * dfg/DFGOSRExitCompilationInfo.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      (JSC::DFG::Plan::reallyAdd):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
      (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
      (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
      (JSC::DFG::SpeculativeJIT::compileObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
      (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
      (JSC::DFG::SpeculativeJIT::compileObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp: Added.
      (JSC::DFG::WatchpointCollectionPhase::WatchpointCollectionPhase):
      (JSC::DFG::WatchpointCollectionPhase::run):
      (JSC::DFG::WatchpointCollectionPhase::handle):
      (JSC::DFG::WatchpointCollectionPhase::handleEdge):
      (JSC::DFG::WatchpointCollectionPhase::handleMasqueradesAsUndefined):
      (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal):
      (JSC::DFG::WatchpointCollectionPhase::addLazily):
      (JSC::DFG::WatchpointCollectionPhase::globalObject):
      (JSC::DFG::performWatchpointCollection):
      * dfg/DFGWatchpointCollectionPhase.h: Added.
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
      (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
      (JSC::FTL::LowerDFGToLLVM::compileGlobalVarWatchpoint):
      (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
      (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
      (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
      (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
      * jit/JITOperations.cpp:
      * jit/JumpReplacementWatchpoint.cpp: Removed.
      * jit/JumpReplacementWatchpoint.h: Removed.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d84425d1
  16. 25 Oct, 2013 1 commit
    • jer.noble@apple.com's avatar
      [Mac] Add helper methods to convert CMTime <--> MediaTime · 99947cbf
      jer.noble@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123285
      
      Reviewed by Eric Carlson.
      
      Source/WebCore:
      
      Add utility methods to convert between CMTime (a rational time class) and MediaTime.
      Once there, PlatformClockCM can now vend and accept MediaTimes for currentTime.
      
      * platform/mac/MediaTimeMac.h:
      * platform/mac/MediaTimeMac.cpp:
      (WebCore::toMediaTime): Added conversion utility method.
      (WebCore::toCMTime): Ditto.
      
      * platform/mac/PlatformClockCM.h:
      * platform/mac/PlatformClockCM.mm:
      (PlatformClockCM::setCurrentMediaTime): Added.
      (PlatformClockCM::currentMediaTime): Added.
      
      * WebCore.xcodeproj/project.pbxproj: Add new files to project.
      
      Source/WTF:
      
      Add a #ifdef header_h protector.
      
      * wtf/MediaTime.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157991 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      99947cbf
  17. 23 Oct, 2013 2 commits
    • fpizlo@apple.com's avatar
      FTL should be able to do some simple inline caches using LLVM patchpoints · 2e7ada00
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123164
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      This implements GetById inline caches in the FTL using llvm.webkit.patchpoint.
              
      The idea is that we ask LLVM for a nop slide the size of a GetById inline
      cache and then fill in the code after LLVM compilation is complete. For now, we
      just use the system calling convention for the arguments and return. We also
      still make some assumptions about registers that aren't correct. But, most of
      the scaffolding is there and this will successfully patch an inline cache.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/AbstractMacroAssembler.h:
      * assembler/LinkBuffer.cpp:
      (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
      (JSC::LinkBuffer::linkCode):
      (JSC::LinkBuffer::allocate):
      * assembler/LinkBuffer.h:
      (JSC::LinkBuffer::LinkBuffer):
      (JSC::LinkBuffer::link):
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::constNull):
      (JSC::FTL::buildCall):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::fixFunctionBasedOnStackMaps):
      * ftl/FTLInlineCacheDescriptor.h: Added.
      (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
      (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
      (JSC::FTL::GetByIdDescriptor::stackmapID):
      (JSC::FTL::GetByIdDescriptor::codeOrigin):
      (JSC::FTL::GetByIdDescriptor::uid):
      * ftl/FTLInlineCacheSize.cpp: Added.
      (JSC::FTL::sizeOfGetById):
      (JSC::FTL::sizeOfPutById):
      * ftl/FTLInlineCacheSize.h: Added.
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLJITFinalizer.cpp:
      (JSC::FTL::JITFinalizer::finalizeFunction):
      * ftl/FTLJITFinalizer.h:
      * ftl/FTLLocation.cpp:
      (JSC::FTL::Location::directGPR):
      * ftl/FTLLocation.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileGetById):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::call):
      * ftl/FTLSlowPathCall.cpp: Added.
      (JSC::FTL::callOperation):
      * ftl/FTLSlowPathCall.h: Added.
      (JSC::FTL::SlowPathCall::SlowPathCall):
      (JSC::FTL::SlowPathCall::call):
      (JSC::FTL::SlowPathCall::key):
      * ftl/FTLSlowPathCallKey.cpp: Added.
      (JSC::FTL::SlowPathCallKey::dump):
      * ftl/FTLSlowPathCallKey.h: Added.
      (JSC::FTL::SlowPathCallKey::SlowPathCallKey):
      (JSC::FTL::SlowPathCallKey::usedRegisters):
      (JSC::FTL::SlowPathCallKey::callTarget):
      (JSC::FTL::SlowPathCallKey::offset):
      (JSC::FTL::SlowPathCallKey::isEmptyValue):
      (JSC::FTL::SlowPathCallKey::isDeletedValue):
      (JSC::FTL::SlowPathCallKey::operator==):
      (JSC::FTL::SlowPathCallKey::hash):
      (JSC::FTL::SlowPathCallKeyHash::hash):
      (JSC::FTL::SlowPathCallKeyHash::equal):
      * ftl/FTLStackMaps.cpp:
      (JSC::FTL::StackMaps::Location::directGPR):
      * ftl/FTLStackMaps.h:
      * ftl/FTLState.h:
      * ftl/FTLThunks.cpp:
      (JSC::FTL::slowPathCallThunkGenerator):
      * ftl/FTLThunks.h:
      (JSC::FTL::Thunks::getSlowPathCallThunk):
      * jit/CCallHelpers.h:
      (JSC::CCallHelpers::setupArguments):
      * jit/GPRInfo.h:
      * jit/JITInlineCacheGenerator.cpp:
      (JSC::garbageStubInfo):
      (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
      (JSC::JITByIdGenerator::finalize):
      * jit/JITInlineCacheGenerator.h:
      (JSC::JITByIdGenerator::slowPathBegin):
      * jit/RegisterSet.cpp:
      (JSC::RegisterSet::stackRegisters):
      (JSC::RegisterSet::specialRegisters):
      (JSC::RegisterSet::calleeSaveRegisters):
      (JSC::RegisterSet::allGPRs):
      (JSC::RegisterSet::allFPRs):
      (JSC::RegisterSet::allRegisters):
      (JSC::RegisterSet::dump):
      * jit/RegisterSet.h:
      (JSC::RegisterSet::exclude):
      (JSC::RegisterSet::numberOfSetRegisters):
      (JSC::RegisterSet::RegisterSet):
      (JSC::RegisterSet::isEmptyValue):
      (JSC::RegisterSet::isDeletedValue):
      (JSC::RegisterSet::operator==):
      (JSC::RegisterSet::hash):
      (JSC::RegisterSetHash::hash):
      (JSC::RegisterSetHash::equal):
      * runtime/Options.h:
      
      Source/WTF: 
      
      Reviewed by Mark Hahnenberg.
              
      This needed some better bitvector support, like merging (|=), excluding (&=~),
      hashing, and bit counting.
      
      * wtf/BitVector.cpp:
      (WTF::BitVector::setSlow):
      (WTF::BitVector::excludeSlow):
      (WTF::BitVector::bitCountSlow):
      (WTF::BitVector::equalsSlowCase):
      (WTF::BitVector::hashSlowCase):
      (WTF::BitVector::dump):
      * wtf/BitVector.h:
      (WTF::BitVector::merge):
      (WTF::BitVector::exclude):
      (WTF::BitVector::bitCount):
      (WTF::BitVector::BitVector):
      (WTF::BitVector::isEmptyValue):
      (WTF::BitVector::isDeletedValue):
      (WTF::BitVector::isEmptyOrDeletedValue):
      (WTF::BitVector::operator==):
      (WTF::BitVector::hash):
      (WTF::BitVectorHash::hash):
      (WTF::BitVectorHash::equal):
      * wtf/HashTraits.h:
      (WTF::CustomHashTraits::constructDeletedValue):
      (WTF::CustomHashTraits::isDeletedValue):
      (WTF::CustomHashTraits::emptyValue):
      (WTF::CustomHashTraits::isEmptyValue):
      * wtf/StdLibExtras.h:
      (WTF::bitCount):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157872 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2e7ada00
    • dbates@webkit.org's avatar
      [iOS] Upstream more JavaScriptCore build configuration changes · dd225b04
      dbates@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=123169
      
      Reviewed by David Kilzer.
      
      * Configurations/Base.xcconfig:
      * Configurations/Version.xcconfig:
      * Configurations/iOS.xcconfig: Added.
      * JavaScriptCore.xcodeproj/project.pbxproj:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157864 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      dd225b04
  18. 20 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      StructureStubInfo's usedRegisters set should be able to track all registers,... · 9dbc4b4f
      fpizlo@apple.com authored
      StructureStubInfo's usedRegisters set should be able to track all registers, not just the ones that our JIT's view as temporaries
      https://bugs.webkit.org/show_bug.cgi?id=123076
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      Start preparing for a world in which we are patching code generated by LLVM, which may have
      very different register usage conventions than our JITs. This requires us being more explicit
      about the registers we are using. For example, the repatching code shouldn't take for granted
      that tagMaskRegister holds the TagMask or that the register is even in use.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/MacroAssembler.h:
      (JSC::MacroAssembler::numberOfRegisters):
      (JSC::MacroAssembler::registerIndex):
      (JSC::MacroAssembler::numberOfFPRegisters):
      (JSC::MacroAssembler::fpRegisterIndex):
      (JSC::MacroAssembler::totalNumberOfRegisters):
      * bytecode/StructureStubInfo.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::usedRegisters):
      * dfg/DFGSpeculativeJIT.h:
      * ftl/FTLSaveRestore.cpp:
      (JSC::FTL::bytesForGPRs):
      (JSC::FTL::bytesForFPRs):
      (JSC::FTL::offsetOfGPR):
      (JSC::FTL::offsetOfFPR):
      * jit/JITInlineCacheGenerator.cpp:
      (JSC::JITByIdGenerator::JITByIdGenerator):
      (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
      * jit/JITInlineCacheGenerator.h:
      (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emit_op_put_by_id):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emit_op_put_by_id):
      * jit/RegisterSet.cpp: Added.
      (JSC::RegisterSet::specialRegisters):
      * jit/RegisterSet.h: Added.
      (JSC::RegisterSet::RegisterSet):
      (JSC::RegisterSet::set):
      (JSC::RegisterSet::clear):
      (JSC::RegisterSet::get):
      (JSC::RegisterSet::merge):
      * jit/Repatch.cpp:
      (JSC::generateProtoChainAccessStub):
      (JSC::tryCacheGetByID):
      (JSC::tryBuildGetByIDList):
      (JSC::emitPutReplaceStub):
      (JSC::tryRepatchIn):
      (JSC::linkClosureCall):
      * jit/TempRegisterSet.cpp: Added.
      (JSC::TempRegisterSet::TempRegisterSet):
      * jit/TempRegisterSet.h:
      
      Source/WTF: 
      
      Reviewed by Sam Weinig.
              
      Teach BitVector how to efficiently merge (i.e. bitvector |=).
      
      * wtf/BitVector.cpp:
      (WTF::BitVector::mergeSlow):
      * wtf/BitVector.h:
      (WTF::BitVector::merge):
      (WTF::BitVector::cleanseInlineBits):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157707 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9dbc4b4f
  19. 19 Oct, 2013 2 commits
    • fpizlo@apple.com's avatar
      Rename RegisterSet to TempRegisterSet · e5e2d4e7
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123077
      
      Reviewed by Dan Bernstein.
      
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/StructureStubInfo.h:
      * dfg/DFGJITCompiler.h:
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::usedRegisters):
      * jit/JITInlineCacheGenerator.cpp:
      (JSC::JITByIdGenerator::JITByIdGenerator):
      (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
      * jit/JITInlineCacheGenerator.h:
      (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emit_op_put_by_id):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emit_op_put_by_id):
      * jit/RegisterSet.h: Removed.
      * jit/ScratchRegisterAllocator.h:
      (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator):
      * jit/TempRegisterSet.h: Copied from Source/JavaScriptCore/jit/RegisterSet.h.
      (JSC::TempRegisterSet::TempRegisterSet):
      (JSC::TempRegisterSet::asPOD):
      (JSC::TempRegisterSet::copyInfo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157693 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e5e2d4e7
    • fpizlo@apple.com's avatar
      Baseline JIT and DFG IC code generation should be unified and rationalized · 5ba07883
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122939
      
      Reviewed by Geoffrey Garen.
              
      Introduce the JITInlineCacheGenerator, which takes a CodeBlock and a CodeOrigin plus
      some register info and creates JIT inline caches for you. Used this to even furhter
      unify the baseline and DFG ICs. In the future we can use this for FTL ICs. And my hope
      is that we'll be able to use it for cascading ICs: an IC for some instruction may realize
      that it needs to do the equivalent of get_by_id, so with this generator it will be able
      to create an IC even though it wasn't associated with a get_by_id bytecode instruction.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/AbstractMacroAssembler.h:
      (JSC::AbstractMacroAssembler::DataLabelCompact::label):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::ecmaMode):
      * dfg/DFGInlineCacheWrapper.h: Added.
      (JSC::DFG::InlineCacheWrapper::InlineCacheWrapper):
      * dfg/DFGInlineCacheWrapperInlines.h: Added.
      (JSC::DFG::::finalize):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::addGetById):
      (JSC::DFG::JITCompiler::addPutById):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::cachedGetById):
      (JSC::DFG::SpeculativeJIT::cachedPutById):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::cachedGetById):
      (JSC::DFG::SpeculativeJIT::cachedPutById):
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/AssemblyHelpers.h:
      (JSC::AssemblyHelpers::isStrictModeFor):
      (JSC::AssemblyHelpers::strictModeFor):
      * jit/GPRInfo.h:
      (JSC::JSValueRegs::tagGPR):
      * jit/JIT.cpp:
      (JSC::JIT::JIT):
      (JSC::JIT::privateCompileSlowCases):
      (JSC::JIT::privateCompile):
      * jit/JIT.h:
      * jit/JITInlineCacheGenerator.cpp: Added.
      (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
      (JSC::JITByIdGenerator::JITByIdGenerator):
      (JSC::JITByIdGenerator::finalize):
      (JSC::JITByIdGenerator::generateFastPathChecks):
      (JSC::JITGetByIdGenerator::generateFastPath):
      (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
      (JSC::JITPutByIdGenerator::generateFastPath):
      (JSC::JITPutByIdGenerator::slowPathFunction):
      * jit/JITInlineCacheGenerator.h: Added.
      (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
      (JSC::JITInlineCacheGenerator::stubInfo):
      (JSC::JITByIdGenerator::JITByIdGenerator):
      (JSC::JITByIdGenerator::reportSlowPathCall):
      (JSC::JITByIdGenerator::slowPathJump):
      (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
      (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emitSlow_op_get_by_id):
      (JSC::JIT::emit_op_put_by_id):
      (JSC::JIT::emitSlow_op_put_by_id):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emit_op_get_by_id):
      (JSC::JIT::emitSlow_op_get_by_id):
      (JSC::JIT::emit_op_put_by_id):
      (JSC::JIT::emitSlow_op_put_by_id):
      * jit/RegisterSet.h:
      (JSC::RegisterSet::set):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157685 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5ba07883
  20. 17 Oct, 2013 1 commit
    • oliver@apple.com's avatar
      Remove JITStubCall.h · bac8be98
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122991
      
      Reviewed by Geoff Garen.
      
      Happily this is no longer used
      
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * jit/JIT.cpp:
      * jit/JITArithmetic.cpp:
      * jit/JITArithmetic32_64.cpp:
      * jit/JITCall.cpp:
      * jit/JITCall32_64.cpp:
      * jit/JITOpcodes.cpp:
      * jit/JITOpcodes32_64.cpp:
      * jit/JITPropertyAccess.cpp:
      * jit/JITPropertyAccess32_64.cpp:
      * jit/JITStubCall.h: Removed.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157603 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      bac8be98
  21. 16 Oct, 2013 1 commit
    • mhahnenberg@apple.com's avatar
      llint_slow_path_put_by_id can deadlock on a ConcurrentJITLock · efd0d517
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122667
      
      Reviewed by Geoffrey Garen.
      
      The issue this patch is attempting to fix is that there are places in our codebase
      where we acquire the ConcurrentJITLock for a particular CodeBlock, then we do some
      operations that can initiate a garbage collection. Garbage collection then calls 
      some methods of CodeBlock that also take the ConcurrentJITLock (because they don't
      always necessarily run during garbage collection). This causes a deadlock.
       
      To fix this issue, this patch adds a new RAII-style object (DisallowGC) that stores 
      into a thread-local field that indicates that it is unsafe to perform any operation 
      that could trigger garbage collection on the current thread. In debug builds, 
      ConcurrentJITLocker contains one of these DisallowGC objects so that we can eagerly 
      detect deadlocks.
       
      This patch also adds a new type of ConcurrentJITLocker, GCSafeConcurrentJITLocker,
      which uses the DeferGC mechanism to prevent collections from occurring while the 
      lock is held.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * heap/DeferGC.h:
      (JSC::DisallowGC::DisallowGC):
      (JSC::DisallowGC::~DisallowGC):
      (JSC::DisallowGC::isGCDisallowedOnCurrentThread):
      (JSC::DisallowGC::initialize):
      * jit/Repatch.cpp:
      (JSC::repatchPutByID):
      (JSC::buildPutByIdList):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * runtime/ConcurrentJITLock.h:
      (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
      (JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase):
      (JSC::ConcurrentJITLockerBase::unlockEarly):
      (JSC::GCSafeConcurrentJITLocker::GCSafeConcurrentJITLocker):
      (JSC::GCSafeConcurrentJITLocker::~GCSafeConcurrentJITLocker):
      (JSC::GCSafeConcurrentJITLocker::NoDefer::NoDefer):
      (JSC::ConcurrentJITLocker::ConcurrentJITLocker):
      * runtime/InitializeThreading.cpp:
      (JSC::initializeThreadingOnce):
      * runtime/JSCellInlines.h:
      (JSC::allocateCell):
      * runtime/JSSymbolTableObject.h:
      (JSC::symbolTablePut):
      * runtime/Structure.cpp: materializePropertyMapIfNecessary* now has a problem in that it
      can start a garbage collection when the GCSafeConcurrentJITLocker goes out of scope, but 
      before the caller has a chance to use the newly created PropertyTable. The garbage collection
      clears the PropertyTable, and then the caller uses it assuming it's valid. To avoid this,
      we must DeferGC until the caller is done getting the newly materialized PropertyTable from 
      the Structure.
      (JSC::Structure::materializePropertyMap):
      (JSC::Structure::despecifyDictionaryFunction):
      (JSC::Structure::changePrototypeTransition):
      (JSC::Structure::despecifyFunctionTransition):
      (JSC::Structure::attributeChangeTransition):
      (JSC::Structure::toDictionaryTransition):
      (JSC::Structure::preventExtensionsTransition):
      (JSC::Structure::takePropertyTableOrCloneIfPinned):
      (JSC::Structure::isSealed):
      (JSC::Structure::isFrozen):
      (JSC::Structure::addPropertyWithoutTransition):
      (JSC::Structure::removePropertyWithoutTransition):
      (JSC::Structure::get):
      (JSC::Structure::despecifyFunction):
      (JSC::Structure::despecifyAllFunctions):
      (JSC::Structure::putSpecificValue):
      (JSC::Structure::createPropertyMap):
      (JSC::Structure::getPropertyNamesFromStructure):
      * runtime/Structure.h:
      (JSC::Structure::materializePropertyMapIfNecessary):
      (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
      * runtime/StructureInlines.h:
      (JSC::Structure::get):
      * runtime/SymbolTable.h:
      (JSC::SymbolTable::find):
      (JSC::SymbolTable::end):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157539 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      efd0d517
  22. 15 Oct, 2013 2 commits
    • dbates@webkit.org's avatar
      [iOS] Upstream JavaScriptCore support for ARM64 · 98f0de07
      dbates@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=122762
      
      Source/JavaScriptCore:
      
      Reviewed by Oliver Hunt and Filip Pizlo.
      
      * Configurations/Base.xcconfig:
      * Configurations/DebugRelease.xcconfig:
      * Configurations/JavaScriptCore.xcconfig:
      * Configurations/ToolExecutable.xcconfig:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/ARM64Assembler.h: Added.
      * assembler/AbstractMacroAssembler.h:
      (JSC::isARM64):
      (JSC::AbstractMacroAssembler::Label::Label):
      (JSC::AbstractMacroAssembler::Jump::Jump):
      (JSC::AbstractMacroAssembler::Jump::link):
      (JSC::AbstractMacroAssembler::Jump::linkTo):
      (JSC::AbstractMacroAssembler::CachedTempRegister::CachedTempRegister):
      (JSC::AbstractMacroAssembler::CachedTempRegister::registerIDInvalidate):
      (JSC::AbstractMacroAssembler::CachedTempRegister::registerIDNoInvalidate):
      (JSC::AbstractMacroAssembler::CachedTempRegister::value):
      (JSC::AbstractMacroAssembler::CachedTempRegister::setValue):
      (JSC::AbstractMacroAssembler::CachedTempRegister::invalidate):
      (JSC::AbstractMacroAssembler::invalidateAllTempRegisters):
      (JSC::AbstractMacroAssembler::isTempRegisterValid):
      (JSC::AbstractMacroAssembler::clearTempRegisterValid):
      (JSC::AbstractMacroAssembler::setTempRegisterValid):
      * assembler/LinkBuffer.cpp:
      (JSC::LinkBuffer::copyCompactAndLinkCode):
      (JSC::LinkBuffer::linkCode):
      * assembler/LinkBuffer.h:
      * assembler/MacroAssembler.h:
      (JSC::MacroAssembler::isPtrAlignedAddressOffset):
      (JSC::MacroAssembler::pushToSave):
      (JSC::MacroAssembler::popToRestore):
      (JSC::MacroAssembler::patchableBranchTest32):
      * assembler/MacroAssemblerARM64.h: Added.
      * assembler/MacroAssemblerARMv7.h:
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGOSRExitCompiler32_64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileArithDiv):
      (JSC::DFG::SpeculativeJIT::compileArithMod):
      * disassembler/ARM64/A64DOpcode.cpp: Added.
      * disassembler/ARM64/A64DOpcode.h: Added.
      * disassembler/ARM64Disassembler.cpp: Added.
      * heap/MachineStackMarker.cpp:
      (JSC::getPlatformThreadRegisters):
      (JSC::otherThreadStackPointer):
      * heap/Region.h:
      * jit/AssemblyHelpers.h:
      (JSC::AssemblyHelpers::debugCall):
      * jit/CCallHelpers.h:
      * jit/ExecutableAllocator.h:
      * jit/FPRInfo.h:
      (JSC::FPRInfo::toRegister):
      (JSC::FPRInfo::toIndex):
      (JSC::FPRInfo::debugName):
      * jit/GPRInfo.h:
      (JSC::GPRInfo::toRegister):
      (JSC::GPRInfo::toIndex):
      (JSC::GPRInfo::debugName):
      * jit/JITInlines.h:
      (JSC::JIT::restoreArgumentReferenceForTrampoline):
      * jit/JITOperationWrappers.h:
      * jit/JITOperations.cpp:
      * jit/JITStubs.cpp:
      (JSC::performPlatformSpecificJITAssertions):
      (JSC::tryCachePutByID):
      * jit/JITStubs.h:
      (JSC::JITStackFrame::returnAddressSlot):
      * jit/JITStubsARM64.h: Added.
      * jit/JSInterfaceJIT.h:
      * jit/Repatch.cpp:
      (JSC::emitRestoreScratch):
      (JSC::generateProtoChainAccessStub):
      (JSC::tryCacheGetByID):
      (JSC::emitPutReplaceStub):
      (JSC::tryCachePutByID):
      (JSC::tryRepatchIn):
      * jit/ScratchRegisterAllocator.h:
      (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
      (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
      * jit/ThunkGenerators.cpp:
      (JSC::nativeForGenerator):
      (JSC::floorThunkGenerator):
      (JSC::ceilThunkGenerator):
      * jsc.cpp:
      (main):
      * llint/LLIntOfflineAsmConfig.h:
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::handleHostCall):
      * llint/LowLevelInterpreter.asm:
      * llint/LowLevelInterpreter64.asm:
      * offlineasm/arm.rb:
      * offlineasm/arm64.rb: Added.
      * offlineasm/backends.rb:
      * offlineasm/instructions.rb:
      * offlineasm/risc.rb:
      * offlineasm/transform.rb:
      * yarr/YarrJIT.cpp:
      (JSC::Yarr::YarrGenerator::alignCallFrameSizeInBytes):
      (JSC::Yarr::YarrGenerator::initCallFrame):
      (JSC::Yarr::YarrGenerator::removeCallFrame):
      (JSC::Yarr::YarrGenerator::generateEnter):
      * yarr/YarrJIT.h:
      
      Source/WTF:
      
      Reviewed by Oliver Hunt.
      
      * Configurations/Base.xcconfig:
      * wtf/Atomics.h:
      (WTF::weakCompareAndSwap):
      (WTF::armV7_dmb):
      * wtf/FastMalloc.cpp:
      * wtf/Platform.h:
      * wtf/dtoa.cpp:
      * wtf/dtoa/utils.h:
      * wtf/text/ASCIIFastPath.h:
      (WTF::copyLCharsFromUCharSource):
      * wtf/text/StringImpl.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157474 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      98f0de07
    • mhahnenberg@apple.com's avatar
      ObjCCallbackFunctionImpl shouldn't store a JSContext · e4b8bb7e
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122531
      
      Reviewed by Geoffrey Garen.
      
      The m_context field in ObjCCallbackFunctionImpl is vestigial and is only incidentally correct
      in the common case. It's also no longer necessary in that we can look up the current JSContext
      by looking using the globalObject of the callee when the function callback is invoked.
      
      Also added a new test that would cause us to crash previously. The test required making
      JSContextGetGlobalContext public API so that clients can obtain a JSContext from the JSContextRef
      in C API callbacks.
      
      * API/JSContextRef.h:
      * API/JSContextRefPrivate.h:
      * API/ObjCCallbackFunction.mm:
      (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl):
      (JSC::objCCallbackFunctionCallAsFunction):
      (objCCallbackFunctionForInvocation):
      * API/WebKitAvailability.h:
      * API/tests/CurrentThisInsideBlockGetterTest.h: Added.
      * API/tests/CurrentThisInsideBlockGetterTest.mm: Added.
      (CallAsConstructor):
      (ConstructorFinalize):
      (ConstructorClass):
      (+[JSValue valueWithConstructorDescriptor:inContext:]):
      (-[JSContext valueWithConstructorDescriptor:]):
      (currentThisInsideBlockGetterTest):
      * API/tests/testapi.mm:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * debugger/Debugger.cpp: Had to add some fully qualified names to avoid conflicts with Mac OS X headers.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157468 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e4b8bb7e
  23. 14 Oct, 2013 2 commits
    • commit-queue@webkit.org's avatar
      Unreviewed, rolling out r157413. · 68083b55
      commit-queue@webkit.org authored
      http://trac.webkit.org/changeset/157413
      https://bugs.webkit.org/show_bug.cgi?id=122779
      
      Appears to have caused frequent crashes (Requested by ap on
      #webkit).
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * heap/DeferGC.cpp: Removed.
      * heap/DeferGC.h:
      * jit/JITStubs.cpp:
      (JSC::tryCacheGetByID):
      (JSC::DEFINE_STUB_FUNCTION):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * runtime/ConcurrentJITLock.h:
      * runtime/InitializeThreading.cpp:
      (JSC::initializeThreadingOnce):
      * runtime/JSCellInlines.h:
      (JSC::allocateCell):
      * runtime/Structure.cpp:
      (JSC::Structure::materializePropertyMap):
      (JSC::Structure::putSpecificValue):
      (JSC::Structure::createPropertyMap):
      * runtime/Structure.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157424 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      68083b55
    • mhahnenberg@apple.com's avatar
      llint_slow_path_put_by_id can deadlock on a ConcurrentJITLock · e8cc67f5
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122667
      
      Reviewed by Filip Pizlo.
      
      The issue this patch is attempting to fix is that there are places in our codebase
      where we acquire the ConcurrentJITLock for a particular CodeBlock, then we do some
      operations that can initiate a garbage collection. Garbage collection then calls 
      some methods of CodeBlock that also take the ConcurrentJITLock (because they don't
      always necessarily run during garbage collection). This causes a deadlock.
      
      To fix this issue, this patch adds a new RAII-style object (DisallowGC) that stores 
      into a thread-local field that indicates that it is unsafe to perform any operation 
      that could trigger garbage collection on the current thread. In debug builds, 
      ConcurrentJITLocker contains one of these DisallowGC objects so that we can eagerly 
      detect deadlocks.
      
      This patch also adds a new type of ConcurrentJITLocker, GCSafeConcurrentJITLocker,
      which uses the DeferGC mechanism to prevent collections from occurring while the 
      lock is held.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * heap/DeferGC.cpp: Added.
      * heap/DeferGC.h:
      (JSC::DisallowGC::DisallowGC):
      (JSC::DisallowGC::~DisallowGC):
      (JSC::DisallowGC::isGCDisallowedOnCurrentThread):
      (JSC::DisallowGC::initialize):
      * jit/JITStubs.cpp:
      (JSC::tryCachePutByID):
      (JSC::tryCacheGetByID):
      (JSC::DEFINE_STUB_FUNCTION):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * runtime/ConcurrentJITLock.h:
      (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
      (JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase):
      (JSC::ConcurrentJITLockerBase::unlockEarly):
      (JSC::GCSafeConcurrentJITLocker::GCSafeConcurrentJITLocker):
      (JSC::ConcurrentJITLocker::ConcurrentJITLocker):
      * runtime/InitializeThreading.cpp:
      (JSC::initializeThreadingOnce):
      * runtime/JSCellInlines.h:
      (JSC::allocateCell):
      * runtime/Structure.cpp:
      (JSC::Structure::materializePropertyMap):
      (JSC::Structure::putSpecificValue):
      (JSC::Structure::createPropertyMap):
      * runtime/Structure.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157413 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e8cc67f5
  24. 10 Oct, 2013 4 commits
    • fpizlo@apple.com's avatar
      OSR exit using llvm.webkit.stackmap should pass more tests · 50cd41c0
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122518
      
      Reviewed by Mark Hahnenberg.
              
      - Make the X86Assembler capable of dealing with all XMM registers.
              
      - Make the StackMaps code on WebKit's side capable of dealing with XMM registers.
              
      - Factor out most of the smarts of StackMaps::Location into a self-contained object.
        Previously you needed both StackMaps::Location and a StackMaps reference to do most
        things since the Location might have referred to a constant. Now you can just get a
        self-contained Location object.
              
      - Fix a bug where OSR exit generation thunk generator was assuming that the call frame
        register is already in argumentGPR0. In the future, the call frame will just be the
        machine FP and we won't have to do anything special. But for now the "call frame" is
        just a normal value in LLVM IR and may end up in any register. Make the OSR exit
        generation thunk generator polymorphic over the call frame argument's Location.
              
      - Move the stuff that depends on the polymorphic OSR exit generation thunk generator
        into the finalizer, since generating and linking one of those thunks requires a cache
        flush and we need to do that on the main thread.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/ARMv7Assembler.h:
      (JSC::ARMv7Assembler::firstRegister):
      (JSC::ARMv7Assembler::lastRegister):
      (JSC::ARMv7Assembler::firstFPRegister):
      (JSC::ARMv7Assembler::lastFPRegister):
      * assembler/AbstractMacroAssembler.h:
      (JSC::AbstractMacroAssembler::firstFPRegister):
      (JSC::AbstractMacroAssembler::lastFPRegister):
      * assembler/MacroAssembler.h:
      (JSC::MacroAssembler::nextFPRegister):
      * assembler/MacroAssemblerARMv7.h:
      * assembler/MacroAssemblerX86Common.h:
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::firstFPRegister):
      (JSC::X86Assembler::lastFPRegister):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compileImpl):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::fixFunctionBasedOnStackMaps):
      * ftl/FTLExitThunkGenerator.cpp:
      (JSC::FTL::ExitThunkGenerator::emitThunk):
      (JSC::FTL::ExitThunkGenerator::emitThunks):
      * ftl/FTLJITFinalizer.cpp:
      (JSC::FTL::JITFinalizer::finalizeFunction):
      * ftl/FTLJITFinalizer.h:
      * ftl/FTLLink.cpp:
      (JSC::FTL::link):
      * ftl/FTLLocation.cpp: Added.
      (JSC::FTL::Location::forStackmaps):
      (JSC::FTL::Location::dump):
      (JSC::FTL::Location::involvesGPR):
      (JSC::FTL::Location::isGPR):
      (JSC::FTL::Location::gpr):
      (JSC::FTL::Location::isFPR):
      (JSC::FTL::Location::fpr):
      (JSC::FTL::Location::restoreInto):
      (WTF::printInternal):
      * ftl/FTLLocation.h: Added.
      (JSC::FTL::Location::Location):
      (JSC::FTL::Location::forRegister):
      (JSC::FTL::Location::forIndirect):
      (JSC::FTL::Location::forConstant):
      (JSC::FTL::Location::kind):
      (JSC::FTL::Location::hasDwarfRegNum):
      (JSC::FTL::Location::dwarfRegNum):
      (JSC::FTL::Location::hasOffset):
      (JSC::FTL::Location::offset):
      (JSC::FTL::Location::hasConstant):
      (JSC::FTL::Location::constant):
      (JSC::FTL::Location::operator!):
      (JSC::FTL::Location::isHashTableDeletedValue):
      (JSC::FTL::Location::operator==):
      (JSC::FTL::Location::hash):
      (JSC::FTL::LocationHash::hash):
      (JSC::FTL::LocationHash::equal):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
      (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
      * ftl/FTLSaveRestore.cpp:
      (JSC::FTL::bytesForFPRs):
      (JSC::FTL::requiredScratchMemorySizeInBytes):
      (JSC::FTL::offsetOfFPR):
      (JSC::FTL::saveAllRegisters):
      (JSC::FTL::restoreAllRegisters):
      * ftl/FTLSaveRestore.h:
      * ftl/FTLStackMaps.cpp:
      (JSC::FTL::StackMaps::Location::restoreInto):
      * ftl/FTLStackMaps.h:
      * ftl/FTLState.h:
      * ftl/FTLThunks.cpp:
      (JSC::FTL::osrExitGenerationWithoutStackMapThunkGenerator):
      (JSC::FTL::osrExitGenerationWithStackMapThunkGenerator):
      * ftl/FTLThunks.h:
      (JSC::FTL::generateIfNecessary):
      (JSC::FTL::Thunks::getOSRExitGenerationThunk):
      * runtime/VM.cpp:
      (JSC::VM::VM):
      * runtime/VM.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157264 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      50cd41c0
    • fpizlo@apple.com's avatar
      FTL: Soft-link LLVM as a workaround for LLVM's static initializers and exit-time destructors · ef8dbf84
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122566
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Rowe.
              
      The JSC project now builds a libllvmForJSC.dylib. If FTL is enabled, this
      gets copied into JavaScriptCore.framework/Versions/A/Libraries. JSC will
      load the dylib by finding it using NSBundle APIs and then doing dlopen().
      That will only happen lazily, when something happens that requires LLVM.
              
      This mostly takes care of LLVM static initialization overhead by deferring
      it until it's really needed.
              
      This takes care of LLVM's exit-time destructors because inside
      libllvmForJSC.dylib, we override __cxa_atexit.
              
      * Configurations/JavaScriptCore.xcconfig:
      * Configurations/LLVMForJSC.xcconfig: Added.
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * disassembler/LLVMDisassembler.cpp:
      (JSC::tryToDisassembleWithLLVM):
      * ftl/FTLAbbreviatedTypes.h:
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::voidType):
      (JSC::FTL::int1Type):
      (JSC::FTL::int8Type):
      (JSC::FTL::int16Type):
      (JSC::FTL::int32Type):
      (JSC::FTL::int64Type):
      (JSC::FTL::intPtrType):
      (JSC::FTL::floatType):
      (JSC::FTL::doubleType):
      (JSC::FTL::pointerType):
      (JSC::FTL::structType):
      (JSC::FTL::functionType):
      (JSC::FTL::typeOf):
      (JSC::FTL::mdKindID):
      (JSC::FTL::mdString):
      (JSC::FTL::mdNode):
      (JSC::FTL::setMetadata):
      (JSC::FTL::addFunction):
      (JSC::FTL::setLinkage):
      (JSC::FTL::setFunctionCallingConv):
      (JSC::FTL::getParam):
      (JSC::FTL::constInt):
      (JSC::FTL::constReal):
      (JSC::FTL::constIntToPtr):
      (JSC::FTL::constBitCast):
      (JSC::FTL::appendBasicBlock):
      (JSC::FTL::insertBasicBlock):
      (JSC::FTL::buildPhi):
      (JSC::FTL::addIncoming):
      (JSC::FTL::buildAlloca):
      (JSC::FTL::buildAdd):
      (JSC::FTL::buildSub):
      (JSC::FTL::buildMul):
      (JSC::FTL::buildDiv):
      (JSC::FTL::buildRem):
      (JSC::FTL::buildNeg):
      (JSC::FTL::buildFAdd):
      (JSC::FTL::buildFSub):
      (JSC::FTL::buildFMul):
      (JSC::FTL::buildFDiv):
      (JSC::FTL::buildFRem):
      (JSC::FTL::buildFNeg):
      (JSC::FTL::buildAnd):
      (JSC::FTL::buildOr):
      (JSC::FTL::buildXor):
      (JSC::FTL::buildShl):
      (JSC::FTL::buildAShr):
      (JSC::FTL::buildLShr):
      (JSC::FTL::buildNot):
      (JSC::FTL::buildLoad):
      (JSC::FTL::buildStore):
      (JSC::FTL::buildSExt):
      (JSC::FTL::buildZExt):
      (JSC::FTL::buildFPToSI):
      (JSC::FTL::buildFPToUI):
      (JSC::FTL::buildSIToFP):
      (JSC::FTL::buildUIToFP):
      (JSC::FTL::buildIntCast):
      (JSC::FTL::buildFPCast):
      (JSC::FTL::buildIntToPtr):
      (JSC::FTL::buildPtrToInt):
      (JSC::FTL::buildBitCast):
      (JSC::FTL::buildICmp):
      (JSC::FTL::buildFCmp):
      (JSC::FTL::buildCall):
      (JSC::FTL::setTailCall):
      (JSC::FTL::buildExtractValue):
      (JSC::FTL::buildSelect):
      (JSC::FTL::buildBr):
      (JSC::FTL::buildCondBr):
      (JSC::FTL::buildSwitch):
      (JSC::FTL::addCase):
      (JSC::FTL::buildRet):
      (JSC::FTL::buildUnreachable):
      (JSC::FTL::dumpModule):
      (JSC::FTL::verifyModule):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::compile):
      * ftl/FTLFail.cpp:
      (JSC::FTL::fail):
      * ftl/FTLJITCode.h:
      * ftl/FTLJITFinalizer.h:
      * ftl/FTLLink.cpp:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::lower):
      * ftl/FTLOutput.cpp:
      (JSC::FTL::Output::Output):
      (JSC::FTL::Output::~Output):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::appendTo):
      * ftl/FTLState.cpp:
      (JSC::FTL::State::State):
      (JSC::FTL::State::~State):
      * ftl/WebKitLLVMLibraryAnchor.cpp: Removed.
      * jsc.cpp:
      (jscmain):
      * llvm: Added.
      * llvm/InitializeLLVM.cpp: Added.
      (JSC::initializeLLVM):
      * llvm/InitializeLLVM.h: Added.
      * llvm/InitializeLLVMMac.mm: Added.
      (JSC::initializeLLVMImpl):
      * llvm/InitializeLLVMPOSIX.cpp: Added.
      (JSC::initializeLLVMPOSIX):
      * llvm/InitializeLLVMPOSIX.h: Added.
      * llvm/LLVMAPI.cpp: Added.
      * llvm/LLVMAPI.h: Added.
      * llvm/LLVMAPIFunctions.h: Added.
      * llvm/LLVMHeaders.h: Added.
      * llvm/library: Added.
      * llvm/library/LLVMAnchor.cpp: Added.
      * llvm/library/LLVMExports.cpp: Added.
      (initializeAndGetJSCLLVMAPI):
      * llvm/library/LLVMOverrides.cpp: Added.
      (__cxa_atexit):
      * llvm/library/config_llvm.h: Added.
      * runtime/InitializeThreading.cpp:
      (JSC::initializeThreadingOnce):
      * runtime/Options.h:
      
      Source/WTF: 
      
      Reviewed by Mark Rowe.
              
      Remove all LLVM stuff from WTF since to get LLVM you need to soft-link and it's
      entirely the responsibility of JSC to do that.
              
      Also fixed an export goof that I found after fixing the weak thingy script in JSC.
      
      * WTF.xcodeproj/project.pbxproj:
      * wtf/LLVMHeaders.h: Removed.
      * wtf/text/CString.h:
      (WTF::CStringHash::hash):
      
      Tools: 
      
      Reviewed by Mark Rowe.
      
      * Scripts/configure-llvm:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157260 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ef8dbf84
    • fpizlo@apple.com's avatar
      CallbackData unnecessarily caches the JSValue for currentThis · 752fa12a
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122616
      
      Patch by Mark Hahnenberg <mhahnenberg@apple.com> on 2013-10-10
      Reviewed by Oliver Hunt.
      
      CallbackData implements its own version of caching the JSValue* for the JSValueRef it stores. 
      +[JSValue valueWithJSValueRef:inContext:] already does caching, thus obviating the need for 
      CallbackData to do its own caching.
      
      * API/JSContext.mm:
      (+[JSContext currentThis]):
      (-[JSContext beginCallbackWithData:thisValue:argumentCount:arguments:]):
      (-[JSContext endCallbackWithData:]):
      * API/JSContextInternal.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157256 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      752fa12a
    • fpizlo@apple.com's avatar
      Unreviewed, roll out r157193. It broke some builds. · b37f4bbc
      fpizlo@apple.com authored
      * JavaScriptCore.xcodeproj/project.pbxproj:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b37f4bbc
  25. 09 Oct, 2013 2 commits
    • fpizlo@apple.com's avatar
      FTL should be able to do simple OSR exits using llvm.webkit.stackmap · ea92c209
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122538
      
      Reviewed by Oliver Hunt.
              
      This gives the FTL the ability to OSR exit using the llvm.webkit.stackmap intrinsic.
              
      - The FTL compiles all OSR exit calls as calls to llvm.webkit.stackmap with a unique
        ID, passing a requested size that is big enough for own jump replacement.
              
      - After LLVM compilation, we parse the new LLVM stackmap section.
              
      - For all llvm.webkit.stackmaps that we used for OSR exits, we do a jumpReplacement,
        which targets exit thunks that we generate.
              
      - If an exit thunk fires, it causes JSC to compile an exit off-ramp that uses a
        combination of the JSC-internal OSR exit accounting (FTL::ExitValue and friends) and
        LLVM stackmap's accounting of where data actually ended up (register, indirect,
        constant) to reconstruct bytecode state.
              
      This still has shortcomings; for example it cannot handle XMM or YMM registers. Handling
      YMM registers will require adding some basic YMM support to our assemblers - really we
      just need the ability to move a YMM's value into a GPR.
              
      This patch preserves all of the old, intrinsic-less, FTL OSR exit support. Hence it
      manages to pass all existing FTL tests even despite its incompleteness. I think that's
      the right way to go since this is already a big patch, and anyway it would be great to
      keep the intrinsic-less FTL OSR exit support so long as the LLVM side of this hasn't
      landed.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/AbstractMacroAssembler.h:
      (JSC::AbstractMacroAssembler::firstRegister):
      (JSC::AbstractMacroAssembler::lastRegister):
      * assembler/MacroAssembler.h:
      (JSC::MacroAssembler::isStackRelated):
      (JSC::MacroAssembler::firstRealRegister):
      (JSC::MacroAssembler::nextRegister):
      (JSC::MacroAssembler::secondRealRegister):
      * assembler/MacroAssemblerX86Common.h:
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::firstRegister):
      (JSC::X86Assembler::lastRegister):
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * ftl/FTLCArgumentGetter.cpp:
      (JSC::FTL::CArgumentGetter::loadNextAndBox):
      * ftl/FTLCArgumentGetter.h:
      (JSC::FTL::CArgumentGetter::loadNextDoubleIntoGPR):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::mmAllocateCodeSection):
      (JSC::FTL::mmAllocateDataSection):
      (JSC::FTL::dumpDataSection):
      (JSC::FTL::fixFunctionBasedOnStackMaps):
      (JSC::FTL::compile):
      * ftl/FTLExitThunkGenerator.cpp:
      (JSC::FTL::ExitThunkGenerator::emitThunk):
      (JSC::FTL::ExitThunkGenerator::emitThunks):
      * ftl/FTLExitThunkGenerator.h:
      * ftl/FTLExitValue.h:
      (JSC::FTL::ExitValue::isInJSStackSomehow):
      (JSC::FTL::ExitValue::valueFormat):
      * ftl/FTLFail.cpp:
      (JSC::FTL::fail):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLJITCode.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::generateExitThunks):
      (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
      (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
      * ftl/FTLOSRExit.h:
      * ftl/FTLOSRExitCompilationInfo.h:
      (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
      * ftl/FTLOSRExitCompiler.cpp:
      (JSC::FTL::compileStubWithOSRExitStackmap):
      (JSC::FTL::compileStubWithoutOSRExitStackmap):
      (JSC::FTL::compileFTLOSRExit):
      * ftl/FTLSaveRestore.cpp: Added.
      (JSC::FTL::bytesForGPRs):
      (JSC::FTL::requiredScratchMemorySizeInBytes):
      (JSC::FTL::offsetOfGPR):
      (JSC::FTL::saveAllRegisters):
      (JSC::FTL::restoreAllRegisters):
      * ftl/FTLSaveRestore.h: Added.
      * ftl/FTLStackMaps.cpp: Added.
      (JSC::FTL::readObject):
      (JSC::FTL::StackMaps::Constant::parse):
      (JSC::FTL::StackMaps::Constant::dump):
      (JSC::FTL::StackMaps::Location::parse):
      (JSC::FTL::StackMaps::Location::dump):
      (JSC::FTL::StackMaps::Location::involvesGPR):
      (JSC::FTL::StackMaps::Location::isGPR):
      (JSC::FTL::StackMaps::Location::gpr):
      (JSC::FTL::StackMaps::Location::restoreInto):
      (JSC::FTL::StackMaps::Record::parse):
      (JSC::FTL::StackMaps::Record::dump):
      (JSC::FTL::StackMaps::parse):
      (JSC::FTL::StackMaps::dump):
      (JSC::FTL::StackMaps::dumpMultiline):
      (JSC::FTL::StackMaps::getRecordMap):
      (WTF::printInternal):
      * ftl/FTLStackMaps.h: Added.
      * ftl/FTLState.h:
      * ftl/FTLThunks.cpp:
      (JSC::FTL::osrExitGenerationThunkGenerator):
      * ftl/FTLValueFormat.cpp:
      (JSC::FTL::reboxAccordingToFormat):
      * ftl/FTLValueFormat.h:
      * runtime/DataView.cpp:
      (JSC::DataView::create):
      * runtime/DataView.h:
      (JSC::DataView::read):
      * runtime/Options.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157209 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ea92c209
    • fpizlo@apple.com's avatar
      Minor clean-ups in the JSC Xcode project. · 64302b5b
      fpizlo@apple.com authored
      Rubber stamped by Mark Rowe.
              
      - When we copy the jsc binary into the framework,
        $(BUILT_PRODUCTS_DIR)/JavaScriptCore.framework/Resources/jsc is the *output* file not
        the input file. The input file is $(BUILT_PRODUCTS_DIR)/jsc.
              
      - Correct capitalization of "JavaScriptcore.framework" in a comment in a shell script in
        the project.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157193 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      64302b5b
  26. 05 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      Compress DFG stack layout · a62d4829
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122024
      
      Reviewed by Oliver Hunt.
              
      The DFG needs to be able to store things at a known offset from frame pointer so that
      the runtime can read those things. Prior to this patch, the DFG would use the exact
      offsets that the bytecode asked for, even in the case of inlining, where it would use
      the callsite stack offset to shift all of the inlined function's variables over just as
      they would have been if a bytecode interpreter had really made the call.
              
      But this won't work once WebKit-LLVM integration is complete. LLVM has no notion of
      storing things at a fixed offset from the frame pointer. We could try to hack LLVM to do
      that, but it would seriously complicate LLVM's stack layout. But what we might be able
      to do is have LLVM tell us (via an addressof intrinsic and a side-channel) where some
      alloca landed relative to the frame pointer. Hence if the DFG can put all of its flushed
      variables in a contiguous range that can be expressed to LLVM as a struct that we
      alloca, then all of this can still work just fine.
              
      Previously the flushed variables didn't fit in a contiguous range, but this patch makes
      them contiguous by allowing the stack layout to be compressed.
              
      What this really means is that there is now a distinction between where the DFG saw a
      variable stored in bytecode and where it will actually store it in the resulting machine
      code. Henceforth when the DFG says "local" or "virtual register" it means the variable
      according to bytecode (with the stack offsetting for inlined code as before), but when
      it says "machine local" or "machine virtual register" it means the actual place where it
      will store things in the resulting machine code. All of the OSR exit, inlined arguments,
      captured variables, and various stack unwinding machine now knows about all of this.
              
      Note that the DFG's abstract interpretation still uses bytecode variables rather than
      machine variables. Same for CSE and abstract heaps. This makes sense since it means that
      we don't have to decide on machine variable allocation just to do those optimizations.
              
      The decision of what a local's machine location becomes is deferred to very late in
      compilation. We only need to assign machine locations to variables that must be stored
      to the stack. It's now mandatory to run some kind of "stack layout phase" that makes the
      decision and updates all data structures.
              
      So far the way that this is being used is just to compress the DFG stack layout, which
      is something that we should have done anyway, a long time ago. And the compression isn't
      even that good - the current StackLayoutPhase just identifies local indices that are
      unused in machine code and slides all other variables towards zero. This doesn't achieve
      particularly good compression but it is better than nothing. Note that this phase makes
      it seem like the bytecode-machine mapping is based on bytecode local indices; for
      example if bytecode local 4 is mapped to machine local 3 then it always will be. That's
      true for the current StackLayoutPhase but it _will not_ be true for all possible stack
      layout phases and it would be incorrect to assume that it should be true. This is why
      the current data structures have each VariableAccessData hold its own copy of the
      machine virtual register, and also have each InlineCallFrame report their own machine
      virtual registers for the various things. The DFG backend is likely to always use the
      dumb StackLayoutPhase since it is very cheap to run, but the FTL backend is likely to
      eventually get a better one, where we do some kind of constraint-based coloring: we
      institute constraints where some VariableAccessData's must have the same indices as some
      other ones, and also must be right next to some other ones; then we process all
      VariableAccessData's and attempt to assign them machine locals while preserving those
      constraints. This could lead to two VariableAccessDatas for the same bytecode local
      ending up with different machine locals.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      (JSC::CodeBlock::isCaptured):
      (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters):
      (JSC::CodeBlock::machineSlowArguments):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::hasSlowArguments):
      * bytecode/CodeOrigin.cpp:
      (JSC::CodeOrigin::dump):
      (JSC::InlineCallFrame::calleeForCallFrame):
      (JSC::InlineCallFrame::dumpInContext):
      * bytecode/CodeOrigin.h:
      (JSC::InlineCallFrame::InlineCallFrame):
      (JSC::InlineCallFrame::calleeConstant):
      * bytecode/Operands.h:
      (JSC::Operands::indexForOperand):
      * dfg/DFGBasicBlock.cpp:
      (JSC::DFG::BasicBlock::SSAData::SSAData):
      * dfg/DFGBasicBlock.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::ByteCodeParser):
      (JSC::DFG::ByteCodeParser::get):
      (JSC::DFG::ByteCodeParser::getLocal):
      (JSC::DFG::ByteCodeParser::flushDirect):
      (JSC::DFG::ByteCodeParser::flush):
      (JSC::DFG::ByteCodeParser::handleInlining):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
      (JSC::DFG::ByteCodeParser::parse):
      * dfg/DFGCommon.h:
      * dfg/DFGCommonData.h:
      (JSC::DFG::CommonData::CommonData):
      * dfg/DFGDesiredWriteBarriers.cpp:
      (JSC::DFG::DesiredWriteBarrier::trigger):
      * dfg/DFGDesiredWriteBarriers.h:
      * dfg/DFGFlushLivenessAnalysisPhase.cpp:
      (JSC::DFG::FlushLivenessAnalysisPhase::run):
      (JSC::DFG::FlushLivenessAnalysisPhase::process):
      (JSC::DFG::FlushLivenessAnalysisPhase::reportError):
      * dfg/DFGFlushedAt.cpp: Added.
      (JSC::DFG::FlushedAt::dump):
      (JSC::DFG::FlushedAt::dumpInContext):
      * dfg/DFGFlushedAt.h: Added.
      (JSC::DFG::FlushedAt::FlushedAt):
      (JSC::DFG::FlushedAt::operator!):
      (JSC::DFG::FlushedAt::format):
      (JSC::DFG::FlushedAt::virtualRegister):
      (JSC::DFG::FlushedAt::operator==):
      (JSC::DFG::FlushedAt::operator!=):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::Graph):
      (JSC::DFG::Graph::dump):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::bytecodeRegisterForArgument):
      (JSC::DFG::Graph::argumentsRegisterFor):
      (JSC::DFG::Graph::machineArgumentsRegisterFor):
      (JSC::DFG::Graph::uncheckedArgumentsRegisterFor):
      (JSC::DFG::Graph::activationRegister):
      (JSC::DFG::Graph::uncheckedActivationRegister):
      (JSC::DFG::Graph::machineActivationRegister):
      (JSC::DFG::Graph::uncheckedMachineActivationRegister):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::noticeOSREntry):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::convertToGetLocalUnlinked):
      (JSC::DFG::Node::convertToGetLocal):
      (JSC::DFG::Node::machineLocal):
      (JSC::DFG::Node::hasUnlinkedMachineLocal):
      (JSC::DFG::Node::setUnlinkedMachineLocal):
      (JSC::DFG::Node::unlinkedMachineLocal):
      (JSC::DFG::Node::hasInlineStartData):
      (JSC::DFG::Node::inlineStartData):
      * dfg/DFGNodeFlags.cpp:
      (JSC::DFG::dumpNodeFlags):
      * dfg/DFGOSREntry.cpp:
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGOSREntry.h:
      (JSC::DFG::OSREntryReshuffling::OSREntryReshuffling):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompilerCommon.cpp:
      (JSC::DFG::reifyInlinedCallFrames):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGScoreBoard.h:
      (JSC::DFG::ScoreBoard::ScoreBoard):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileInlineStart):
      (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
      (JSC::DFG::SpeculativeJIT::createOSREntries):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::calleeFrameOffset):
      (JSC::DFG::SpeculativeJIT::callFrameSlot):
      (JSC::DFG::SpeculativeJIT::argumentSlot):
      (JSC::DFG::SpeculativeJIT::callFrameTagSlot):
      (JSC::DFG::SpeculativeJIT::callFramePayloadSlot):
      (JSC::DFG::SpeculativeJIT::argumentTagSlot):
      (JSC::DFG::SpeculativeJIT::argumentPayloadSlot):
      (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters):
      (JSC::DFG::SpeculativeJIT::callOperation):
      (JSC::DFG::SpeculativeJIT::recordSetLocal):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::emitCall):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::emitCall):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGStackLayoutPhase.cpp: Added.
      (JSC::DFG::StackLayoutPhase::StackLayoutPhase):
      (JSC::DFG::StackLayoutPhase::run):
      (JSC::DFG::performStackLayout):
      * dfg/DFGStackLayoutPhase.h: Added.
      * dfg/DFGValidate.cpp:
      (JSC::DFG::Validate::validate):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::machineLocal):
      (JSC::DFG::VariableAccessData::flushedAt):
      * dfg/DFGVirtualRegisterAllocationPhase.cpp:
      (JSC::DFG::VirtualRegisterAllocationPhase::run):
      * ftl/FTLExitValue.h:
      (JSC::FTL::ExitValue::inJSStack):
      (JSC::FTL::ExitValue::inJSStackAsInt32):
      (JSC::FTL::ExitValue::inJSStackAsInt52):
      (JSC::FTL::ExitValue::inJSStackAsDouble):
      (JSC::FTL::ExitValue::virtualRegister):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileGetArgument):
      (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      * ftl/FTLOSRExitCompiler.cpp:
      (JSC::FTL::compileStub):
      * ftl/FTLValueSource.cpp:
      (JSC::FTL::ValueSource::dump):
      * ftl/FTLValueSource.h:
      (JSC::FTL::ValueSource::ValueSource):
      (JSC::FTL::ValueSource::kind):
      (JSC::FTL::ValueSource::operator!):
      (JSC::FTL::ValueSource::node):
      (JSC::FTL::ValueSource::virtualRegister):
      * interpreter/Interpreter.cpp:
      (JSC::unwindCallFrame):
      * interpreter/StackVisitor.cpp:
      (JSC::StackVisitor::readInlinedFrame):
      (JSC::StackVisitor::Frame::createArguments):
      (JSC::StackVisitor::Frame::existingArguments):
      * interpreter/StackVisitor.h:
      * jit/AssemblyHelpers.h:
      (JSC::AssemblyHelpers::addressFor):
      (JSC::AssemblyHelpers::tagFor):
      (JSC::AssemblyHelpers::payloadFor):
      (JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis):
      * runtime/Arguments.cpp:
      (JSC::Arguments::tearOff):
      * runtime/Arguments.h:
      (JSC::Arguments::allocateSlowArguments):
      (JSC::Arguments::tryDeleteArgument):
      (JSC::Arguments::isDeletedArgument):
      (JSC::Arguments::isArgument):
      (JSC::Arguments::argument):
      (JSC::Arguments::finishCreation):
      * runtime/JSActivation.h:
      (JSC::JSActivation::create):
      (JSC::JSActivation::JSActivation):
      * runtime/JSFunction.cpp:
      (JSC::RetrieveArgumentsFunctor::operator()):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156984 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a62d4829
  27. 03 Oct, 2013 1 commit
    • mrowe@apple.com's avatar
      REGRESSION (r156811): WebCore rebuilds from scratch when doing an incremental build · 00312e75
      mrowe@apple.com authored
      The change in r156811 resulted in several public headers in the JavaScriptCore framework having their modification
      date touched on every build, even if their contents had not changed. This resulted in a large portion of WebCore
      needing to rebuilt after an incremental build of JavaScriptCore.
      
      Reviewed by Dan Bernstein.
      
      * JavaScriptCore.xcodeproj/project.pbxproj: Have unifdef generate its output to a temporary file. If its exit status
      indicates that the content did not change, remove the temporary file. If the content changed, moved the temporary file
      over the destination.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156873 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      00312e75
  28. 02 Oct, 2013 1 commit
    • mitz@apple.com's avatar
      The Objective-C API should be available in 10.8 builds · 726a68b9
      mitz@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122245
      
      Reviewed by Mark Rowe.
      
      Enabled the Objective-C API when building on OS X 10.8 with the modern Objective-C runtime,
      but kept the availability attributes in API headers for 10.9 and later as they were.
      
      * API/JSBase.h: When JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 is defined, made
      JSC_OBJC_API_ENABLED true on 10.8 and above.
      * API/JSContext.h: When JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 is defined, marked the class
      as available on all OS X versions.
      * API/JSManagedValue.h: Ditto.
      * API/JSValue.h: Ditto.
      * API/JSVirtualMachine.h: Ditto.
      * Configurations/Base.xcconfig: Added JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 to
      GCC_PREPROCESSOR_DEFINITIONS.
      * JavaScriptCore.xcodeproj/project.pbxproj: Added a script build phase to unifdef the
      above header files with JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 either defined or not based on
      the OS X version we are targeting.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156811 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      726a68b9