1. 11 Jan, 2013 7 commits
  2. 08 Jan, 2013 3 commits
    • oliver@apple.com's avatar
      Support op_typeof in the DFG · e722ad0f
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=98898
      
      Reviewed by Filip Pizlo.
      
      Adds a TypeOf node to the DFG to support op_typeof.
      
      To avoid adding too much GC horror, this also makes the
      common strings portion of the SmallString cache strongly
      referenced.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::execute):
        We try to determine the result early here, and substitute in a constant.
        Otherwise we leave the node intact, and set the result type to SpecString.
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
        Parse op_typeof
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
        TypeOf nodes can be subjected to pure CSE
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canCompileOpcode):
        We can handle typeof.
      * dfg/DFGNodeType.h:
      (DFG):
        Define the node.
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
        Add operationTypeOf to support the non-trivial cases.
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
        Actual codegen
      * runtime/Operations.cpp:
      (JSC::jsTypeStringForValue):
      (JSC):
      * runtime/Operations.h:
      (JSC):
        Some refactoring to allow us to get the type string for an
        object without needing a callframe.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139145 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e722ad0f
    • fpizlo@apple.com's avatar
      REGRESSION (r138921): Crash in JSC::Arguments::create · 608ecbe4
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106329
      <rdar://problem/12974196>
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      Arguments::finishCreation() that takes an InlineCallFrame* needs to understand that the callee can
      be unset, indicating that the callee needs to be loaded from the true call frame. This adds a
      method to InlineCallFrame to do just that.
      
      * bytecode/CodeOrigin.cpp:
      (JSC::InlineCallFrame::calleeForCallFrame):
      * bytecode/CodeOrigin.h:
      (InlineCallFrame):
      * runtime/Arguments.h:
      (JSC::Arguments::finishCreation):
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * fast/js/dfg-create-inlined-arguments-in-closure-inline-expected.txt: Added.
      * fast/js/dfg-create-inlined-arguments-in-closure-inline.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-create-inlined-arguments-in-closure-inline.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139109 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      608ecbe4
    • fpizlo@apple.com's avatar
      If array allocation profiling causes a new_array to allocate double arrays,... · 0d5d62cb
      fpizlo@apple.com authored
      If array allocation profiling causes a new_array to allocate double arrays, then the holes should end up being correctly initialized
      https://bugs.webkit.org/show_bug.cgi?id=106363
      
      Reviewed by Mark Hahnenberg.
      
      Source/JavaScriptCore: 
      
      * runtime/JSArray.h:
      (JSC::JSArray::tryCreateUninitialized):
      
      LayoutTests: 
      
      * fast/js/jsc-test-list:
      * fast/js/new-array-double-with-holes-expected.txt: Added.
      * fast/js/new-array-double-with-holes.html: Added.
      * fast/js/script-tests/new-array-double-with-holes.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0d5d62cb
  3. 07 Jan, 2013 1 commit
  4. 06 Jan, 2013 2 commits
    • fpizlo@apple.com's avatar
      Simplify slow case profiling · 1b694198
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106208
      
      Reviewed by Mark Rowe.
              
      Removing the minimum execution ratio portion of slow case profiling, which allows
      the removal of a field from CodeBlock. This appears to be performance neutral,
      implying that the complexity incurred by the previous heuristic was purely
      harmful: it made the code more complicated, and it made CodeBlock larger, without
      resulting in any measurable benefits.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::likelyToTakeSlowCase):
      (JSC::CodeBlock::couldTakeSlowCase):
      (JSC::CodeBlock::likelyToTakeSpecialFastCase):
      (JSC::CodeBlock::couldTakeSpecialFastCase):
      (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
      (JSC::CodeBlock::likelyToTakeAnySlowCase):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile):
      * runtime/Options.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138924 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1b694198
    • fpizlo@apple.com's avatar
      DFG should inline closure calls · 5e2296a2
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106067
      
      Reviewed by Gavin Barraclough.
              
      This adds initial support for inlining closure calls to the DFG. A call is considered
      to be a closure call when the JSFunction* varies, but always has the same executable.
      We already have closure call inline caching in both JITs, which works by checking that
      the callee has an expected structure (as a cheap way of detecting that it is in fact
      a JSFunction) and an expected executable. Closure call inlining uses profiling data
      aggregated by CallLinkStatus to decide when to specialize the call to the particular
      structure/executable, and inline the call rather than emitting a call sequence. When
      we choose to do a closure inline rather than an ordinary inline, a number of things
      change about how inlining is performed:
              
      - The inline is guarded by a CheckStructure/CheckExecutable rather than a
        CheckFunction.
              
      - Instead of propagating a constant value for the scope, we emit GetMyScope every time
        that the scope is needed, which loads the scope from a local variable. We do similar
        things for the callee.
              
      - The prologue of the inlined code includes SetMyScope and SetCallee nodes to eagerly
        plant the scope and callee into the "true call frame", i.e. the place on the stack
        where the call frame would have been if the call had been actually performed. This
        allows GetMyScope/GetCallee to work as they would if the code wasn't inlined. It
        also allows for trivial handling of scope and callee for call frame reconstruction
        upon stack introspection and during OSR.
              
      - A new node called GetScope is introduced, which just gets the scope of a function.
        This node has the expected CSE support. This allows for the
        SetMyScope(GetScope(@function)) sequence to set up the scope in the true call frame.
              
      - GetMyScope/GetCallee CSE can match against SetMyScope/SetCallee, which means that
        the GetMyScope/GetCallee nodes emitted during parsing are often removed during CSE,
        if we can prove that it is safe to do so.
              
      - Inlining heuristics are adjusted to grok the cost of inlining a closure. We are
        less likely to inline a closure call than we are to inline a normal call, since we
        end up emitting more code for closures due to CheckStructure, CheckExecutable,
        GetScope, SetMyScope, and SetCallee.
              
      Additionally, I've fixed the VariableEventStream to ensure that we don't attempt to
      plant Undefined into the true call frames. This was previously a harmless oversight,
      but it becomes quite bad if OSR is relying on the scope/callee already having been
      set and not subsequently clobbered by the OSR itself.
              
      This is a ~60% speed-up on programs that frequently make calls to closures. It's
      neutral on V8v7 and other major benchmark suites.
              
      The lack of a definite speed-up is likely due the fact that closure inlining currently
      does not do any cardinality [1] optimizations. We don't observe when a closure was
      constructed within its caller, and so used the scope from its caller; and furthermore
      we have no facility to detect when the scope is single. All scoped variable accesses
      are assumed to be multiple instead. A subsequent step will be to ensure that closure
      call inlining will be single and loving it.
              
      [1] Single and loving it: Must-alias analysis for higher-order languages. Suresh
          Jagannathan, Peter Thiemann, Stephen Weeks, and Andrew Wright. In POPL '98.
      
      * bytecode/CallLinkStatus.cpp:
      (JSC::CallLinkStatus::dump):
      * bytecode/CallLinkStatus.h:
      (JSC::CallLinkStatus::isClosureCall):
      (CallLinkStatus):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::globalObjectFor):
      (JSC):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      * bytecode/CodeOrigin.cpp:
      (JSC::InlineCallFrame::dump):
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::execute):
      * dfg/DFGByteCodeParser.cpp:
      (ByteCodeParser):
      (JSC::DFG::ByteCodeParser::handleCall):
      (JSC::DFG::ByteCodeParser::emitFunctionChecks):
      (JSC::DFG::ByteCodeParser::handleInlining):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::pureCSE):
      (CSEPhase):
      (JSC::DFG::CSEPhase::getCalleeLoadElimination):
      (JSC::DFG::CSEPhase::checkExecutableElimination):
      (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::mightInlineFunctionForClosureCall):
      * dfg/DFGCapabilities.h:
      (DFG):
      (JSC::DFG::mightInlineFunctionForClosureCall):
      (JSC::DFG::canInlineFunctionForClosureCall):
      (JSC::DFG::canInlineFunctionFor):
      * dfg/DFGNode.h:
      (Node):
      (JSC::DFG::Node::hasExecutable):
      (JSC::DFG::Node::executable):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGVariableEventStream.cpp:
      (JSC::DFG::VariableEventStream::reconstruct):
      * runtime/Options.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138921 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5e2296a2
  5. 03 Jan, 2013 3 commits
  6. 02 Jan, 2013 1 commit
    • ggaren@apple.com's avatar
      Some renaming in the CodeCache · 446dffa4
      ggaren@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105966
      
      Reviewed by Gavin Barraclough.
      
      CodeBlockKey => SourceCodeKey because the key is not a CodeBlock.
      
      m_recentlyUsedFunctionCode => m_recentlyUsedFunctions to match other names.
      
      GlobalFunctionKey => FunctionKey because the key is not unique to globalness.
      
      m_cachedGlobalFunctions => m_globalFunctions because "cached" is redundant
      for data members in an object called "CodeCache".
      
      kMaxRootCodeBlockEntries => kMaxRootEntries because there are no non-CodeBlock
      entries in a CodeBlock cache.
      
      kMaxFunctionCodeBlocks => kMaxChildFunctionEntries to clarify that this
      number models a parent-child relationship.
      
      Also removed the initial "k" from enum constants. That's an interesting
      style for calling out constants, but it's not the WebKit style.
      
      Finally, a behavior change: Use MaxRootEntries for the limit on global
      functions, and not MaxChildFunctionEntries. Previously, there was an
      unused constant that seemed to have been intended for this purpose.
      
      * runtime/CodeCache.cpp:
      (JSC::CodeCache::makeSourceCodeKey):
      (JSC::CodeCache::getCodeBlock):
      (JSC::CodeCache::generateFunctionCodeBlock):
      (JSC::CodeCache::makeFunctionKey):
      (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
      (JSC::CodeCache::usedFunctionCode):
      * runtime/CodeCache.h:
      (JSC::CodeCache::clear):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138675 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      446dffa4
  7. 01 Jan, 2013 1 commit
    • barraclough@apple.com's avatar
      Objective-C API for JavaScriptCore · fc381887
      barraclough@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105889
      
      Reviewed by Filip Pizlo.
      
      ../JavaScriptCore: 
      
      For a detailed description of the API implemented here, see:
          JSContext.h
          APIJSValue.h
          JSVirtualMachine.h
          JSExport.h
      Still to do -
          (1) Shoud rename APIJSValue.h -> JSValue.h (but we'll have to rename JSValue.h first).
          (2) Numerous FIXMEs, all with separate bugs filed.
      
      * API/APIJSValue.h: Added.
          - this Objective-C class is used to reference a JavaScript object.
      * API/JSBase.h:
          - added JS_OBJC_API_ENABLED macro to control ObjC API support.
      * API/JSBlockAdaptor.h: Added.
          - this Objective-C class is used in creating a special NSBlock proxying a JavaScript function.
      * API/JSBlockAdaptor.mm: Added.
      (BlockArgument):
      (BlockArgument::~BlockArgument):
      (BlockArgumentBoolean):
      (BlockArgumentBoolean::get):
      (BlockArgumentNumeric):
      (BlockArgumentNumeric::get):
      (BlockArgumentId):
      (BlockArgumentId::get):
      (BlockArgumentStruct):
      (BlockArgumentStruct::BlockArgumentStruct):
      (BlockArgumentStruct::~BlockArgumentStruct):
      (BlockArgumentStruct::get):
          - decoded arguent type information of a JSBlockAdaptor.
      (BlockArgumentTypeDelegate):
      (BlockArgumentTypeDelegate::typeInteger):
      (BlockArgumentTypeDelegate::typeDouble):
      (BlockArgumentTypeDelegate::typeBool):
      (BlockArgumentTypeDelegate::typeVoid):
      (BlockArgumentTypeDelegate::typeId):
      (BlockArgumentTypeDelegate::typeOfClass):
      (BlockArgumentTypeDelegate::typeBlock):
      (BlockArgumentTypeDelegate::typeStruct):
          - delegate for use in conjunction with parseObjCType.
      (BlockResult):
      (BlockResult::~BlockResult):
      (BlockResultVoid):
      (BlockResultVoid::set):
      (BlockResultInteger):
      (BlockResultInteger::set):
      (BlockResultDouble):
      (BlockResultDouble::set):
      (BlockResultBoolean):
      (BlockResultBoolean::set):
      (BlockResultStruct):
      (BlockResultStruct::BlockResultStruct):
      (BlockResultStruct::~BlockResultStruct):
      (BlockResultStruct::set):
          - decoded result type information of a JSBlockAdaptor.
      (buildBlockSignature):
          - partial step in constructing a signature with stack offset information from one without.
      (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]):
          - constructor.
      (-[JSBlockAdaptor blockMatchesSignature:]):
          - check whether signature strings match, where only one contains stack frame offsets.
      (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
          - use the adaptor to create a special forwarding block.
      * API/JSCallbackObjectFunctions.h:
      (JSC::::inherits):
          - add missing braces to multiline for statement.
      * API/JSContext.h: Added.
          - this Objective-C class is used to reference a JavaScript context.
      * API/JSContext.mm: Added.
      (-[JSContext init]):
          - constructor.
      (-[JSContext initWithVirtualMachine:]):
          - construct in a given VM (JSGlobalData).
      (-[JSContext evaluateScript:]):
      (-[JSContext globalObject]):
          - evaluate a script, global object accessor.
      (+[JSContext currentContext]):
      (+[JSContext currentThis]):
      (+[JSContext currentArguments]):
          - These methods obtain context, this, arguments from within a callback.
      (-[JSContext virtualMachine]):
          - implementation for .virtualMachine property.
      (-[JSContext objectForKeyedSubscript:]):
      (-[JSContext setObject:forKeyedSubscript:]):
          - support for subscript property access.
      (contextInternalContext):
          - internal accessor to m_context.
      (-[JSContext dealloc]):
          - desctructor.
      (-[JSContext notifyException:]):
      (-[JSContext valueFromNotifyException:]):
      (-[JSContext boolFromNotifyException:]):
          - internal method to record an exception was thrown.
      (-[JSContext beginCallbackWithData:thisValue:argumentCount:arguments:]):
      (-[JSContext endCallbackWithData:]):
          - internal methods to push/pop a callback record.
      (-[JSContext protect:]):
      (-[JSContext unprotect:]):
          - internal methods to add a value to a protect set (used to protect the internal property of JSValue).
      (-[JSContext wrapperForObject:]):
          - internal method to create a wrapper object.
      (WeakContextRef::WeakContextRef):
      (WeakContextRef::~WeakContextRef):
      (WeakContextRef::get):
      (WeakContextRef::set):
          - Helper class to implement a weak reference to a JSContext.
      * API/JSContextInternal.h: Added.
      (CallbackData):
      (WeakContextRef):
          - see API/JSContext.mm for description of internal methods.
      * API/JSExport.h: Added.
          - Provides JSExport protocol & JSExportAs macro.
      * API/JSValue.mm: Added.
      (+[JSValue valueWithObject:inContext:]):
      (+[JSValue valueWithBool:inContext:]):
      (+[JSValue valueWithDouble:inContext:]):
      (+[JSValue valueWithInt32:inContext:]):
      (+[JSValue valueWithUInt32:inContext:]):
      (+[JSValue valueWithNewObjectInContext:]):
      (+[JSValue valueWithNewArrayInContext:]):
      (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]):
      (+[JSValue valueWithNewErrorFromMessage:inContext:]):
      (+[JSValue valueWithNullInContext:]):
      (+[JSValue valueWithUndefinedInContext:]):
          - Constructors.
      (-[JSValue toObject]):
      (-[JSValue toObjectOfClass:]):
      (-[JSValue toBool]):
      (-[JSValue toDouble]):
      (-[JSValue toInt32]):
      (-[JSValue toUInt32]):
      (-[JSValue toNumber]):
      (-[JSValue toString]):
      (-[JSValue toDate]):
      (-[JSValue toArray]):
      (-[JSValue toDictionary]):
          - Conversion to Objective-C types.
      (-[JSValue valueForProperty:]):
      (-[JSValue setValue:forProperty:]):
      (-[JSValue deleteProperty:]):
      (-[JSValue hasProperty:]):
      (-[JSValue defineProperty:descriptor:]):
          - Property access by property name.
      (-[JSValue valueAtIndex:]):
      (-[JSValue setValue:atIndex:]):
          - Property access by index.
      (-[JSValue isUndefined]):
      (-[JSValue isNull]):
      (-[JSValue isBoolean]):
      (-[JSValue isNumber]):
      (-[JSValue isString]):
      (-[JSValue isObject]):
          - Test JavaScript type.
      (-[JSValue isEqualToObject:]):
      (-[JSValue isEqualWithTypeCoercionToObject:]):
      (-[JSValue isInstanceOf:]):
          - ===, ==, instanceof operators.
      (-[JSValue callWithArguments:]):
      (-[JSValue constructWithArguments:]):
      (-[JSValue invokeMethod:withArguments:]):
          - Call & construct.
      (-[JSValue context]):
          - implementation for .context property.
      (-[JSValue toPoint]):
      (-[JSValue toRange]):
      (-[JSValue toRect]):
      (-[JSValue toSize]):
      (+[JSValue valueWithPoint:inContext:]):
      (+[JSValue valueWithRange:inContext:]):
      (+[JSValue valueWithRect:inContext:]):
      (+[JSValue valueWithSize:inContext:]):
          - Support for NS struct types.
      (-[JSValue objectForKeyedSubscript:]):
      (-[JSValue objectAtIndexedSubscript:]):
      (-[JSValue setObject:forKeyedSubscript:]):
      (-[JSValue setObject:atIndexedSubscript:]):
          - support for subscript property access.
      (isDate):
      (isArray):
          - internal helper functions to check for instances of JS Date, Array types.
      (JSContainerConvertor):
      (Task):
      (JSContainerConvertor::JSContainerConvertor):
      (JSContainerConvertor::isWorkListEmpty):
      (JSContainerConvertor::convert):
      (JSContainerConvertor::add):
      (JSContainerConvertor::take):
          - helper class for tracking state while converting to Array/Dictionary objects.
      (valueToObjectWithoutCopy):
      (containerValueToObject):
      (valueToObject):
      (valueToNumber):
      (valueToString):
      (valueToDate):
      (valueToArray):
      (valueToDictionary):
          - function for converting JavaScript values to Objective-C objects.
      (ObjcContainerConvertor):
      (ObjcContainerConvertor::ObjcContainerConvertor):
      (ObjcContainerConvertor::isWorkListEmpty):
      (ObjcContainerConvertor::convert):
      (ObjcContainerConvertor::add):
      (ObjcContainerConvertor::take):
          - helper class for tracking state while converting to Array/Dictionary values.
      (objectToValueWithoutCopy):
      (objectToValue):
      (valueInternalValue):
          - function for converting Objective-C objects to JavaScript values.
      (+[JSValue valueWithValue:inContext:]):
      (-[JSValue initWithValue:inContext:]):
          - internal constructors.
      (StructTagHandler):
      (getStructTagHandler):
      (+[JSValue selectorForStructToValue:]):
      (+[JSValue selectorForValueToStruct:]):
          - methods to tracking struct types that support conversion to/from JSValue.
      (-[JSValue dealloc]):
          - destructor.
      (-[JSValue description]):
          - Objective-C to-NSString conversion.
      (typeToValueInvocationFor):
      (valueToTypeInvocationFor):
          - create invocation objects for conversion to/from JSValue.
      * API/JSValueInternal.h: Added.
          - see API/JSValue.mm for description of internal methods.
      * API/JSVirtualMachine.h: Added.
          - this Objective-C class is used to reference a JavaScript virtual machine (JSGlobalData).
      * API/JSVirtualMachine.mm: Added.
      (-[JSVirtualMachine init]):
      (-[JSVirtualMachine dealloc]):
          - constructor & destructor.
      (getGroupFromVirtualMachine):
          - internal accessor for m_group property.
      * API/JSVirtualMachineInternal.h: Added.
          - see API/JSVirtualMachine.mm for description of internal methods.
      * API/JSWrapperMap.h: Added.
      * API/JSWrapperMap.mm: Added.
      (wrapperClass):
          - singleton root for detction (& unwrapping) of wrapper objects.
      (selectorToPropertyName):
          - default selector to property name conversion.
      (createObjectWithCustomBrand):
          - creates a JSObject with a custom NativeBrand (class name).
      (createRenameMap):
          - parse @optional properties of a JSExport protocol.
      (putNonEnumerable):
          - property put with enumerable=false.
      (copyMethodsToObject):
          - iterate methods in a protocol; add functions to a JSObject.
      (parsePropertyAttributes):
          - examine protocol property metadata.
      (makeSetterName):
          - "foo" -> "setFoo"
      (copyPrototypeProperties):
          - create properties on a Protocol object reflecting the instance methods & properties of a protocol.
      (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
      (-[JSObjCClassInfo dealloc]):
      (-[JSObjCClassInfo wrapperForObject:]):
      (-[JSObjCClassInfo constructor]):
          - cache the Protocol/Constructor objects for an Objective-C type.
      (-[JSWrapperMap initWithContext:]):
      (-[JSWrapperMap dealloc]):
          - constructor & desctructor.
      (-[JSWrapperMap classInfoForClass:]):
          - maps Class -> JSObjCClassInfo.
      (-[JSWrapperMap wrapperForObject:]):
          - cretae or retrieve a cached wrapper value for an object.
      (tryUnwrapObjcObject):
          - check whether a value is a wrapper object; unwrap if so.
      * API/JavaScriptCore.h:
          - Added includes for new API headers.
      * API/ObjCCallbackFunction.h: Added.
          - this class is used to wrap Objective-C instance methods, class methods & blocks as JSFunction objects.
      * API/ObjCCallbackFunction.mm: Added.
      (CallbackArgument):
      (CallbackArgument::~CallbackArgument):
      (CallbackArgumentBoolean):
      (CallbackArgumentBoolean::set):
      (CallbackArgumentInteger):
      (CallbackArgumentInteger::set):
      (CallbackArgumentDouble):
      (CallbackArgumentDouble::set):
      (CallbackArgumentJSValue):
      (CallbackArgumentJSValue::set):
      (CallbackArgumentId):
      (CallbackArgumentId::set):
      (CallbackArgumentOfClass):
      (CallbackArgumentOfClass::CallbackArgumentOfClass):
      (CallbackArgumentOfClass::~CallbackArgumentOfClass):
      (CallbackArgumentOfClass::set):
      (CallbackArgumentNSNumber):
      (CallbackArgumentNSNumber::set):
      (CallbackArgumentNSString):
      (CallbackArgumentNSString::set):
      (CallbackArgumentNSDate):
      (CallbackArgumentNSDate::set):
      (CallbackArgumentNSArray):
      (CallbackArgumentNSArray::set):
      (CallbackArgumentNSDictionary):
      (CallbackArgumentNSDictionary::set):
      (CallbackArgumentStruct):
      (CallbackArgumentStruct::CallbackArgumentStruct):
      (CallbackArgumentStruct::~CallbackArgumentStruct):
      (CallbackArgumentStruct::set):
      (CallbackArgumentBlockCallback):
      (CallbackArgumentBlockCallback::CallbackArgumentBlockCallback):
      (CallbackArgumentBlockCallback::~CallbackArgumentBlockCallback):
      (CallbackArgumentBlockCallback::set):
          - decoded arguent type information of a ObjCCallbackFunction.
      (ArgumentTypeDelegate):
      (ArgumentTypeDelegate::typeInteger):
      (ArgumentTypeDelegate::typeDouble):
      (ArgumentTypeDelegate::typeBool):
      (ArgumentTypeDelegate::typeVoid):
      (ArgumentTypeDelegate::typeId):
      (ArgumentTypeDelegate::typeOfClass):
      (ArgumentTypeDelegate::typeBlock):
      (ArgumentTypeDelegate::typeStruct):
          - delegate for use in conjunction with parseObjCType.
      (CallbackResult):
      (CallbackResult::~CallbackResult):
      (CallbackResultVoid):
      (CallbackResultVoid::get):
      (CallbackResultId):
      (CallbackResultId::get):
      (CallbackResultNumeric):
      (CallbackResultNumeric::get):
      (CallbackResultBoolean):
      (CallbackResultBoolean::get):
      (CallbackResultStruct):
      (CallbackResultStruct::CallbackResultStruct):
      (CallbackResultStruct::~CallbackResultStruct):
      (CallbackResultStruct::get):
          - decoded result type information of a ObjCCallbackFunction.
      (ResultTypeDelegate):
      (ResultTypeDelegate::typeInteger):
      (ResultTypeDelegate::typeDouble):
      (ResultTypeDelegate::typeBool):
      (ResultTypeDelegate::typeVoid):
      (ResultTypeDelegate::typeId):
      (ResultTypeDelegate::typeOfClass):
      (ResultTypeDelegate::typeBlock):
      (ResultTypeDelegate::typeStruct):
          - delegate for use in conjunction with parseObjCType.
      (ObjCCallbackFunction):
      (ObjCCallbackFunction::ObjCCallbackFunction):
      (ObjCCallbackFunction::~ObjCCallbackFunction):
          - constructor & destructor.
      (ObjCCallbackFunction::context):
          - accessor.
      (ObjCCallbackFunction::wrappedBlock):
          - attemmpt to unwrap a block object.
      (objCCallbackFunctionFinalize):
      (objCCallbackFunctionCallAsFunction):
      (objCCallbackFunctionClass):
          - JSClassRef used to represent ObjCCallbackFunction objects.
      (ObjCCallbackFunction::call):
      (blockSignatureContainsClass):
          - helper function to determine if we're running on a recent Clang.
      (skipNumber):
          - helper used in parsing signature strings.
      (objCCallbackFunctionForInvocation):
      (objCCallbackFunctionForMethod):
      (objCCallbackFunctionForBlock):
          - functions to try to create ObjCCallbackFunction instances for methods/blocks.
      (tryUnwrapBlock):
          - attemmpt to unwrap a block object.
      * API/ObjcRuntimeExtras.h: Added.
      (protocolImplementsProtocol):
      (forEachProtocolImplementingProtocol):
      (forEachMethodInClass):
      (forEachMethodInProtocol):
      (forEachPropertyInProtocol):
          - functions used in reflecting on Objective-C types.
      (skipPair):
          - parsing helper used by parseObjCType, scans for matching parentheses.
      (StringRange):
      (StringRange::StringRange):
      (StringRange::~StringRange):
      (StringRange::operator const char*):
      (StringRange::get):
          - Helper class - create a c string copy of a range of an existing string.
      (parseObjCType):
          - function to parse Objective-C type strings, makes callbacks to a deleagte.
      * API/tests/testapi.c:
      (main):
          - added call to testObjectiveCAPI (in testapi.m).
      * API/tests/testapi.m: Added.
      (+[ParentObject parentTest]):
      (+[TestObject testObject]):
      (+[TestObject classTest]):
      (-[TestObject getString]):
      (-[TestObject testArgumentTypesWithInt:double:boolean:string:number:array:dictionary:]):
      (-[TestObject callback:]):
      (-[TextXYZ test:]):
          - test object, used in various test vases.
      (checkResult):
          - helper function.
      (blockSignatureContainsClass):
          - helper function to determine if we're running on a recent Clang.
      (testObjectiveCAPI):
          - new test cases.
      * JavaScriptCore.xcodeproj/project.pbxproj:
          - added new files.
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::JSGlobalData):
      * runtime/JSGlobalData.h:
      (JSGlobalData):
          - added m_apiData - provide convenient storage for use by the API.
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::JSGlobalObject):
      * runtime/JSGlobalObject.h:
      (JSGlobalObject):
          - added m_apiData - provide convenient storage for use by the API.
      
      ../WTF: 
      
      * wtf/WTFThreadData.cpp:
      (WTF::WTFThreadData::WTFThreadData):
      * wtf/WTFThreadData.h:
      (WTFThreadData):
          - Added m_apiData - provide convenient storage for use by the API.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138604 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fc381887
  8. 27 Dec, 2012 1 commit
    • fpizlo@apple.com's avatar
      All JIT stubs should go through the getCTIStub API · 2ac511cb
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105750
      
      Reviewed by Sam Weinig.
              
      Previously JITThunks had two sets of thunks: one static set stored in a struct,
      which was filled by JIT::privateCompileCTITrampolines, and another set stored in
      a HashMap. Moreover, the code to generate the code for the CTI trampoline struct
      had loads of copy-paste between JSVALUE32_64 and JSVALUE64, and was total
      unmodular with respect to calls versus constructors, among other things.
                        
      This changeset removes this struct and rationalizes the code that generates those
      thunks. All of thunks are now generated through the getCTIStub HashMap API. All
      thunks for the baseline JIT now use the JSInterfaceJIT and have their codegen
      located in ThunkGenerators.cpp. All thunks now share as much code as possible -
      it turns out that they are almost 100% identical between 32_64 and 64, so that
      works out great. A bunch of call vs. construct duplication was eliminated. And,
      most of the call link versus virtual call duplication was also eliminated.
              
      This does not change behavior but it does make it easier to add more thunks in
      the future.
      
      * bytecode/CallLinkInfo.cpp:
      (JSC::CallLinkInfo::unlink):
      * jit/JIT.cpp:
      (JSC::JIT::linkFor):
      * jit/JIT.h:
      (JIT):
      * jit/JITCall.cpp:
      (JSC::JIT::compileCallEvalSlowCase):
      (JSC::JIT::compileOpCallSlowCase):
      * jit/JITCall32_64.cpp:
      (JSC::JIT::compileCallEvalSlowCase):
      (JSC::JIT::compileOpCallSlowCase):
      * jit/JITInlines.h:
      (JSC):
      * jit/JITOpcodes.cpp:
      (JSC):
      (JSC::JIT::privateCompileCTINativeCall):
      * jit/JITOpcodes32_64.cpp:
      (JSC):
      * jit/JITStubs.cpp:
      (JSC::tryCacheGetByID):
      * jit/JITThunks.cpp:
      (JSC::JITThunks::JITThunks):
      (JSC::JITThunks::ctiNativeCall):
      (JSC::JITThunks::ctiNativeConstruct):
      (JSC):
      (JSC::JITThunks::hostFunctionStub):
      * jit/JITThunks.h:
      (JSC):
      (JITThunks):
      * jit/JSInterfaceJIT.h:
      (JSInterfaceJIT):
      (JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
      (JSC):
      (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck):
      (JSC::JSInterfaceJIT::emitJumpIfNotType):
      (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr):
      (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
      (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader):
      (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader):
      (JSC::JSInterfaceJIT::preserveReturnAddressAfterCall):
      (JSC::JSInterfaceJIT::restoreReturnAddressBeforeReturn):
      (JSC::JSInterfaceJIT::restoreArgumentReference):
      * jit/ThunkGenerators.cpp:
      (JSC::generateSlowCaseFor):
      (JSC):
      (JSC::linkForGenerator):
      (JSC::linkCallGenerator):
      (JSC::linkConstructGenerator):
      (JSC::virtualForGenerator):
      (JSC::virtualCallGenerator):
      (JSC::virtualConstructGenerator):
      (JSC::stringLengthTrampolineGenerator):
      (JSC::nativeForGenerator):
      (JSC::nativeCallGenerator):
      (JSC::nativeConstructGenerator):
      (JSC::charCodeAtThunkGenerator):
      (JSC::charAtThunkGenerator):
      (JSC::fromCharCodeThunkGenerator):
      (JSC::sqrtThunkGenerator):
      (JSC::floorThunkGenerator):
      (JSC::ceilThunkGenerator):
      (JSC::roundThunkGenerator):
      (JSC::expThunkGenerator):
      (JSC::logThunkGenerator):
      (JSC::absThunkGenerator):
      (JSC::powThunkGenerator):
      * jit/ThunkGenerators.h:
      (JSC):
      * runtime/Executable.h:
      (NativeExecutable):
      (JSC::NativeExecutable::nativeFunctionFor):
      (JSC::NativeExecutable::offsetOfNativeFunctionFor):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138516 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2ac511cb
  9. 25 Dec, 2012 1 commit
    • fpizlo@apple.com's avatar
      JITThunks should be in its own file · c8eca23c
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105744
      
      Rubber stamped by Sam Weinig.
              
      Moved JITThunks into its own file and removed some static methods from it
      that were not related to what JITThunks currently does. Performed various
      pagan rituals to get it to build - apparently there is a circular dependency
      between JSCell, Weak, and JITThunks, which magically resolves itself if you
      make sure to first include Register.h. Making it so that fewer pagan rituals
      need to be performed if this code changes in the future is covered by
      https://bugs.webkit.org/show_bug.cgi?id=105696.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * jit/JITStubs.cpp:
      (JSC::tryCachePutByID):
      (JSC::tryCacheGetByID):
      * jit/JITStubs.h:
      (JSC::JITStackFrame::returnAddressSlot):
      (JSC::returnAddressIsInCtiTrampoline):
      * jit/JITThunks.cpp: Added.
      (JSC::JITThunks::JITThunks):
      (JSC::JITThunks::~JITThunks):
      (JSC::JITThunks::ctiStub):
      (JSC::JITThunks::hostFunctionStub):
      (JSC::JITThunks::clearHostFunctionStubs):
      * jit/JITThunks.h: Added.
      (JSC::JITThunks::ctiStringLengthTrampoline):
      (JSC::JITThunks::ctiVirtualCallLink):
      (JSC::JITThunks::ctiVirtualConstructLink):
      (JSC::JITThunks::ctiVirtualCall):
      (JSC::JITThunks::ctiVirtualConstruct):
      (JSC::JITThunks::ctiNativeCall):
      (JSC::JITThunks::ctiNativeConstruct):
      * jit/ThunkGenerator.h: Added.
      * jit/ThunkGenerators.cpp:
      * jit/ThunkGenerators.h:
      * runtime/JSGlobalData.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138465 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c8eca23c
  10. 19 Dec, 2012 1 commit
    • fpizlo@apple.com's avatar
      JSObject::ensure<IndexingType> should gracefully handle InterceptsGetOwn...,... · 274b6f17
      fpizlo@apple.com authored
      JSObject::ensure<IndexingType> should gracefully handle InterceptsGetOwn..., and should never be called when the 'this' is not an object
      https://bugs.webkit.org/show_bug.cgi?id=105468
      
      Reviewed by Mark Hahnenberg, Oliver Hunt, and Gavin Barraclough.
      
      Source/JavaScriptCore: 
      
      Changed JSObject::ensure<IndexingType> methods to gracefully handle
      InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero. Most of them handle it by returning
      null as a result of indexingShouldBeSparse() returning true, while ensureArrayStorage handles it
      by entering dictionary indexing mode, which forces the object to behave correctly even if there
      is proxying or weird prototype stuff going on.
              
      Changed DFGOperations entrypoints to reject non-objects, so that JSObject doesn't have to deal
      with pretending to be JSString. In particular, this would go wrong in the ArrayStorage case
      since we'd try to resize a butterfly on a JSString, but JSString has something other than
      m_butterfly at that offset.
              
      Finally, removed all InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero from JIT code
      since those are now redundant.
      
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::arrayify):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * runtime/JSObject.cpp:
      (JSC::JSObject::enterDictionaryIndexingMode):
      (JSC::JSObject::ensureInt32Slow):
      (JSC::JSObject::ensureDoubleSlow):
      (JSC::JSObject::ensureContiguousSlow):
      (JSC::JSObject::ensureArrayStorageSlow):
      (JSC):
      (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
      * runtime/JSObject.h:
      (JSObject):
      
      LayoutTests: 
      
      * fast/js/dfg-ensure-array-storage-on-string-expected.txt: Added.
      * fast/js/dfg-ensure-array-storage-on-string.html: Added.
      * fast/js/dfg-ensure-contiguous-on-string-expected.txt: Added.
      * fast/js/dfg-ensure-contiguous-on-string.html: Added.
      * fast/js/jsc-test-list
      * fast/js/script-tests/dfg-ensure-array-storage-on-string.js: Added.
      (foo):
      * fast/js/script-tests/dfg-ensure-contiguous-on-string.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138201 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      274b6f17
  11. 18 Dec, 2012 4 commits
    • fpizlo@apple.com's avatar
      Proxies should set InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero · d5e0b705
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105379
      
      Reviewed by Gavin Barraclough.
      
      Source/JavaScriptCore: 
      
      Forgetting to set this flag led to the DFG trying to ensure array storage on a proxy. I've
      now hardened the code with a release assertion as well as fixing the bug. A release assertion
      is appropriate here since this is slow-path code.
      
      * runtime/JSObject.cpp:
      (JSC::JSObject::enterDictionaryIndexingMode):
      (JSC::JSObject::ensureInt32Slow):
      (JSC::JSObject::ensureDoubleSlow):
      (JSC::JSObject::ensureContiguousSlow):
      (JSC::JSObject::ensureArrayStorageSlowNoCheck):
      (JSC::JSObject::ensureArrayStorageSlow):
      (JSC):
      (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
      * runtime/JSObject.h:
      (JSObject):
      * runtime/JSProxy.h:
      (JSProxy):
      
      LayoutTests: 
      
      * fast/js/dfg-ensure-non-array-array-storage-on-window-expected.txt: Added.
      * fast/js/dfg-ensure-non-array-array-storage-on-window.html: Added.
      * fast/js/script-tests/dfg-ensure-non-array-array-storage-on-window.js: Added.
      (foo):
      (bar):
      (.shouldBe):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138107 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d5e0b705
    • fpizlo@apple.com's avatar
      SunSpider/date-format-tofte shouldn't compile each of the tiny worthless... · d29f9635
      fpizlo@apple.com authored
      SunSpider/date-format-tofte shouldn't compile each of the tiny worthless eval's only to OSR exit in the prologue every time
      https://bugs.webkit.org/show_bug.cgi?id=105335
      
      Reviewed by Geoffrey Garen.
      
      The first thing I did was restructure the logic of canInlineResolveOperations(),
      because I didn't understand it. This was relevant because the OSR exits are
      caused by a resolve that the DFG cannot handle.
              
      I was then going to make it so that we didn't compile the resolve at all, but
      realized that this would not be the best fix: it didn't seem sensible to me to
      be optimizing these evals after only 60 invocations. Evals should have a higher
      threshold, since they often contain code for which the baseline JIT does a
      pretty good job already (if all you've got is a single heap access or a single
      hard-to-inline call, then the baseline JIT has got you covered), and typically
      if we see one eval code block we expect to see more (from the same eval site):
      so our typical low threshold could lead to a *lot* of compilation. As such, the
      main effect of this patch is to introduce an evalThresholdMultiplier, which is
      now set to 10.
              
      This is a ~5% speed-up on data-format-tofte. No regressions anywhere as far as
      I can see.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::codeTypeThresholdMultiplier):
      (JSC):
      (JSC::CodeBlock::optimizationThresholdScalingFactor):
      (JSC::CodeBlock::exitCountThresholdForReoptimization):
      (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canInlineResolveOperations):
      * dfg/DFGOSRExitCompiler.cpp:
      * runtime/Options.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138074 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d29f9635
    • fpizlo@apple.com's avatar
      Convert indexingTypeToString to IndexingTypeDump · 0520bd41
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105351
      
      Reviewed by Mark Hahnenberg.
      
      This gets rid of another case of static char buffer[thingy].
      
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      * runtime/IndexingType.cpp:
      (JSC::dumpIndexingType):
      * runtime/IndexingType.h:
      (JSC):
      * runtime/JSValue.cpp:
      (JSC::JSValue::dump):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138073 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0520bd41
    • mhahnenberg@apple.com's avatar
      Restrictions on oversize CopiedBlock allocations should be relaxed · 22e209a9
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105339
      
      Reviewed by Filip Pizlo.
      
      Currently the DFG has a single branch in the inline allocation path for property/array storage where
      it checks to see if the number of bytes requested will fit in the current block. This does not match
      what the C++ allocation path does; it checks if the requested number of bytes is oversize, and then
      if it's not, it tries to fit it in the current block. The garbage collector assumes that ALL allocations
      that are greater than 16KB are in oversize blocks. Therefore, this mismatch can lead to crashes when
      the collector tries to perform some operation on a CopiedBlock.
      
      To avoid adding an extra branch to the inline allocation path in the JIT, we should make it so that
      oversize blocks are allocated on the same alignment boundaries so that there is a single mask to find
      the block header of any CopiedBlock (rather than two, one for normal and one for oversize blocks), and
      we should figure out if a block is oversize by some other method than just whatever the JSObject says
      it is. One way we could record this info Region of the block, since we allocate a one-off Region for
      oversize blocks.
      
      * heap/BlockAllocator.h:
      (JSC::Region::isCustomSize):
      (Region):
      (JSC::Region::createCustomSize):
      (JSC::Region::Region):
      (JSC::BlockAllocator::deallocateCustomSize):
      * heap/CopiedBlock.h:
      (CopiedBlock):
      (JSC::CopiedBlock::isOversize):
      (JSC):
      * heap/CopiedSpace.cpp:
      (JSC::CopiedSpace::tryAllocateOversize):
      (JSC::CopiedSpace::tryReallocate):
      (JSC::CopiedSpace::tryReallocateOversize):
      * heap/CopiedSpace.h:
      (CopiedSpace):
      * heap/CopiedSpaceInlines.h:
      (JSC::CopiedSpace::contains):
      (JSC::CopiedSpace::tryAllocate):
      (JSC):
      * heap/CopyVisitor.h:
      (CopyVisitor):
      * heap/CopyVisitorInlines.h:
      (JSC::CopyVisitor::checkIfShouldCopy):
      (JSC::CopyVisitor::didCopy):
      * heap/SlotVisitorInlines.h:
      (JSC::SlotVisitor::copyLater):
      * runtime/JSObject.cpp:
      (JSC::JSObject::copyButterfly):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138067 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      22e209a9
  12. 17 Dec, 2012 2 commits
  13. 13 Dec, 2012 4 commits
    • fpizlo@apple.com's avatar
      Don't assert that flags <= 0x3ff in JSTypeInfo · 08775b8a
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104988
      
      Reviewed by Sam Weinig.
      
      This assertion doesn't accomplish anything other than crashes.
      
      * runtime/JSTypeInfo.h:
      (JSC::TypeInfo::TypeInfo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137705 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      08775b8a
    • fpizlo@apple.com's avatar
      Named lookups on HTML documents produce inconsistent results in JavaScriptCore bindings · 6e5582e7
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104623
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      Add the notion of objects that HasImpureGetOwnPropertySlot, and use that to inhibit prototype chain caching
      in some cases. This appears to be perf-neutral on benchmarks that we track.
      
      * dfg/DFGRepatch.cpp:
      (JSC::DFG::tryCacheGetByID):
      (JSC::DFG::tryBuildGetByIDProtoList):
      * jit/JITStubs.cpp:
      (JSC::JITThunks::tryCacheGetByID):
      (JSC::DEFINE_STUB_FUNCTION):
      * runtime/JSTypeInfo.h:
      (JSC):
      (JSC::TypeInfo::hasImpureGetOwnPropertySlot):
      * runtime/Operations.h:
      (JSC::normalizePrototypeChainForChainAccess):
      
      Source/WebCore: 
      
      All DOM objects that have named getters or directly override getOwnPropertySlot are now marked as
      HasImpureGetOwnPropertySlot.
      
      Tests: fast/js/prototype-chain-caching-with-impure-get-own-property-slot-traps
             fast/js/dfg-prototype-chain-caching-with-impure-get-own-property-slot-traps
      
      * bindings/scripts/CodeGeneratorJS.pm:
      (GenerateHeader):
      
      LayoutTests: 
      
      * fast/js/dfg-prototype-chain-caching-with-impure-get-own-property-slot-traps-expected.txt: Added.
      * fast/js/dfg-prototype-chain-caching-with-impure-get-own-property-slot-traps.html: Added.
      * fast/js/prototype-chain-caching-with-impure-get-own-property-slot-traps-expected.txt: Added.
      * fast/js/prototype-chain-caching-with-impure-get-own-property-slot-traps.html: Added.
      * fast/js/script-tests/dfg-prototype-chain-caching-with-impure-get-own-property-slot-traps.js: Added.
      (f):
      * fast/js/script-tests/prototype-chain-caching-with-impure-get-own-property-slot-traps.js: Added.
      (f):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137700 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6e5582e7
    • fpizlo@apple.com's avatar
      Unreviewed, roll out http://trac.webkit.org/changeset/137683. · 8376f062
      fpizlo@apple.com authored
      It broke gmail.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::execute):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::putStructureStoreElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canCompileOpcode):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * runtime/Operations.cpp:
      (JSC::jsTypeStringForValue):
      (JSC):
      * runtime/Operations.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137699 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8376f062
    • oliver@apple.com's avatar
      Support op_typeof in the DFG · a005d207
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=98898
      
      Reviewed by Filip Pizlo.
      
      Adds a TypeOf node to the DFG to support op_typeof.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::execute):
        We try to determine the result early here, and substitute in a constant.
        Otherwise we leave the node intact, and set the result type to SpecString.
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
        Parse op_typeof
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
        TypeOf nodes can be subjected to pure CSE
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canCompileOpcode):
        We can handle typeof.
      * dfg/DFGNodeType.h:
      (DFG):
        Define the node.
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
        Add operationTypeOf to support the non-trivial cases.
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
        Actual codegen
      * runtime/Operations.cpp:
      (JSC::jsTypeStringForValue):
      (JSC):
      * runtime/Operations.h:
      (JSC):
        Some refactoring to allow us to get the type string for an
        object without needing a callframe.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a005d207
  14. 11 Dec, 2012 1 commit
    • fpizlo@apple.com's avatar
      Profiler should show bytecode dumps as they would have been visible to the... · 77ef0e33
      fpizlo@apple.com authored
      Profiler should show bytecode dumps as they would have been visible to the JITs, including the profiling data that the JITs would see
      https://bugs.webkit.org/show_bug.cgi?id=104647
      
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore: 
      
      Adds more profiling data to bytecode dumps, and adds the ability to do a secondary
      bytecode dump for each JIT compilation of a code block. This is relevant because both
      the bytecodes, and the profiling data, may change after some number of executions.
              
      Also fixes some random dumping code to use PrintStream& rather than
      static const char[thingy].
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * bytecode/ArrayProfile.cpp:
      (JSC::dumpArrayModes):
      (JSC::ArrayProfile::briefDescription):
      * bytecode/ArrayProfile.h:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::printGetByIdOp):
      (JSC::CodeBlock::printGetByIdCacheStatus):
      (JSC::CodeBlock::printCallOp):
      (JSC::CodeBlock::dumpValueProfiling):
      (JSC::CodeBlock::dumpArrayProfiling):
      (JSC::CodeBlock::dumpBytecode):
      * bytecode/CodeBlock.h:
      * bytecode/ValueProfile.h:
      (JSC::ValueProfileBase::briefDescription):
      * dfg/DFGAbstractValue.h:
      (JSC::DFG::AbstractValue::dump):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseCodeBlock):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile):
      * profiler/ProfilerBytecodeSequence.cpp: Added.
      (JSC::Profiler::BytecodeSequence::BytecodeSequence):
      (JSC::Profiler::BytecodeSequence::~BytecodeSequence):
      (JSC::Profiler::BytecodeSequence::indexForBytecodeIndex):
      (JSC::Profiler::BytecodeSequence::forBytecodeIndex):
      (JSC::Profiler::BytecodeSequence::addSequenceProperties):
      * profiler/ProfilerBytecodeSequence.h: Added.
      (JSC::Profiler::BytecodeSequence::size):
      (JSC::Profiler::BytecodeSequence::at):
      * profiler/ProfilerBytecodes.cpp:
      (JSC::Profiler::Bytecodes::Bytecodes):
      (JSC::Profiler::Bytecodes::toJS):
      * profiler/ProfilerBytecodes.h:
      (JSC::Profiler::Bytecodes::instructionCount):
      * profiler/ProfilerCompilation.cpp:
      (JSC::Profiler::Compilation::addProfiledBytecodes):
      (JSC::Profiler::Compilation::toJS):
      * profiler/ProfilerCompilation.h:
      (JSC::Profiler::Compilation::profiledBytecodesSize):
      (JSC::Profiler::Compilation::profiledBytecodesAt):
      * profiler/ProfilerDatabase.cpp:
      (JSC::Profiler::Database::ensureBytecodesFor):
      * profiler/ProfilerDatabase.h:
      * profiler/ProfilerProfiledBytecodes.cpp: Added.
      (JSC::Profiler::ProfiledBytecodes::ProfiledBytecodes):
      (JSC::Profiler::ProfiledBytecodes::~ProfiledBytecodes):
      (JSC::Profiler::ProfiledBytecodes::toJS):
      * profiler/ProfilerProfiledBytecodes.h: Added.
      (JSC::Profiler::ProfiledBytecodes::bytecodes):
      * runtime/CommonIdentifiers.h:
      
      Tools: 
      
      Added a "profiling" (or "p") command to show the profiling data that the JITs saw
      for each JIT compilation of a code block.
              
      Also added instruction counts in the "full" display and made the "full" display the
      default thing you see.
      
      * Scripts/display-profiler-output:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137379 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      77ef0e33
  15. 10 Dec, 2012 2 commits
    • fpizlo@apple.com's avatar
      JSC profiling and debug dump code should use inferred names when possible · 1a6da216
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104519
      
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore: 
      
      This does as advertised: the profiler now knows the inferred name of all code blocks,
      and all uses of CodeBlock::dump() dump it along with the hash.
              
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::inferredName):
      (JSC::CodeBlock::dumpAssumingJITType):
      * bytecode/CodeBlock.h:
      * profiler/ProfilerBytecodes.cpp:
      (JSC::Profiler::Bytecodes::Bytecodes):
      (JSC::Profiler::Bytecodes::toJS):
      * profiler/ProfilerBytecodes.h:
      (JSC::Profiler::Bytecodes::inferredName):
      * profiler/ProfilerDatabase.cpp:
      (JSC::Profiler::Database::addBytecodes):
      (JSC::Profiler::Database::ensureBytecodesFor):
      * profiler/ProfilerDatabase.h:
      * runtime/CommonIdentifiers.h:
      
      Tools: 
      
      The format I'm using for referring to a code block is now name#hash. For example,
      v8-crypto has something called bnpSquareTo#B5QFbU. The profiler allows you to use
      either the hash, the inferred name, or the combined hash and full name when referring
      to blocks.
      
      * Scripts/display-profiler-output:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137179 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1a6da216
    • fpizlo@apple.com's avatar
      Profiler should say things about OSR exits · d2deec81
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104497
      
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore: 
      
      This adds support for profiling OSR exits. For each exit that is taken, the profiler
      records the machine code address that the exit occurred on, the exit kind, the origin
      stack, and the number of times that it happened.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * assembler/AbstractMacroAssembler.h:
      (Jump):
      (JSC::AbstractMacroAssembler::Jump::label):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::saveCompilation):
      (CodeBlock):
      (JSC::CodeBlock::compilation):
      (DFGData):
      * bytecode/DFGExitProfile.h:
      (DFG):
      * bytecode/ExitKind.cpp: Added.
      (JSC):
      (JSC::exitKindToString):
      (JSC::exitKindIsCountable):
      (WTF):
      (WTF::printInternal):
      * bytecode/ExitKind.h: Added.
      (JSC):
      (WTF):
      * dfg/DFGGraph.h:
      (Graph):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::linkOSRExits):
      (JSC::DFG::JITCompiler::link):
      (JSC::DFG::JITCompiler::compile):
      (JSC::DFG::JITCompiler::compileFunction):
      * dfg/DFGJITCompiler.h:
      (JITCompiler):
      * dfg/DFGOSRExitCompiler.cpp:
      * jit/JIT.cpp:
      (JSC::JIT::JIT):
      (JSC::JIT::privateCompile):
      * jit/JIT.h:
      (JIT):
      * jit/JumpReplacementWatchpoint.h:
      (JSC::JumpReplacementWatchpoint::sourceLabel):
      (JumpReplacementWatchpoint):
      * profiler/ProfilerCompilation.cpp:
      (JSC::Profiler::Compilation::addOSRExitSite):
      (Profiler):
      (JSC::Profiler::Compilation::addOSRExit):
      (JSC::Profiler::Compilation::toJS):
      * profiler/ProfilerCompilation.h:
      (Compilation):
      * profiler/ProfilerDatabase.cpp:
      (JSC::Profiler::Database::newCompilation):
      * profiler/ProfilerDatabase.h:
      (Database):
      * profiler/ProfilerOSRExit.cpp: Added.
      (Profiler):
      (JSC::Profiler::OSRExit::OSRExit):
      (JSC::Profiler::OSRExit::~OSRExit):
      (JSC::Profiler::OSRExit::toJS):
      * profiler/ProfilerOSRExit.h: Added.
      (Profiler):
      (OSRExit):
      (JSC::Profiler::OSRExit::id):
      (JSC::Profiler::OSRExit::origin):
      (JSC::Profiler::OSRExit::exitKind):
      (JSC::Profiler::OSRExit::isWatchpoint):
      (JSC::Profiler::OSRExit::counterAddress):
      (JSC::Profiler::OSRExit::count):
      * profiler/ProfilerOSRExitSite.cpp: Added.
      (Profiler):
      (JSC::Profiler::OSRExitSite::toJS):
      * profiler/ProfilerOSRExitSite.h: Added.
      (Profiler):
      (OSRExitSite):
      (JSC::Profiler::OSRExitSite::OSRExitSite):
      (JSC::Profiler::OSRExitSite::codeAddress):
      * runtime/CommonIdentifiers.h:
      
      Tools: 
      
      Adds support for displaying OSR exit information for full summary (just displays the
      counts and the number of recompilations), bytecode display (says which bytecodes
      exited), and DFG display (annotates disassembly with taken OSR exits and their
      counts).
      
      * Scripts/display-profiler-output:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137175 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d2deec81
  16. 09 Dec, 2012 1 commit
    • fpizlo@apple.com's avatar
      JSC should scale the optimization threshold for a code block according to the cost of compiling it · 7f7ba49f
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104406
      
      Reviewed by Oliver Hunt.
      
      We've long known that we want to scale the execution count threshold needed for the DFG
      to kick in to scale according to some estimate of the cost of compiling that code block.
      This institutes a relationship like this:
              
      threshold = thresholdSetting * (a * sqrt(instructionCount + b) + abs(c * instructionCount) + d
              
      Where a, b, c, d are coefficients derived from fitting the above expression to various
      data points, which I chose based on looking at one benchmark (3d-cube) and from my
      own intuitions.
              
      Making this work well also required changing the thresholdForOptimizeAfterLongWarmUp
      from 5000 to 1000.
              
      This is a >1% speed-up on SunSpider, a >3% speed-up on V8Spider, ~1% speed-up on V8v7,
      neutral on Octane, and neutral on Kraken.
              
      I also out-of-lined a bunch of methods related to these heuristics, because I couldn't
      stand having them defined in the header anymore. I also made improvements to debugging
      code because I needed it for tuning this change.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::sourceCodeForTools):
      (JSC::CodeBlock::sourceCodeOnOneLine):
      (JSC::CodeBlock::dumpBytecode):
      (JSC::CodeBlock::CodeBlock):
      (JSC::CodeBlock::reoptimizationRetryCounter):
      (JSC::CodeBlock::countReoptimization):
      (JSC::CodeBlock::optimizationThresholdScalingFactor):
      (JSC::clipThreshold):
      (JSC::CodeBlock::counterValueForOptimizeAfterWarmUp):
      (JSC::CodeBlock::counterValueForOptimizeAfterLongWarmUp):
      (JSC::CodeBlock::counterValueForOptimizeSoon):
      (JSC::CodeBlock::checkIfOptimizationThresholdReached):
      (JSC::CodeBlock::optimizeNextInvocation):
      (JSC::CodeBlock::dontOptimizeAnytimeSoon):
      (JSC::CodeBlock::optimizeAfterWarmUp):
      (JSC::CodeBlock::optimizeAfterLongWarmUp):
      (JSC::CodeBlock::optimizeSoon):
      (JSC::CodeBlock::adjustedExitCountThreshold):
      (JSC::CodeBlock::exitCountThresholdForReoptimization):
      (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
      (JSC::CodeBlock::shouldReoptimizeNow):
      (JSC::CodeBlock::shouldReoptimizeFromLoopNow):
      * bytecode/CodeBlock.h:
      * bytecode/ExecutionCounter.cpp:
      (JSC::ExecutionCounter::hasCrossedThreshold):
      * bytecode/ReduceWhitespace.cpp: Added.
      (JSC::reduceWhitespace):
      * bytecode/ReduceWhitespace.h: Added.
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::mightCompileEval):
      (JSC::DFG::mightCompileProgram):
      (JSC::DFG::mightCompileFunctionForCall):
      (JSC::DFG::mightCompileFunctionForConstruct):
      (JSC::DFG::mightInlineFunctionForCall):
      (JSC::DFG::mightInlineFunctionForConstruct):
      * dfg/DFGCapabilities.h:
      * dfg/DFGDisassembler.cpp:
      (JSC::DFG::Disassembler::dumpHeader):
      * dfg/DFGOSREntry.cpp:
      (JSC::DFG::prepareOSREntry):
      * jit/JITDisassembler.cpp:
      (JSC::JITDisassembler::dumpHeader):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::entryOSR):
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * profiler/ProfilerDatabase.cpp:
      (JSC::Profiler::Database::ensureBytecodesFor):
      * runtime/Options.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7f7ba49f
  17. 07 Dec, 2012 2 commits
  18. 06 Dec, 2012 2 commits
  19. 05 Dec, 2012 1 commit
    • oliver@apple.com's avatar
      Empty parse cache when receiving a low memory warning · c32e3a0e
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=104161
      
      Reviewed by Filip Pizlo.
      
      Source/JavaScriptCore:
      
      This adds a function to the globaldata to empty all code related data
      structures (code in the heap and the code cache).
      It also adds a function to allow the CodeCache to actually be cleared
      at all.
      
      * runtime/CodeCache.h:
      (CacheMap):
      (JSC::CacheMap::clear):
      (JSC::CodeCache::clear):
      (CodeCache):
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::discardAllCode):
      (JSC):
      * runtime/JSGlobalData.h:
      (JSGlobalData):
      
      Source/WebCore:
      
      Use new discardAllCode() function on the global data, rather than
      directly interacting with the heap.
      
      * bindings/js/GCController.cpp:
      (WebCore::GCController::discardAllCompiledCode):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@136773 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c32e3a0e