Source/JavaScriptCore/ChangeLog-2013-04-24 - external/WebKit_trimmed - Git at Google

 2013-04-23  Filip Pizlo  <fpizlo@apple.com>

         DFG CFA filters CheckFunction in a really weird way, and assumes that the function's structure won't change
         https://bugs.webkit.org/show_bug.cgi?id=115077

         Reviewed by Oliver Hunt.

         The filtering did three things that are unusual:

         1) AbstractValue::filterByValue() assumed that the passed value's structure wouldn't change, in
            the sense that at it assumed it could use that value's *current* structure to do structure
            filtering. Filtering by structure only makes sense if you can prove that the given value will
            always have that structure (for example by either using a watchpoing or emitting code that
            checks that structure at run-time).

         2) AbstractValue::filterByValue() and the CheckFunction case in AbstractState::executeEffects()
            tried to invalidate the CFA based on whether the filtration led to an empty value. This is
            well-intentioned, but it's not how the CFA currently works. It's inconsistent with other
            parts of the CFA. We shouldn't introduce this feature into just one kind of filtration and
            not have it elsewhere.

         3) The attempt to detect when the value was empty was actually implemented incorrectly. It
            relied on AbstractValue::validate(). That method says that a concrete value does not belong
            to the abstract value if it has a different structure. This makes sense for the other place
            where AbstractValue::validate() is called: during OSR entry, where we are talking about a
            JSValue that we see *right now*. It doesn't make sense in the CFA, since in the CFA any
            value we observe in the code is a value whose structure may change when the code starts
            running, and so we cannot use the value's current structure to infer things about the code
            when it starts running.

         I fixed the above problems by (1) changing filterByValue() to not filter the structure, (2)
         changing filterByValue() and the CheckFunction case to not invalidate the CFA, and (3)
         making sure that nobody else was misusing AbstractValue::validate() (they weren't).

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::filterByValue):

 2013-04-23  Oliver Hunt  <oliver@apple.com>

         Default ParserError() initialiser doesn't initialise all fields
         https://bugs.webkit.org/show_bug.cgi?id=115074

         Reviewed by Joseph Pecoraro.

         Only the jsc command prompt depended on this, but we'll fix it to
         be on the safe side.

         * parser/ParserError.h:
         (JSC::ParserError::ParserError):

 2013-04-23  Christophe Dumez  <ch.dumez@sisa.samsung.com>

         Global constructors should be configurable and not enumerable
         https://bugs.webkit.org/show_bug.cgi?id=110573

         Reviewed by Geoffrey Garen.

         Update JSObject::deleteProperty() so that mark to set the property
         value to undefined if it is in static hashtable of properties. The
         previous code was not doing anything in this case and this meant
         we could not remove builtin DOMWindow properties such as
         "ProgressEvent" even if marked as Deletable.

         * runtime/JSObject.cpp:
         (JSC::JSObject::deleteProperty):
         * runtime/Lookup.h:
         (JSC):
         (JSC::putEntry):
         (JSC::lookupPut):

 2013-04-23  Geoffrey Garen  <ggaren@apple.com>

         Filled out more cases of branch folding in bytecode when emitting
         expressions into a branching context
         https://bugs.webkit.org/show_bug.cgi?id=115057

         Reviewed by Filip Pizlo.

         This covers a few cases like:

             - while (true) { }
             - while (1) { }
             - if (x) break;
             - if (x) continue;
             - if (boolean_expr == boolean_const) { }
             - if (boolean_expr == 1_or_0) { }
             - if (bitop == 1_or_0) { }

         This also works, but will bring shame on your family:

             - while ("hello world") { }

         No change on the benchmarks we track, but a 2.5X speedup on a microbenchmark
         that uses these techniques.

         * JavaScriptCore.order: Order!

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitNewArray):
         (JSC::BytecodeGenerator::emitThrowReferenceError):
         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
         * bytecompiler/BytecodeGenerator.h:
         (JSC::BytecodeGenerator::shouldEmitDebugHooks): Updated ancillary code
         for interface simplifications.

         * bytecompiler/NodesCodegen.cpp:
         (JSC::ConstantNode::emitBytecodeInConditionContext): Constants can
         jump unconditionally when used within a condition context.

         (JSC::ConstantNode::emitBytecode):
         (JSC::StringNode::jsValue): Gave constants a common base class so I
         could implement their codegen just once.

         (JSC::BinaryOpNode::emitBytecodeInConditionContext):
         (JSC::canFoldToBranch):
         (JSC::BinaryOpNode::tryFoldToBranch): Fold (!/=)= and (!/=)== where
         appropriate. A lot of cases are not appropriate because of the surprising
         type conversion semantics of ==. For example, if (number == true) { } is
         not the same as if (number) { } because the former will up-convert true
         to number and then do numeric comparison.

         (JSC::singleStatement):
         (JSC::IfElseNode::tryFoldBreakAndContinue):
         (JSC::IfElseNode::emitBytecode):
         (JSC::ContinueNode::trivialTarget):
         (JSC::BreakNode::trivialTarget): Fold "if (expression) break" and
         "if (expression) continue" into direct jumps from expression.

         * parser/ASTBuilder.h:
         (ASTBuilder):
         (JSC::ASTBuilder::createIfStatement):
         * parser/NodeConstructors.h:
         (JSC::ConstantNode::ConstantNode):
         (JSC):
         (JSC::NullNode::NullNode):
         (JSC::BooleanNode::BooleanNode):
         (JSC::NumberNode::NumberNode):
         (JSC::StringNode::StringNode):
         (JSC::IfElseNode::IfElseNode):
         * parser/Nodes.h:
         (JSC::ExpressionNode::isConstant):
         (JSC::ExpressionNode::isBoolean):
         (JSC::StatementNode::isBreak):
         (JSC::StatementNode::isContinue):
         (ConstantNode):
         (JSC::ConstantNode::isPure):
         (JSC::ConstantNode::isConstant):
         (NullNode):
         (JSC::NullNode::jsValue):
         (JSC::BooleanNode::value):
         (JSC::BooleanNode::isBoolean):
         (JSC::BooleanNode::jsValue):
         (JSC::NumberNode::value):
         (NumberNode):
         (JSC::NumberNode::jsValue):
         (StringNode):
         (BinaryOpNode):
         (IfElseNode):
         (ContinueNode):
         (JSC::ContinueNode::isContinue):
         (BreakNode):
         (JSC::BreakNode::isBreak):
         * parser/Parser.cpp:
         (JSC::::parseIfStatement):
         * parser/ResultType.h:
         (JSC::ResultType::definitelyIsBoolean):
         (ResultType):
         * runtime/JSCJSValueInlines.h:
         (JSC::JSValue::pureToBoolean):
         * runtime/JSCell.h:
         * runtime/JSCellInlines.h:
         (JSC::JSCell::pureToBoolean): Updated for interface changes above.

 2013-04-23  Mark Lam  <mark.lam@apple.com>

         Simplify the baseline JIT loop hint call site.
         https://bugs.webkit.org/show_bug.cgi?id=115052.

         Reviewed by Geoffrey Garen.

         Moved the watchdog timer check after the JIT optimization check. This
         ensures that the JIT opimization counter is incremented on every loop
         hint even if the watchdog timer fires.

         Removed the code that allows the JIT OSR to happen if the watchdog
         timer fires but does not result in a termination. It is extremely rare
         that the JIT optimization counter would trigger an OSR on the same pass
         as when the watchdog timer fire. If it does happen, we'll simply hold
         off on servicing the watchdog timer until the next pass (because it's
         not time critical).

         * jit/JITOpcodes.cpp:
         (JSC::JIT::emit_op_loop_hint):
         (JSC::JIT::emitSlow_op_loop_hint):

 2013-04-23  Roger Fong  <roger_fong@apple.com>

         AppleWin build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:

 2013-04-18  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Update public header documentation
         https://bugs.webkit.org/show_bug.cgi?id=114841

         Reviewed by Geoffrey Garen.

         Added documentation for the newly added object lifetime-related stuff.

         * API/JSManagedValue.h:
         * API/JSVirtualMachine.h:

 2013-04-22  Mark Lam  <mark.lam@apple.com>

         Fix a typo in MacroAssemblerARMv7.h.
         https://bugs.webkit.org/show_bug.cgi?id=115011.

         Reviewed by Geoffrey Garen.

         * assembler/ARMAssembler.h: Fix a comment.
         * assembler/ARMv7Assembler.h: Added some comments.
         * assembler/MacroAssemblerARMv7.h:
           - ARMAssembler::PL should be ARMv7Assembler::ConditionPL.

 2013-04-22  Julien Brianceau  <jbrianceau@nds.com>

         Add branchAdd32 missing implementation in SH4 base JIT.
         This should fix SH4 build, broken since r148893.
         https://bugs.webkit.org/show_bug.cgi?id=114993.

         Reviewed by Oliver Hunt.

         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::branchAdd32):
         (MacroAssemblerSH4):

 2013-04-22  Benjamin Poulain  <bpoulain@apple.com>

         Windows build fix after r148921

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-22  Benjamin Poulain  <benjamin@webkit.org>

         Remove the memory instrumentation code
         https://bugs.webkit.org/show_bug.cgi?id=114931

         Reviewed by Andreas Kling.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-22  Mark Lam  <mark.lam@apple.com>

         Fix broken 32-bit build to green the bots.
         https://bugs.webkit.org/show_bug.cgi?id=114968.

         Unreviewed.

         Basically, I moved a JIT::emit_op_loop_hint() and JIT::emitSlow_op_loop_hint()
         into common code where they belong, instead of the 64-bit specific section.

         Also fixed some SH4 assertions failures which were also caused by
         https://bugs.webkit.org/show_bug.cgi?id=114963. Thanks to Julien Brianceau
         for pointing this out.

         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::branchAdd32):
         * jit/JITOpcodes.cpp:
         (JSC):
         (JSC::JIT::emit_op_loop_hint):
         (JSC::JIT::emitSlow_op_loop_hint):

 2013-04-22  Oliver Hunt  <oliver@apple.com>

         Perform null check before trying to use the result of readline()

         RS=Gavin

         * jsc.cpp:
         (runInteractive):

 2013-04-22  Oliver Hunt  <oliver@apple.com>

         Fix assertions to account for new Vector layout

         RS=Gavin

         * llint/LLIntData.cpp:
         (JSC::LLInt::Data::performAssertions):

 2013-04-22  Mark Lam  <mark.lam@apple.com>

         Change baseline JIT watchdog timer check to use the proper fast slow path
         infrastructure.
         https://bugs.webkit.org/show_bug.cgi?id=114963.

         Reviewed by Oliver Hunt.

         Edit: The PositiveOrZero condition is added because it is needed for
         the JIT optimization check. Previously, the JIT check branches around
         the slow path if the test result is 'Signed' i.e. negative. Since we
         now need to test for a condition that branches to the slow path (not
         around it), we need the complement of 'Signed / Negative' i.e. Positive
         or zero.

         SH4 parts contributed by Julien Brianceau.

         * assembler/ARMAssembler.h:
         * assembler/MacroAssemblerARM.h:
         * assembler/MacroAssemblerARMv7.h:
         * assembler/MacroAssemblerMIPS.h:
         (JSC::MacroAssemblerMIPS::branchAdd32):
         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::branchAdd32):
         * assembler/MacroAssemblerX86Common.h:
         * assembler/SH4Assembler.h:
         * jit/JIT.cpp:
         (JSC::JIT::emitEnterOptimizationCheck):
         (JSC::JIT::privateCompileSlowCases):
         * jit/JIT.h:
         (JSC::JIT::emitEnterOptimizationCheck):
         * jit/JITOpcodes.cpp:
         (JSC::JIT::emit_op_loop_hint):
         (JSC::JIT::emitSlow_op_loop_hint):
         (JSC::JIT::emit_op_enter):
         * jit/JITOpcodes32_64.cpp:
         (JSC::JIT::emit_op_enter):

 2013-04-22  Andreas Kling  <akling@apple.com>

         Shrink baseline size of WTF::Vector on 64-bit by switching to unsigned capacity and size.
         <http://webkit.org/b/97268>
         <rdar://problem/12376519>

         Reviewed by Sam Weinig.

         Update LLInt WTF::Vector offset constants to match the new memory layout.

         * llint/LowLevelInterpreter.asm:

 2013-04-21  Oliver Hunt  <oliver@apple.com>

         JS Lexer and Parser should be more informative when they encounter errors
         https://bugs.webkit.org/show_bug.cgi?id=114924

         Reviewed by Filip Pizlo.

         Add new tokens to represent the various ways that parsing and lexing have failed.
         This gives us the ability to produce better error messages in some cases,
         and to indicate whether or not the failure was due to invalid source, or simply
         early termination.

         The jsc prompt now makes use of this so that you can write functions that
         are more than one line long.

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::generate):
         * jsc.cpp:
         (stringFromUTF):
         (jscSource):
         (runInteractive):
         * parser/Lexer.cpp:
         (JSC::::parseFourDigitUnicodeHex):
         (JSC::::parseIdentifierSlowCase):
         (JSC::::parseString):
         (JSC::::parseStringSlowCase):
         (JSC::::lex):
         * parser/Lexer.h:
         (UnicodeHexValue):
         (JSC::Lexer::UnicodeHexValue::UnicodeHexValue):
         (JSC::Lexer::UnicodeHexValue::valueType):
         (JSC::Lexer::UnicodeHexValue::isValid):
         (JSC::Lexer::UnicodeHexValue::value):
         (Lexer):
         * parser/Parser.h:
         (JSC::Parser::getTokenName):
         (JSC::Parser::updateErrorMessageSpecialCase):
         (JSC::::parse):
         * parser/ParserError.h:
         (ParserError):
         (JSC::ParserError::ParserError):
         * parser/ParserTokens.h:
         * runtime/Completion.cpp:
         (JSC):
         (JSC::checkSyntax):
         * runtime/Completion.h:
         (JSC):

 2013-04-21  Mark Lam  <mark.lam@apple.com>

         Refactor identical inline functions in JSVALUE64 and JSVALUE32_64 sections
         out into the common section.
         https://bugs.webkit.org/show_bug.cgi?id=114910.

         Reviewed by Filip Pizlo.

         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::callOperation):

 2013-04-20  Allan Sandfeld Jensen  <allan.jensen@digia.com>

         LLint should be able to use x87 instead of SSE for floating pointer
         https://bugs.webkit.org/show_bug.cgi?id=112239

         Reviewed by Filip Pizlo.

         Implements LLInt floating point operations in x87, to ensure we support
         x86 without SSE2.

         X86 (except 64bit) now defaults to using x87 instructions in order to
         support all 32bit x86 back to i686. The implementation uses the fucomi
         instruction from i686 which sets the new minimum.

         The FPU registers must always be empty on entering or exiting a function.
         We make sure to only use two X87 registers, and they are always emptied
         before calling deeper functions or returning from the LLInt.

         * jit/JITStubs.cpp:
         (JSC): Empty FPU registers before exiting.
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:
         * offlineasm/instructions.rb:
         * offlineasm/x86.rb:

 2013-04-19  Roger Fong  <roger_fong@apple.com>

         Remove uses of WebKit_Source from AppleWin build in JavaScriptCore.

         * JavaScriptCore.vcxproj/JavaScriptCore.make:
         * JavaScriptCore.vcxproj/build-generated-files.sh:
         * JavaScriptCore.vcxproj/copy-files.cmd:
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:

 2013-04-19  Benjamin Poulain  <bpoulain@apple.com>

         Rename JSStringJoiner::build() to join()
         https://bugs.webkit.org/show_bug.cgi?id=114845

         Reviewed by Geoffrey Garen.

         The method name build() came from StringBuilder history. It does not make much
         sense on the StringJoiner.

         * runtime/ArrayPrototype.cpp:
         (JSC::arrayProtoFuncToString):
         (JSC::arrayProtoFuncToLocaleString):
         (JSC::arrayProtoFuncJoin):
         * runtime/JSStringJoiner.cpp:
         (JSC::JSStringJoiner::join):
         * runtime/JSStringJoiner.h:
         (JSStringJoiner):

 2013-04-19  Roger Fong  <roger_fong@apple.com>

         Unreviewed. WebKit_Source is incorrectly set.

         * JavaScriptCore.vcxproj/JavaScriptCore.make:

 2013-04-19  Martin Robinson  <mrobinson@igalia.com>

         [GTK] JSCore.gir.in has a few problems
         https://bugs.webkit.org/show_bug.cgi?id=114710

         Reviewed by Philippe Normand.

         * GNUmakefile.am: Add the gobject introspection steps for JavaScriptCore here,
         because they are shared between WebKit1 and WebKit2.
         * JavaScriptCore.gir.in: Added. Moved from the WebKit1 directory. Now written
         as foreign interfaces and referencing the javascriptcoregtk library.

 2013-04-18  Benjamin Poulain  <bpoulain@apple.com>

         Use StringJoiner to create the JSString of arrayProtoFuncToString
         https://bugs.webkit.org/show_bug.cgi?id=114779

         Reviewed by Geoffrey Garen.

         The function arrayProtoFuncToString was just a glorified JSStringJoiner.
         This patch replaces it by JSStringJoiner to simplify the code and enjoy any optimization
         made on JSStringJoiner.

         For some reason, this makes the execution 3.4% faster, despite having almost identical code.

         * runtime/ArrayPrototype.cpp:
         (JSC::arrayProtoFuncToString):

 2013-04-18  Oliver Hunt  <oliver@apple.com>

         StackFrame::column() returning bogus value
         https://bugs.webkit.org/show_bug.cgi?id=114840

         Reviewed by Gavin Barraclough.

         Don't add one part of the expression offset to the other part of the expression.
         Make StackFrame::toString() include the column info.

         * interpreter/Interpreter.cpp:
         (JSC::StackFrame::expressionInfo):
         (JSC::StackFrame::toString):

 2013-04-18  Mark Hahnenberg  <mhahnenberg@apple.com>

         Crash beneath JSC::JIT::privateCompileSlowCases @ stephenrdonaldson.com
         https://bugs.webkit.org/show_bug.cgi?id=114774

         Reviewed by Geoffrey Garen.

         We're not linking up all of the slow cases in the baseline JIT when compiling put_to_base.

         * jit/JITOpcodes.cpp:
         (JSC::JIT::emitSlow_op_put_to_base):

 2013-04-18  Mark Lam  <mark.lam@apple.com>

         Interpreter entry points should throw the TerminatedExecutionException from the caller frame.
         https://bugs.webkit.org/show_bug.cgi?id=114816.

         Reviewed by Oliver Hunt.

         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::execute):
         (JSC::Interpreter::executeCall):
         (JSC::Interpreter::executeConstruct):

 2013-04-18  Gabor Rapcsanyi  <rgabor@webkit.org>

         LLInt ARM backend should not use the d8 register as scratch register
         https://bugs.webkit.org/show_bug.cgi?id=114811

         Reviewed by Filip Pizlo.

         The d8 register must preserved across function calls and should
         not used as scratch register. Changing it to d6.

         * offlineasm/arm.rb:

 2013-04-18  Geoffrey Garen  <ggaren@apple.com>

         Removed HeapTimer::synchronize
         https://bugs.webkit.org/show_bug.cgi?id=114832

         Reviewed by Mark Hahnenberg.

         HeapTimer::synchronize was a flawed attempt to make HeapTimer thread-safe.
         Instead, we use proper locking now.

         This is a slight API change, since the GC timer will now only fire in the
         run loop that created the JS VM, even if another run loop later executes
         some JS.

         * API/APIShims.h:
         (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock):
         * heap/HeapTimer.cpp:
         (JSC):
         * heap/HeapTimer.h:
         (HeapTimer):

 2013-04-17  Geoffrey Garen  <ggaren@apple.com>

         Renamed JSGlobalData to VM
         https://bugs.webkit.org/show_bug.cgi?id=114777

         Reviewed by Phil Pizlo.

         * API/APICast.h:
         (JSC):
         (toJS):
         (toRef):
         * API/APIShims.h:
         (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock):
         (APIEntryShimWithoutLock):
         (JSC::APIEntryShim::APIEntryShim):
         (APIEntryShim):
         (JSC::APIEntryShim::~APIEntryShim):
         (JSC::APICallbackShim::APICallbackShim):
         (JSC::APICallbackShim::~APICallbackShim):
         (APICallbackShim):
         * API/JSAPIWrapperObject.h:
         (JSAPIWrapperObject):
         * API/JSAPIWrapperObject.mm:
         (JSC::::createStructure):
         (JSC::JSAPIWrapperObject::JSAPIWrapperObject):
         (JSC::JSAPIWrapperObject::finishCreation):
         (JSC::JSAPIWrapperObject::visitChildren):
         * API/JSBase.cpp:
         (JSGarbageCollect):
         (JSReportExtraMemoryCost):
         (JSSynchronousGarbageCollectForDebugging):
         * API/JSCallbackConstructor.cpp:
         (JSC::JSCallbackConstructor::JSCallbackConstructor):
         (JSC::JSCallbackConstructor::finishCreation):
         * API/JSCallbackConstructor.h:
         (JSC::JSCallbackConstructor::createStructure):
         * API/JSCallbackFunction.cpp:
         (JSC::JSCallbackFunction::finishCreation):
         (JSC::JSCallbackFunction::create):
         * API/JSCallbackFunction.h:
         (JSCallbackFunction):
         (JSC::JSCallbackFunction::createStructure):
         * API/JSCallbackObject.cpp:
         (JSC::::create):
         (JSC::::createStructure):
         * API/JSCallbackObject.h:
         (JSC::JSCallbackObjectData::setPrivateProperty):
         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
         (JSCallbackObject):
         (JSC::JSCallbackObject::setPrivateProperty):
         * API/JSCallbackObjectFunctions.h:
         (JSC::::JSCallbackObject):
         (JSC::::finishCreation):
         (JSC::::put):
         (JSC::::staticFunctionGetter):
         * API/JSClassRef.cpp:
         (OpaqueJSClassContextData::OpaqueJSClassContextData):
         (OpaqueJSClass::contextData):
         (OpaqueJSClass::prototype):
         * API/JSClassRef.h:
         (OpaqueJSClassContextData):
         * API/JSContext.mm:
         (-[JSContext setException:]):
         (-[JSContext initWithGlobalContextRef:]):
         (+[JSContext contextWithGlobalContextRef:]):
         * API/JSContextRef.cpp:
         (JSContextGroupCreate):
         (JSContextGroupRelease):
         (JSGlobalContextCreate):
         (JSGlobalContextCreateInGroup):
         (JSGlobalContextRetain):
         (JSGlobalContextRelease):
         (JSContextGetGroup):
         (JSContextCreateBacktrace):
         * API/JSObjectRef.cpp:
         (JSObjectMake):
         (JSObjectMakeConstructor):
         (JSObjectMakeFunction):
         (JSObjectSetPrototype):
         (JSObjectHasProperty):
         (JSObjectGetProperty):
         (JSObjectSetProperty):
         (JSObjectDeleteProperty):
         (JSObjectGetPrivateProperty):
         (JSObjectSetPrivateProperty):
         (JSObjectDeletePrivateProperty):
         (OpaqueJSPropertyNameArray::OpaqueJSPropertyNameArray):
         (OpaqueJSPropertyNameArray):
         (JSObjectCopyPropertyNames):
         (JSPropertyNameArrayRelease):
         (JSPropertyNameAccumulatorAddName):
         * API/JSScriptRef.cpp:
         (OpaqueJSScript::create):
         (OpaqueJSScript::vm):
         (OpaqueJSScript::OpaqueJSScript):
         (OpaqueJSScript):
         (parseScript):
         * API/JSVirtualMachine.mm:
         (scanExternalObjectGraph):
         * API/JSVirtualMachineInternal.h:
         (JSC):
         * API/JSWrapperMap.mm:
         (makeWrapper):
         * API/ObjCCallbackFunction.h:
         (JSC::ObjCCallbackFunction::createStructure):
         * API/ObjCCallbackFunction.mm:
         (JSC::ObjCCallbackFunction::create):
         * API/OpaqueJSString.cpp:
         (OpaqueJSString::identifier):
         * API/OpaqueJSString.h:
         (JSC):
         (OpaqueJSString):
         * GNUmakefile.list.am:
         * JSCTypedArrayStubs.h:
         (JSC):
         * JavaScriptCore.order:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * KeywordLookupGenerator.py:
         (Trie.printSubTreeAsC):
         * Target.pri:
         * assembler/ARMAssembler.cpp:
         (JSC::ARMAssembler::executableCopy):
         * assembler/ARMAssembler.h:
         (ARMAssembler):
         * assembler/AssemblerBuffer.h:
         (JSC::AssemblerBuffer::executableCopy):
         * assembler/AssemblerBufferWithConstantPool.h:
         (JSC::AssemblerBufferWithConstantPool::executableCopy):
         * assembler/LinkBuffer.cpp:
         (JSC::LinkBuffer::linkCode):
         * assembler/LinkBuffer.h:
         (JSC):
         (JSC::LinkBuffer::LinkBuffer):
         (LinkBuffer):
         * assembler/MIPSAssembler.h:
         (JSC::MIPSAssembler::executableCopy):
         * assembler/SH4Assembler.h:
         (JSC::SH4Assembler::executableCopy):
         * assembler/X86Assembler.h:
         (JSC::X86Assembler::executableCopy):
         (JSC::X86Assembler::X86InstructionFormatter::executableCopy):
         * bytecode/CallLinkInfo.cpp:
         (JSC::CallLinkInfo::unlink):
         * bytecode/CallLinkInfo.h:
         (CallLinkInfo):
         * bytecode/CodeBlock.cpp:
         (JSC::dumpStructure):
         (JSC::CodeBlock::printStructures):
         (JSC::CodeBlock::CodeBlock):
         (JSC::CodeBlock::~CodeBlock):
         (JSC::CodeBlock::visitStructures):
         (JSC::CodeBlock::finalizeUnconditionally):
         (JSC::CodeBlock::createActivation):
         (JSC::CodeBlock::unlinkCalls):
         (JSC::CodeBlock::unlinkIncomingCalls):
         (JSC::CodeBlock::findClosureCallForReturnPC):
         (JSC::ProgramCodeBlock::jettisonImpl):
         (JSC::EvalCodeBlock::jettisonImpl):
         (JSC::FunctionCodeBlock::jettisonImpl):
         (JSC::CodeBlock::predictedMachineCodeSize):
         (JSC::CodeBlock::usesOpcode):
         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::appendWeakReference):
         (JSC::CodeBlock::appendWeakReferenceTransition):
         (JSC::CodeBlock::setJITCode):
         (JSC::CodeBlock::setGlobalData):
         (JSC::CodeBlock::vm):
         (JSC::CodeBlock::valueProfileForBytecodeOffset):
         (JSC::CodeBlock::addConstant):
         (JSC::CodeBlock::setConstantRegisters):
         (CodeBlock):
         (JSC::CodeBlock::WeakReferenceTransition::WeakReferenceTransition):
         * bytecode/EvalCodeCache.h:
         (JSC::EvalCodeCache::getSlow):
         * bytecode/GetByIdStatus.cpp:
         (JSC::GetByIdStatus::computeFromLLInt):
         (JSC::GetByIdStatus::computeForChain):
         (JSC::GetByIdStatus::computeFor):
         * bytecode/GetByIdStatus.h:
         (GetByIdStatus):
         * bytecode/Instruction.h:
         (JSC::Instruction::Instruction):
         * bytecode/ObjectAllocationProfile.h:
         (JSC::ObjectAllocationProfile::initialize):
         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
         * bytecode/PolymorphicAccessStructureList.h:
         (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set):
         (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList):
         * bytecode/PolymorphicPutByIdList.h:
         (JSC::PutByIdAccess::transition):
         (JSC::PutByIdAccess::replace):
         * bytecode/PreciseJumpTargets.cpp:
         (JSC::computePreciseJumpTargets):
         * bytecode/PutByIdStatus.cpp:
         (JSC::PutByIdStatus::computeFromLLInt):
         (JSC::PutByIdStatus::computeFor):
         * bytecode/PutByIdStatus.h:
         (JSC):
         (PutByIdStatus):
         * bytecode/ResolveGlobalStatus.cpp:
         (JSC::computeForStructure):
         * bytecode/SamplingTool.cpp:
         (JSC::SamplingTool::notifyOfScope):
         * bytecode/SamplingTool.h:
         (JSC::ScriptSampleRecord::ScriptSampleRecord):
         (SamplingTool):
         * bytecode/StructureStubInfo.h:
         (JSC::StructureStubInfo::initGetByIdSelf):
         (JSC::StructureStubInfo::initGetByIdProto):
         (JSC::StructureStubInfo::initGetByIdChain):
         (JSC::StructureStubInfo::initPutByIdTransition):
         (JSC::StructureStubInfo::initPutByIdReplace):
         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::generateFunctionCodeBlock):
         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
         (JSC::UnlinkedFunctionExecutable::link):
         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
         * bytecode/UnlinkedCodeBlock.h:
         (JSC::UnlinkedFunctionExecutable::create):
         (UnlinkedFunctionExecutable):
         (JSC::UnlinkedFunctionExecutable::finishCreation):
         (JSC::UnlinkedFunctionExecutable::createStructure):
         (JSC::UnlinkedCodeBlock::addRegExp):
         (JSC::UnlinkedCodeBlock::addConstant):
         (JSC::UnlinkedCodeBlock::addFunctionDecl):
         (JSC::UnlinkedCodeBlock::addFunctionExpr):
         (JSC::UnlinkedCodeBlock::vm):
         (UnlinkedCodeBlock):
         (JSC::UnlinkedCodeBlock::finishCreation):
         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
         (JSC::UnlinkedProgramCodeBlock::create):
         (JSC::UnlinkedProgramCodeBlock::addFunctionDeclaration):
         (JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
         (JSC::UnlinkedProgramCodeBlock::createStructure):
         (JSC::UnlinkedEvalCodeBlock::create):
         (JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
         (JSC::UnlinkedEvalCodeBlock::createStructure):
         (JSC::UnlinkedFunctionCodeBlock::create):
         (JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
         (JSC::UnlinkedFunctionCodeBlock::createStructure):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::BytecodeGenerator):
         (JSC::BytecodeGenerator::addConstant):
         (JSC::BytecodeGenerator::emitLoad):
         (JSC::BytecodeGenerator::emitDirectPutById):
         (JSC::BytecodeGenerator::addStringConstant):
         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
         (JSC::BytecodeGenerator::emitThrowReferenceError):
         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
         * bytecompiler/BytecodeGenerator.h:
         (BytecodeGenerator):
         (JSC::BytecodeGenerator::vm):
         (JSC::BytecodeGenerator::propertyNames):
         (JSC::BytecodeGenerator::makeFunction):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::RegExpNode::emitBytecode):
         (JSC::ArrayNode::toArgumentList):
         (JSC::ApplyFunctionCallDotNode::emitBytecode):
         (JSC::InstanceOfNode::emitBytecode):
         * debugger/Debugger.cpp:
         (JSC::Debugger::recompileAllJSFunctions):
         (JSC::evaluateInGlobalCallFrame):
         * debugger/Debugger.h:
         (JSC):
         * debugger/DebuggerActivation.cpp:
         (JSC::DebuggerActivation::DebuggerActivation):
         (JSC::DebuggerActivation::finishCreation):
         * debugger/DebuggerActivation.h:
         (JSC::DebuggerActivation::create):
         (JSC::DebuggerActivation::createStructure):
         (DebuggerActivation):
         * debugger/DebuggerCallFrame.cpp:
         (JSC::DebuggerCallFrame::evaluate):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGAssemblyHelpers.h:
         (JSC::DFG::AssemblyHelpers::AssemblyHelpers):
         (JSC::DFG::AssemblyHelpers::vm):
         (JSC::DFG::AssemblyHelpers::debugCall):
         (JSC::DFG::AssemblyHelpers::emitExceptionCheck):
         (AssemblyHelpers):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::ByteCodeParser):
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
         (JSC::DFG::ByteCodeParser::parseBlock):
         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * dfg/DFGByteCodeParser.h:
         (JSC):
         * dfg/DFGCCallHelpers.h:
         (JSC::DFG::CCallHelpers::CCallHelpers):
         * dfg/DFGCapabilities.cpp:
         (JSC::DFG::canHandleOpcodes):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::reportToProfiler):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGDriver.h:
         (JSC):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::Graph):
         * dfg/DFGGraph.h:
         (Graph):
         * dfg/DFGJITCompiler.cpp:
         (JSC::DFG::JITCompiler::JITCompiler):
         (JSC::DFG::JITCompiler::linkOSRExits):
         (JSC::DFG::JITCompiler::link):
         (JSC::DFG::JITCompiler::compile):
         (JSC::DFG::JITCompiler::compileFunction):
         * dfg/DFGJITCompiler.h:
         (JSC):
         * dfg/DFGOSREntry.cpp:
         (JSC::DFG::prepareOSREntry):
         * dfg/DFGOSRExitCompiler.cpp:
         * dfg/DFGOSRExitCompiler32_64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOSRExitCompiler64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOperations.cpp:
         (JSC::DFG::putByVal):
         (JSC::DFG::operationPutByValInternal):
         (JSC::getHostCallReturnValueWithExecState):
         * dfg/DFGPhase.h:
         (JSC::DFG::Phase::vm):
         * dfg/DFGRepatch.cpp:
         (JSC::DFG::generateProtoChainAccessStub):
         (JSC::DFG::tryCacheGetByID):
         (JSC::DFG::tryBuildGetByIDList):
         (JSC::DFG::tryBuildGetByIDProtoList):
         (JSC::DFG::emitPutReplaceStub):
         (JSC::DFG::emitPutTransitionStub):
         (JSC::DFG::tryCachePutByID):
         (JSC::DFG::tryBuildPutByIdList):
         (JSC::DFG::linkSlowFor):
         (JSC::DFG::dfgLinkFor):
         (JSC::DFG::dfgLinkSlowFor):
         (JSC::DFG::dfgLinkClosureCall):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::typedArrayDescriptor):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
         (JSC::DFG::SpeculativeJIT::compileMakeRope):
         (JSC::DFG::SpeculativeJIT::compileStringEquality):
         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
         (JSC::DFG::SpeculativeJIT::speculateObject):
         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
         (JSC::DFG::SpeculativeJIT::speculateString):
         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::prepareForExternalCall):
         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage):
         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (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::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGThunks.cpp:
         (JSC::DFG::osrExitGenerationThunkGenerator):
         (JSC::DFG::throwExceptionFromCallSlowPathGenerator):
         (JSC::DFG::slowPathFor):
         (JSC::DFG::linkForThunkGenerator):
         (JSC::DFG::linkCallThunkGenerator):
         (JSC::DFG::linkConstructThunkGenerator):
         (JSC::DFG::linkClosureCallThunkGenerator):
         (JSC::DFG::virtualForThunkGenerator):
         (JSC::DFG::virtualCallThunkGenerator):
         (JSC::DFG::virtualConstructThunkGenerator):
         * dfg/DFGThunks.h:
         (JSC):
         (DFG):
         * heap/BlockAllocator.h:
         (JSC):
         * heap/CopiedSpace.cpp:
         (JSC::CopiedSpace::tryAllocateSlowCase):
         (JSC::CopiedSpace::tryReallocate):
         * heap/CopiedSpaceInlines.h:
         (JSC::CopiedSpace::tryAllocate):
         * heap/GCThreadSharedData.cpp:
         (JSC::GCThreadSharedData::GCThreadSharedData):
         (JSC::GCThreadSharedData::reset):
         * heap/GCThreadSharedData.h:
         (JSC):
         (GCThreadSharedData):
         * heap/HandleSet.cpp:
         (JSC::HandleSet::HandleSet):
         (JSC::HandleSet::~HandleSet):
         (JSC::HandleSet::grow):
         * heap/HandleSet.h:
         (JSC):
         (HandleSet):
         (JSC::HandleSet::vm):
         * heap/Heap.cpp:
         (JSC::Heap::Heap):
         (JSC):
         (JSC::Heap::lastChanceToFinalize):
         (JSC::Heap::protect):
         (JSC::Heap::unprotect):
         (JSC::Heap::stack):
         (JSC::Heap::getConservativeRegisterRoots):
         (JSC::Heap::markRoots):
         (JSC::Heap::deleteAllCompiledCode):
         (JSC::Heap::collect):
         (JSC::Heap::isValidAllocation):
         * heap/Heap.h:
         (JSC):
         (Heap):
         (JSC::Heap::vm):
         * heap/HeapTimer.cpp:
         (JSC::HeapTimer::HeapTimer):
         (JSC::HeapTimer::timerDidFire):
         (JSC::HeapTimer::timerEvent):
         * heap/HeapTimer.h:
         (JSC):
         (HeapTimer):
         * heap/IncrementalSweeper.cpp:
         (JSC::IncrementalSweeper::IncrementalSweeper):
         (JSC::IncrementalSweeper::sweepNextBlock):
         (JSC::IncrementalSweeper::willFinishSweeping):
         (JSC::IncrementalSweeper::create):
         * heap/IncrementalSweeper.h:
         (IncrementalSweeper):
         * heap/Local.h:
         (Local):
         (JSC::::Local):
         (JSC::LocalStack::LocalStack):
         (JSC::LocalStack::push):
         (LocalStack):
         * heap/LocalScope.h:
         (JSC):
         (LocalScope):
         (JSC::LocalScope::LocalScope):
         * heap/MachineStackMarker.cpp:
         (JSC::MachineThreads::addCurrentThread):
         * heap/MarkedAllocator.cpp:
         (JSC::MarkedAllocator::allocateSlowCase):
         * heap/MarkedBlock.cpp:
         (JSC::MarkedBlock::MarkedBlock):
         * heap/MarkedBlock.h:
         (JSC::MarkedBlock::vm):
         * heap/SlotVisitor.cpp:
         (JSC::SlotVisitor::SlotVisitor):
         (JSC::SlotVisitor::setup):
         * heap/Strong.h:
         (JSC):
         (Strong):
         (JSC::Strong::operator=):
         * heap/StrongInlines.h:
         (JSC::::Strong):
         (JSC::::set):
         * heap/SuperRegion.h:
         (JSC):
         * heap/WeakSet.cpp:
         * heap/WeakSet.h:
         (WeakSet):
         (JSC::WeakSet::WeakSet):
         (JSC::WeakSet::vm):
         * interpreter/AbstractPC.cpp:
         (JSC::AbstractPC::AbstractPC):
         * interpreter/AbstractPC.h:
         (JSC):
         (AbstractPC):
         * interpreter/CachedCall.h:
         (JSC::CachedCall::CachedCall):
         * interpreter/CallFrame.h:
         (ExecState):
         (JSC::ExecState::clearException):
         (JSC::ExecState::clearSupplementaryExceptionInfo):
         (JSC::ExecState::exception):
         (JSC::ExecState::hadException):
         (JSC::ExecState::propertyNames):
         (JSC::ExecState::emptyList):
         (JSC::ExecState::interpreter):
         (JSC::ExecState::heap):
         (JSC::ExecState::arrayConstructorTable):
         (JSC::ExecState::arrayPrototypeTable):
         (JSC::ExecState::booleanPrototypeTable):
         (JSC::ExecState::dateTable):
         (JSC::ExecState::dateConstructorTable):
         (JSC::ExecState::errorPrototypeTable):
         (JSC::ExecState::globalObjectTable):
         (JSC::ExecState::jsonTable):
         (JSC::ExecState::mathTable):
         (JSC::ExecState::numberConstructorTable):
         (JSC::ExecState::numberPrototypeTable):
         (JSC::ExecState::objectConstructorTable):
         (JSC::ExecState::privateNamePrototypeTable):
         (JSC::ExecState::regExpTable):
         (JSC::ExecState::regExpConstructorTable):
         (JSC::ExecState::regExpPrototypeTable):
         (JSC::ExecState::stringConstructorTable):
         (JSC::ExecState::abstractReturnPC):
         * interpreter/CallFrameClosure.h:
         (CallFrameClosure):
         * interpreter/Interpreter.cpp:
         (JSC):
         (JSC::eval):
         (JSC::loadVarargs):
         (JSC::Interpreter::Interpreter):
         (JSC::Interpreter::dumpRegisters):
         (JSC::Interpreter::unwindCallFrame):
         (JSC::appendSourceToError):
         (JSC::getCallerInfo):
         (JSC::Interpreter::getStackTrace):
         (JSC::Interpreter::addStackTraceIfNecessary):
         (JSC::Interpreter::throwException):
         (JSC::Interpreter::execute):
         (JSC::Interpreter::executeCall):
         (JSC::Interpreter::executeConstruct):
         (JSC::Interpreter::prepareForRepeatCall):
         (JSC::Interpreter::retrieveArgumentsFromVMCode):
         (JSC::Interpreter::retrieveCallerFromVMCode):
         * interpreter/Interpreter.h:
         (JSC):
         (JSC::TopCallFrameSetter::TopCallFrameSetter):
         (JSC::TopCallFrameSetter::~TopCallFrameSetter):
         (TopCallFrameSetter):
         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
         (Interpreter):
         * interpreter/JSStack.cpp:
         (JSC::JSStack::JSStack):
         * interpreter/JSStack.h:
         (JSC):
         * jit/ClosureCallStubRoutine.cpp:
         (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine):
         * jit/ClosureCallStubRoutine.h:
         (ClosureCallStubRoutine):
         * jit/ExecutableAllocator.cpp:
         (JSC::ExecutableAllocator::ExecutableAllocator):
         (JSC::ExecutableAllocator::allocate):
         * jit/ExecutableAllocator.h:
         (JSC):
         (ExecutableAllocator):
         * jit/ExecutableAllocatorFixedVMPool.cpp:
         (JSC::ExecutableAllocator::ExecutableAllocator):
         (JSC::ExecutableAllocator::allocate):
         * jit/GCAwareJITStubRoutine.cpp:
         (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject):
         (JSC::createJITStubRoutine):
         * jit/GCAwareJITStubRoutine.h:
         (GCAwareJITStubRoutine):
         (MarkingGCAwareJITStubRoutineWithOneObject):
         (JSC):
         * jit/JIT.cpp:
         (JSC::JIT::JIT):
         (JSC::JIT::privateCompile):
         (JSC::JIT::linkFor):
         (JSC::JIT::linkSlowCall):
         * jit/JIT.h:
         (JSC::JIT::compile):
         (JSC::JIT::compileClosureCall):
         (JSC::JIT::compileGetByIdProto):
         (JSC::JIT::compileGetByIdSelfList):
         (JSC::JIT::compileGetByIdProtoList):
         (JSC::JIT::compileGetByIdChainList):
         (JSC::JIT::compileGetByIdChain):
         (JSC::JIT::compilePutByIdTransition):
         (JSC::JIT::compileGetByVal):
         (JSC::JIT::compilePutByVal):
         (JSC::JIT::compileCTINativeCall):
         (JSC::JIT::compilePatchGetArrayLength):
         (JIT):
         * jit/JITCall.cpp:
         (JSC::JIT::compileLoadVarargs):
         (JSC::JIT::compileCallEvalSlowCase):
         (JSC::JIT::compileOpCallSlowCase):
         (JSC::JIT::privateCompileClosureCall):
         * jit/JITCall32_64.cpp:
         (JSC::JIT::compileLoadVarargs):
         (JSC::JIT::compileCallEvalSlowCase):
         (JSC::JIT::compileOpCallSlowCase):
         (JSC::JIT::privateCompileClosureCall):
         * jit/JITCode.h:
         (JSC):
         (JSC::JITCode::execute):
         * jit/JITDriver.h:
         (JSC::jitCompileIfAppropriate):
         (JSC::jitCompileFunctionIfAppropriate):
         * jit/JITExceptions.cpp:
         (JSC::genericThrow):
         (JSC::jitThrow):
         * jit/JITExceptions.h:
         (JSC):
         * jit/JITInlines.h:
         (JSC::JIT::emitLoadCharacterString):
         (JSC::JIT::updateTopCallFrame):
         * jit/JITOpcodes.cpp:
         (JSC::JIT::privateCompileCTINativeCall):
         (JSC::JIT::emit_op_new_object):
         (JSC::JIT::emit_op_to_primitive):
         (JSC::JIT::emit_op_catch):
         (JSC::JIT::emit_op_convert_this):
         (JSC::JIT::emitSlow_op_convert_this):
         * jit/JITOpcodes32_64.cpp:
         (JSC::JIT::privateCompileCTINativeCall):
         (JSC::JIT::emit_op_new_object):
         (JSC::JIT::emit_op_to_primitive):
         (JSC::JIT::emitSlow_op_eq):
         (JSC::JIT::emitSlow_op_neq):
         (JSC::JIT::compileOpStrictEq):
         (JSC::JIT::emit_op_catch):
         (JSC::JIT::emit_op_convert_this):
         (JSC::JIT::emitSlow_op_convert_this):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::stringGetByValStubGenerator):
         (JSC::JIT::emitSlow_op_get_by_val):
         (JSC::JIT::compileGetByIdHotPath):
         (JSC::JIT::privateCompilePutByIdTransition):
         (JSC::JIT::privateCompilePatchGetArrayLength):
         (JSC::JIT::privateCompileGetByIdProto):
         (JSC::JIT::privateCompileGetByIdSelfList):
         (JSC::JIT::privateCompileGetByIdProtoList):
         (JSC::JIT::privateCompileGetByIdChainList):
         (JSC::JIT::privateCompileGetByIdChain):
         (JSC::JIT::privateCompileGetByVal):
         (JSC::JIT::privateCompilePutByVal):
         * jit/JITPropertyAccess32_64.cpp:
         (JSC::JIT::stringGetByValStubGenerator):
         (JSC::JIT::emitSlow_op_get_by_val):
         (JSC::JIT::compileGetByIdHotPath):
         (JSC::JIT::privateCompilePutByIdTransition):
         (JSC::JIT::privateCompilePatchGetArrayLength):
         (JSC::JIT::privateCompileGetByIdProto):
         (JSC::JIT::privateCompileGetByIdSelfList):
         (JSC::JIT::privateCompileGetByIdProtoList):
         (JSC::JIT::privateCompileGetByIdChainList):
         (JSC::JIT::privateCompileGetByIdChain):
         * jit/JITStubs.cpp:
         (JSC::ctiTrampoline):
         (JSC):
         (JSC::performPlatformSpecificJITAssertions):
         (JSC::tryCachePutByID):
         (JSC::tryCacheGetByID):
         (JSC::returnToThrowTrampoline):
         (JSC::throwExceptionFromOpCall):
         (JSC::DEFINE_STUB_FUNCTION):
         (JSC::getPolymorphicAccessStructureListSlot):
         (JSC::jitCompileFor):
         (JSC::lazyLinkFor):
         (JSC::putByVal):
         * jit/JITStubs.h:
         (JSC):
         (JITStackFrame):
         * jit/JITThunks.cpp:
         (JSC::JITThunks::ctiNativeCall):
         (JSC::JITThunks::ctiNativeConstruct):
         (JSC::JITThunks::ctiStub):
         (JSC::JITThunks::hostFunctionStub):
         * jit/JITThunks.h:
         (JSC):
         (JITThunks):
         * jit/JITWriteBarrier.h:
         (JSC):
         (JSC::JITWriteBarrierBase::set):
         (JSC::JITWriteBarrier::set):
         * jit/SpecializedThunkJIT.h:
         (JSC::SpecializedThunkJIT::loadJSStringArgument):
         (JSC::SpecializedThunkJIT::finalize):
         * jit/ThunkGenerator.h:
         (JSC):
         * jit/ThunkGenerators.cpp:
         (JSC::generateSlowCaseFor):
         (JSC::linkForGenerator):
         (JSC::linkCallGenerator):
         (JSC::linkConstructGenerator):
         (JSC::linkClosureCallGenerator):
         (JSC::virtualForGenerator):
         (JSC::virtualCallGenerator):
         (JSC::virtualConstructGenerator):
         (JSC::stringLengthTrampolineGenerator):
         (JSC::nativeForGenerator):
         (JSC::nativeCallGenerator):
         (JSC::nativeConstructGenerator):
         (JSC::stringCharLoad):
         (JSC::charToString):
         (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):
         * jsc.cpp:
         (GlobalObject):
         (GlobalObject::create):
         (GlobalObject::createStructure):
         (GlobalObject::finishCreation):
         (GlobalObject::addFunction):
         (GlobalObject::addConstructableFunction):
         (functionDumpCallFrame):
         (functionJSCStack):
         (functionReleaseExecutableMemory):
         (functionRun):
         (main):
         (runWithScripts):
         (jscmain):
         * llint/LLIntData.cpp:
         (JSC::LLInt::Data::performAssertions):
         * llint/LLIntData.h:
         (JSC):
         (Data):
         (JSC::LLInt::Data::performAssertions):
         * llint/LLIntEntrypoints.cpp:
         (JSC::LLInt::getFunctionEntrypoint):
         (JSC::LLInt::getEvalEntrypoint):
         (JSC::LLInt::getProgramEntrypoint):
         * llint/LLIntEntrypoints.h:
         (JSC):
         (LLInt):
         (JSC::LLInt::getEntrypoint):
         * llint/LLIntExceptions.cpp:
         (JSC::LLInt::interpreterThrowInCaller):
         (JSC::LLInt::returnToThrow):
         (JSC::LLInt::callToThrow):
         * llint/LLIntOffsetsExtractor.cpp:
         * llint/LLIntSlowPaths.cpp:
         (LLInt):
         (JSC::LLInt::llint_trace_operand):
         (JSC::LLInt::llint_trace_value):
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         (JSC::LLInt::shouldJIT):
         (JSC::LLInt::handleHostCall):
         (JSC::LLInt::setUpCall):
         * llint/LLIntThunks.cpp:
         (JSC::LLInt::generateThunkWithJumpTo):
         (JSC::LLInt::functionForCallEntryThunkGenerator):
         (JSC::LLInt::functionForConstructEntryThunkGenerator):
         (JSC::LLInt::functionForCallArityCheckThunkGenerator):
         (JSC::LLInt::functionForConstructArityCheckThunkGenerator):
         (JSC::LLInt::evalEntryThunkGenerator):
         (JSC::LLInt::programEntryThunkGenerator):
         * llint/LLIntThunks.h:
         (JSC):
         (LLInt):
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter.cpp:
         (JSC::CLoop::execute):
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:
         * offlineasm/cloop.rb:
         * parser/ASTBuilder.h:
         (JSC::ASTBuilder::ASTBuilder):
         (JSC::ASTBuilder::createSourceElements):
         (JSC::ASTBuilder::createCommaExpr):
         (JSC::ASTBuilder::createLogicalNot):
         (JSC::ASTBuilder::createUnaryPlus):
         (JSC::ASTBuilder::createVoid):
         (JSC::ASTBuilder::thisExpr):
         (JSC::ASTBuilder::createResolve):
         (JSC::ASTBuilder::createObjectLiteral):
         (JSC::ASTBuilder::createArray):
         (JSC::ASTBuilder::createNumberExpr):
         (JSC::ASTBuilder::createString):
         (JSC::ASTBuilder::createBoolean):
         (JSC::ASTBuilder::createNull):
         (JSC::ASTBuilder::createBracketAccess):
         (JSC::ASTBuilder::createDotAccess):
         (JSC::ASTBuilder::createRegExp):
         (JSC::ASTBuilder::createNewExpr):
         (JSC::ASTBuilder::createConditionalExpr):
         (JSC::ASTBuilder::createAssignResolve):
         (JSC::ASTBuilder::createFunctionExpr):
         (JSC::ASTBuilder::createFunctionBody):
         (JSC::ASTBuilder::createGetterOrSetterProperty):
         (JSC::ASTBuilder::createArguments):
         (JSC::ASTBuilder::createArgumentsList):
         (JSC::ASTBuilder::createProperty):
         (JSC::ASTBuilder::createPropertyList):
         (JSC::ASTBuilder::createElementList):
         (JSC::ASTBuilder::createFormalParameterList):
         (JSC::ASTBuilder::createClause):
         (JSC::ASTBuilder::createClauseList):
         (JSC::ASTBuilder::createFuncDeclStatement):
         (JSC::ASTBuilder::createBlockStatement):
         (JSC::ASTBuilder::createExprStatement):
         (JSC::ASTBuilder::createIfStatement):
         (JSC::ASTBuilder::createForLoop):
         (JSC::ASTBuilder::createForInLoop):
         (JSC::ASTBuilder::createEmptyStatement):
         (JSC::ASTBuilder::createVarStatement):
         (JSC::ASTBuilder::createReturnStatement):
         (JSC::ASTBuilder::createBreakStatement):
         (JSC::ASTBuilder::createContinueStatement):
         (JSC::ASTBuilder::createTryStatement):
         (JSC::ASTBuilder::createSwitchStatement):
         (JSC::ASTBuilder::createWhileStatement):
         (JSC::ASTBuilder::createDoWhileStatement):
         (JSC::ASTBuilder::createLabelStatement):
         (JSC::ASTBuilder::createWithStatement):
         (JSC::ASTBuilder::createThrowStatement):
         (JSC::ASTBuilder::createDebugger):
         (JSC::ASTBuilder::createConstStatement):
         (JSC::ASTBuilder::appendConstDecl):
         (JSC::ASTBuilder::addVar):
         (JSC::ASTBuilder::combineCommaNodes):
         (JSC::ASTBuilder::Scope::Scope):
         (JSC::ASTBuilder::createNumber):
         (ASTBuilder):
         (JSC::ASTBuilder::makeTypeOfNode):
         (JSC::ASTBuilder::makeDeleteNode):
         (JSC::ASTBuilder::makeNegateNode):
         (JSC::ASTBuilder::makeBitwiseNotNode):
         (JSC::ASTBuilder::makeMultNode):
         (JSC::ASTBuilder::makeDivNode):
         (JSC::ASTBuilder::makeModNode):
         (JSC::ASTBuilder::makeAddNode):
         (JSC::ASTBuilder::makeSubNode):
         (JSC::ASTBuilder::makeLeftShiftNode):
         (JSC::ASTBuilder::makeRightShiftNode):
         (JSC::ASTBuilder::makeURightShiftNode):
         (JSC::ASTBuilder::makeBitOrNode):
         (JSC::ASTBuilder::makeBitAndNode):
         (JSC::ASTBuilder::makeBitXOrNode):
         (JSC::ASTBuilder::makeFunctionCallNode):
         (JSC::ASTBuilder::makeBinaryNode):
         (JSC::ASTBuilder::makeAssignNode):
         (JSC::ASTBuilder::makePrefixNode):
         (JSC::ASTBuilder::makePostfixNode):
         * parser/Lexer.cpp:
         (JSC::Keywords::Keywords):
         (JSC::::Lexer):
         (JSC::::parseIdentifier):
         (JSC::::parseIdentifierSlowCase):
         * parser/Lexer.h:
         (JSC::Keywords::isKeyword):
         (JSC::Keywords::getKeyword):
         (Keywords):
         (Lexer):
         (JSC::::makeIdentifier):
         (JSC::::makeRightSizedIdentifier):
         (JSC::::makeIdentifierLCharFromUChar):
         (JSC::::makeLCharIdentifier):
         * parser/NodeConstructors.h:
         (JSC::ParserArenaFreeable::operator new):
         (JSC::ParserArenaDeletable::operator new):
         (JSC::ParserArenaRefCounted::ParserArenaRefCounted):
         (JSC::PropertyNode::PropertyNode):
         (JSC::ContinueNode::ContinueNode):
         (JSC::BreakNode::BreakNode):
         (JSC::ForInNode::ForInNode):
         * parser/Nodes.cpp:
         (JSC::ScopeNode::ScopeNode):
         (JSC::ProgramNode::ProgramNode):
         (JSC::ProgramNode::create):
         (JSC::EvalNode::EvalNode):
         (JSC::EvalNode::create):
         (JSC::FunctionBodyNode::FunctionBodyNode):
         (JSC::FunctionBodyNode::create):
         * parser/Nodes.h:
         (ParserArenaFreeable):
         (ParserArenaDeletable):
         (ParserArenaRefCounted):
         (ArrayNode):
         (ForInNode):
         (ContinueNode):
         (BreakNode):
         (ScopeNode):
         (ProgramNode):
         (EvalNode):
         (FunctionBodyNode):
         * parser/Parser.cpp:
         (JSC::::Parser):
         (JSC::::parseInner):
         (JSC::::parseSourceElements):
         (JSC::::parseTryStatement):
         (JSC::::parseFunctionBody):
         (JSC::::parseFunctionInfo):
         (JSC::::parseAssignmentExpression):
         (JSC::::parseProperty):
         (JSC::::parsePrimaryExpression):
         (JSC::::parseMemberExpression):
         (JSC::::parseUnaryExpression):
         * parser/Parser.h:
         (JSC):
         (JSC::Scope::Scope):
         (JSC::Scope::declareVariable):
         (JSC::Scope::declareParameter):
         (Scope):
         (Parser):
         (JSC::Parser::pushScope):
         (JSC::::parse):
         (JSC::parse):
         * parser/ParserArena.h:
         (IdentifierArena):
         (JSC::IdentifierArena::makeIdentifier):
         (JSC::IdentifierArena::makeIdentifierLCharFromUChar):
         (JSC::IdentifierArena::makeNumericIdentifier):
         * parser/SyntaxChecker.h:
         (JSC::SyntaxChecker::SyntaxChecker):
         (JSC::SyntaxChecker::createProperty):
         (JSC::SyntaxChecker::createGetterOrSetterProperty):
         * profiler/LegacyProfiler.cpp:
         (JSC::LegacyProfiler::startProfiling):
         (JSC::LegacyProfiler::stopProfiling):
         * profiler/LegacyProfiler.h:
         (JSC):
         * profiler/ProfilerBytecode.cpp:
         (JSC::Profiler::Bytecode::toJS):
         * profiler/ProfilerBytecodeSequence.cpp:
         (JSC::Profiler::BytecodeSequence::BytecodeSequence):
         (JSC::Profiler::BytecodeSequence::addSequenceProperties):
         * profiler/ProfilerBytecodes.cpp:
         (JSC::Profiler::Bytecodes::toJS):
         * profiler/ProfilerCompilation.cpp:
         (JSC::Profiler::Compilation::toJS):
         * profiler/ProfilerCompiledBytecode.cpp:
         (JSC::Profiler::CompiledBytecode::toJS):
         * profiler/ProfilerDatabase.cpp:
         (JSC::Profiler::Database::Database):
         (JSC::Profiler::Database::toJS):
         (JSC::Profiler::Database::toJSON):
         * profiler/ProfilerDatabase.h:
         (Database):
         * profiler/ProfilerOSRExit.cpp:
         (JSC::Profiler::OSRExit::toJS):
         * profiler/ProfilerOrigin.cpp:
         (JSC::Profiler::Origin::toJS):
         * profiler/ProfilerProfiledBytecodes.cpp:
         (JSC::Profiler::ProfiledBytecodes::toJS):
         * runtime/ArgList.h:
         (MarkedArgumentBuffer):
         * runtime/Arguments.cpp:
         (JSC::Arguments::putByIndex):
         (JSC::Arguments::put):
         (JSC::Arguments::deleteProperty):
         (JSC::Arguments::defineOwnProperty):
         (JSC::Arguments::tearOff):
         (JSC::Arguments::didTearOffActivation):
         (JSC::Arguments::tearOffForInlineCallFrame):
         * runtime/Arguments.h:
         (JSC::Arguments::create):
         (JSC::Arguments::createStructure):
         (Arguments):
         (JSC::Arguments::Arguments):
         (JSC::Arguments::trySetArgument):
         (JSC::Arguments::finishCreation):
         * runtime/ArrayConstructor.cpp:
         (JSC::ArrayConstructor::finishCreation):
         * runtime/ArrayConstructor.h:
         (JSC::ArrayConstructor::createStructure):
         * runtime/ArrayPrototype.cpp:
         (JSC::ArrayPrototype::ArrayPrototype):
         (JSC::ArrayPrototype::finishCreation):
         (JSC::arrayProtoFuncSort):
         (JSC::arrayProtoFuncSplice):
         * runtime/ArrayPrototype.h:
         (JSC::ArrayPrototype::createStructure):
         * runtime/BatchedTransitionOptimizer.h:
         (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer):
         (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer):
         (BatchedTransitionOptimizer):
         * runtime/BooleanConstructor.cpp:
         (JSC::BooleanConstructor::finishCreation):
         (JSC::constructBoolean):
         (JSC::constructBooleanFromImmediateBoolean):
         * runtime/BooleanConstructor.h:
         (JSC::BooleanConstructor::createStructure):
         * runtime/BooleanObject.cpp:
         (JSC::BooleanObject::BooleanObject):
         (JSC::BooleanObject::finishCreation):
         * runtime/BooleanObject.h:
         (BooleanObject):
         (JSC::BooleanObject::create):
         (JSC::BooleanObject::createStructure):
         * runtime/BooleanPrototype.cpp:
         (JSC::BooleanPrototype::BooleanPrototype):
         (JSC::BooleanPrototype::finishCreation):
         (JSC::booleanProtoFuncToString):
         * runtime/BooleanPrototype.h:
         (JSC::BooleanPrototype::createStructure):
         * runtime/Butterfly.h:
         (JSC):
         (Butterfly):
         * runtime/ButterflyInlines.h:
         (JSC::Butterfly::createUninitialized):
         (JSC::Butterfly::create):
         (JSC::Butterfly::growPropertyStorage):
         (JSC::Butterfly::createOrGrowArrayRight):
         (JSC::Butterfly::growArrayRight):
         (JSC::Butterfly::resizeArray):
         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getCodeBlock):
         (JSC::CodeCache::getProgramCodeBlock):
         (JSC::CodeCache::getEvalCodeBlock):
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         * runtime/CodeCache.h:
         (JSC):
         (JSC::SourceCodeValue::SourceCodeValue):
         (CodeCache):
         * runtime/CommonIdentifiers.cpp:
         (JSC):
         (JSC::CommonIdentifiers::CommonIdentifiers):
         * runtime/CommonIdentifiers.h:
         (CommonIdentifiers):
         * runtime/CommonSlowPaths.h:
         (JSC::CommonSlowPaths::opIn):
         * runtime/Completion.cpp:
         (JSC::checkSyntax):
         (JSC::evaluate):
         * runtime/DateConstructor.cpp:
         (JSC::DateConstructor::finishCreation):
         * runtime/DateConstructor.h:
         (JSC::DateConstructor::createStructure):
         * runtime/DateInstance.cpp:
         (JSC::DateInstance::DateInstance):
         (JSC::DateInstance::finishCreation):
         (JSC::DateInstance::calculateGregorianDateTime):
         (JSC::DateInstance::calculateGregorianDateTimeUTC):
         * runtime/DateInstance.h:
         (DateInstance):
         (JSC::DateInstance::create):
         (JSC::DateInstance::createStructure):
         * runtime/DatePrototype.cpp:
         (JSC::DatePrototype::finishCreation):
         (JSC::dateProtoFuncSetTime):
         (JSC::setNewValueFromTimeArgs):
         (JSC::setNewValueFromDateArgs):
         (JSC::dateProtoFuncSetYear):
         (JSC::dateProtoFuncToJSON):
         * runtime/DatePrototype.h:
         (JSC::DatePrototype::createStructure):
         * runtime/Error.cpp:
         (JSC::createError):
         (JSC::createEvalError):
         (JSC::createRangeError):
         (JSC::createReferenceError):
         (JSC::createSyntaxError):
         (JSC::createTypeError):
         (JSC::createURIError):
         (JSC::addErrorInfo):
         (JSC::throwError):
         * runtime/Error.h:
         (JSC):
         (JSC::StrictModeTypeErrorFunction::create):
         (JSC::StrictModeTypeErrorFunction::createStructure):
         * runtime/ErrorConstructor.cpp:
         (JSC::ErrorConstructor::finishCreation):
         * runtime/ErrorConstructor.h:
         (JSC::ErrorConstructor::createStructure):
         * runtime/ErrorInstance.cpp:
         (JSC::ErrorInstance::ErrorInstance):
         * runtime/ErrorInstance.h:
         (JSC::ErrorInstance::createStructure):
         (JSC::ErrorInstance::create):
         (ErrorInstance):
         (JSC::ErrorInstance::finishCreation):
         * runtime/ErrorPrototype.cpp:
         (JSC::ErrorPrototype::ErrorPrototype):
         (JSC::ErrorPrototype::finishCreation):
         * runtime/ErrorPrototype.h:
         (JSC::ErrorPrototype::createStructure):
         * runtime/ExceptionHelpers.cpp:
         (JSC::createInterruptedExecutionException):
         (JSC::createTerminatedExecutionException):
         * runtime/ExceptionHelpers.h:
         (JSC):
         (JSC::InterruptedExecutionError::InterruptedExecutionError):
         (JSC::InterruptedExecutionError::create):
         (JSC::InterruptedExecutionError::createStructure):
         (JSC::TerminatedExecutionError::TerminatedExecutionError):
         (JSC::TerminatedExecutionError::create):
         (JSC::TerminatedExecutionError::createStructure):
         * runtime/Executable.cpp:
         (JSC::jettisonCodeBlock):
         (JSC::EvalExecutable::EvalExecutable):
         (JSC::ProgramExecutable::ProgramExecutable):
         (JSC::FunctionExecutable::FunctionExecutable):
         (JSC::EvalExecutable::compileOptimized):
         (JSC::EvalExecutable::compileInternal):
         (JSC::EvalExecutable::jettisonOptimizedCode):
         (JSC::ProgramExecutable::checkSyntax):
         (JSC::ProgramExecutable::compileOptimized):
         (JSC::ProgramExecutable::jettisonOptimizedCode):
         (JSC::ProgramExecutable::initializeGlobalProperties):
         (JSC::FunctionExecutable::compileOptimizedForCall):
         (JSC::FunctionExecutable::compileOptimizedForConstruct):
         (JSC::FunctionExecutable::produceCodeBlockFor):
         (JSC::FunctionExecutable::jettisonOptimizedCodeForCall):
         (JSC::FunctionExecutable::jettisonOptimizedCodeForConstruct):
         (JSC::FunctionExecutable::fromGlobalCode):
         * runtime/Executable.h:
         (JSC::ExecutableBase::ExecutableBase):
         (JSC::ExecutableBase::finishCreation):
         (JSC::ExecutableBase::createStructure):
         (JSC::NativeExecutable::create):
         (JSC::NativeExecutable::createStructure):
         (JSC::NativeExecutable::finishCreation):
         (JSC::NativeExecutable::NativeExecutable):
         (JSC::ScriptExecutable::ScriptExecutable):
         (JSC::ScriptExecutable::finishCreation):
         (JSC::EvalExecutable::compile):
         (EvalExecutable):
         (JSC::EvalExecutable::create):
         (JSC::EvalExecutable::createStructure):
         (JSC::ProgramExecutable::create):
         (ProgramExecutable):
         (JSC::ProgramExecutable::compile):
         (JSC::ProgramExecutable::createStructure):
         (JSC::FunctionExecutable::create):
         (JSC::FunctionExecutable::compileForCall):
         (FunctionExecutable):
         (JSC::FunctionExecutable::compileForConstruct):
         (JSC::FunctionExecutable::jettisonOptimizedCodeFor):
         (JSC::FunctionExecutable::createStructure):
         (JSC::JSFunction::JSFunction):
         * runtime/ExecutionHarness.h:
         (JSC::prepareForExecution):
         (JSC::prepareFunctionForExecution):
         * runtime/FunctionConstructor.cpp:
         (JSC::FunctionConstructor::finishCreation):
         * runtime/FunctionConstructor.h:
         (JSC::FunctionConstructor::createStructure):
         * runtime/FunctionPrototype.cpp:
         (JSC::FunctionPrototype::finishCreation):
         (JSC::FunctionPrototype::addFunctionProperties):
         (JSC::functionProtoFuncBind):
         * runtime/FunctionPrototype.h:
         (JSC::FunctionPrototype::createStructure):
         * runtime/GCActivityCallback.cpp:
         (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
         (JSC::DefaultGCActivityCallback::doWork):
         (JSC::DefaultGCActivityCallback::didAllocate):
         * runtime/GCActivityCallback.h:
         (JSC::GCActivityCallback::GCActivityCallback):
         * runtime/GCActivityCallbackBlackBerry.cpp:
         (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
         (JSC::DefaultGCActivityCallback::doWork):
         (JSC::DefaultGCActivityCallback::didAllocate):
         * runtime/GetterSetter.h:
         (JSC::GetterSetter::GetterSetter):
         (JSC::GetterSetter::create):
         (JSC::GetterSetter::setGetter):
         (JSC::GetterSetter::setSetter):
         (JSC::GetterSetter::createStructure):
         * runtime/Identifier.cpp:
         (JSC::Identifier::add):
         (JSC::Identifier::add8):
         (JSC::Identifier::addSlowCase):
         (JSC::Identifier::from):
         (JSC::Identifier::checkCurrentIdentifierTable):
         * runtime/Identifier.h:
         (JSC::Identifier::Identifier):
         (JSC::Identifier::createLCharFromUChar):
         (Identifier):
         (JSC::Identifier::add):
         * runtime/InternalFunction.cpp:
         (JSC::InternalFunction::InternalFunction):
         (JSC::InternalFunction::finishCreation):
         (JSC::InternalFunction::name):
         (JSC::InternalFunction::displayName):
         * runtime/InternalFunction.h:
         (JSC::InternalFunction::createStructure):
         (InternalFunction):
         * runtime/JSAPIValueWrapper.h:
         (JSC::JSAPIValueWrapper::createStructure):
         (JSC::JSAPIValueWrapper::finishCreation):
         (JSC::JSAPIValueWrapper::JSAPIValueWrapper):
         * runtime/JSActivation.cpp:
         (JSC::JSActivation::symbolTablePut):
         (JSC::JSActivation::symbolTablePutWithAttributes):
         (JSC::JSActivation::getOwnPropertySlot):
         (JSC::JSActivation::put):
         (JSC::JSActivation::putDirectVirtual):
         (JSC::JSActivation::argumentsGetter):
         * runtime/JSActivation.h:
         (JSActivation):
         (JSC::JSActivation::create):
         (JSC::JSActivation::createStructure):
         (JSC::JSActivation::JSActivation):
         (JSC::JSActivation::tearOff):
         * runtime/JSArray.cpp:
         (JSC::createArrayButterflyInDictionaryIndexingMode):
         (JSC::JSArray::setLengthWritable):
         (JSC::JSArray::unshiftCountSlowCase):
         (JSC::JSArray::setLength):
         (JSC::JSArray::push):
         (JSC::JSArray::shiftCountWithAnyIndexingType):
         (JSC::JSArray::unshiftCountWithArrayStorage):
         (JSC::JSArray::unshiftCountWithAnyIndexingType):
         (JSC::ContiguousTypeAccessor::setWithValue):
         (JSC::JSArray::sortCompactedVector):
         (JSC::JSArray::sortVector):
         * runtime/JSArray.h:
         (JSC::JSArray::JSArray):
         (JSArray):
         (JSC::JSArray::shiftCountForShift):
         (JSC::JSArray::unshiftCountForShift):
         (JSC::JSArray::createStructure):
         (JSC::createContiguousArrayButterfly):
         (JSC::createArrayButterfly):
         (JSC):
         (JSC::JSArray::create):
         (JSC::JSArray::tryCreateUninitialized):
         (JSC::constructArray):
         * runtime/JSBoundFunction.cpp:
         (JSC::JSBoundFunction::create):
         (JSC::JSBoundFunction::JSBoundFunction):
         * runtime/JSBoundFunction.h:
         (JSC::JSBoundFunction::createStructure):
         * runtime/JSCJSValue.cpp:
         (JSC::JSValue::putToPrimitive):
         (JSC::JSValue::toStringSlowCase):
         * runtime/JSCJSValue.h:
         (JSC):
         * runtime/JSCell.h:
         (JSCell):
         * runtime/JSCellInlines.h:
         (JSC::JSCell::JSCell):
         (JSC::JSCell::finishCreation):
         (JSC::allocateCell):
         (JSC::JSCell::setStructure):
         (JSC::JSCell::fastGetOwnProperty):
         * runtime/JSDateMath.cpp:
         (JSC::getDSTOffset):
         (JSC::getUTCOffset):
         (JSC::parseDate):
         * runtime/JSDestructibleObject.h:
         (JSC::JSDestructibleObject::JSDestructibleObject):
         * runtime/JSFunction.cpp:
         (JSC::JSFunction::create):
         (JSC::JSFunction::JSFunction):
         (JSC::JSFunction::finishCreation):
         (JSC::JSFunction::createAllocationProfile):
         (JSC::JSFunction::name):
         (JSC::JSFunction::displayName):
         (JSC::JSFunction::getOwnPropertySlot):
         (JSC::JSFunction::deleteProperty):
         * runtime/JSFunction.h:
         (JSFunction):
         (JSC::JSFunction::create):
         (JSC::JSFunction::setScope):
         (JSC::JSFunction::createStructure):
         * runtime/JSGlobalData.cpp: Removed.
         * runtime/JSGlobalData.h: Removed.
         * runtime/JSGlobalObject.cpp:
         (JSC::JSGlobalObject::JSGlobalObject):
         (JSC::JSGlobalObject::~JSGlobalObject):
         (JSC::JSGlobalObject::setGlobalThis):
         (JSC::JSGlobalObject::init):
         (JSC::JSGlobalObject::putDirectVirtual):
         (JSC::JSGlobalObject::reset):
         (JSC):
         (JSC::JSGlobalObject::haveABadTime):
         (JSC::JSGlobalObject::createThrowTypeError):
         (JSC::JSGlobalObject::resetPrototype):
         (JSC::JSGlobalObject::addStaticGlobals):
         (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):
         (JSC::JSGlobalObject::createProgramCodeBlock):
         (JSC::JSGlobalObject::createEvalCodeBlock):
         * runtime/JSGlobalObject.h:
         (JSC::JSGlobalObject::create):
         (JSGlobalObject):
         (JSC::JSGlobalObject::finishCreation):
         (JSC::JSGlobalObject::vm):
         (JSC::JSGlobalObject::createStructure):
         (JSC::ExecState::dynamicGlobalObject):
         (JSC::constructEmptyArray):
         (DynamicGlobalObjectScope):
         * runtime/JSGlobalObjectFunctions.cpp:
         (JSC::globalFuncProtoSetter):
         * runtime/JSLock.cpp:
         (JSC::JSLockHolder::JSLockHolder):
         (JSC::JSLockHolder::init):
         (JSC::JSLockHolder::~JSLockHolder):
         (JSC::JSLock::JSLock):
         (JSC::JSLock::willDestroyGlobalData):
         (JSC::JSLock::lock):
         (JSC::JSLock::unlock):
         (JSC::JSLock::DropAllLocks::DropAllLocks):
         (JSC::JSLock::DropAllLocks::~DropAllLocks):
         * runtime/JSLock.h:
         (JSC):
         (JSLockHolder):
         (JSLock):
         (JSC::JSLock::vm):
         (DropAllLocks):
         * runtime/JSNameScope.h:
         (JSC::JSNameScope::createStructure):
         (JSC::JSNameScope::finishCreation):
         (JSC::JSNameScope::JSNameScope):
         * runtime/JSNotAnObject.h:
         (JSC::JSNotAnObject::JSNotAnObject):
         (JSC::JSNotAnObject::create):
         (JSC::JSNotAnObject::createStructure):
         * runtime/JSONObject.cpp:
         (JSC::JSONObject::JSONObject):
         (JSC::JSONObject::finishCreation):
         (Holder):
         (JSC::Stringifier::Stringifier):
         (JSC::Stringifier::stringify):
         (JSC::Stringifier::toJSON):
         (JSC::Stringifier::appendStringifiedValue):
         (JSC::Stringifier::Holder::Holder):
         (JSC::Stringifier::Holder::appendNextProperty):
         (JSC::Walker::Walker):
         (JSC::Walker::walk):
         (JSC::JSONProtoFuncParse):
         (JSC::JSONProtoFuncStringify):
         (JSC::JSONStringify):
         * runtime/JSONObject.h:
         (JSC::JSONObject::createStructure):
         * runtime/JSObject.cpp:
         (JSC::JSObject::put):
         (JSC::JSObject::putByIndex):
         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
         (JSC::JSObject::enterDictionaryIndexingMode):
         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
         (JSC::JSObject::createInitialIndexedStorage):
         (JSC::JSObject::createInitialUndecided):
         (JSC::JSObject::createInitialInt32):
         (JSC::JSObject::createInitialDouble):
         (JSC::JSObject::createInitialContiguous):
         (JSC::JSObject::createArrayStorage):
         (JSC::JSObject::createInitialArrayStorage):
         (JSC::JSObject::convertUndecidedToInt32):
         (JSC::JSObject::convertUndecidedToDouble):
         (JSC::JSObject::convertUndecidedToContiguous):
         (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
         (JSC::JSObject::convertUndecidedToArrayStorage):
         (JSC::JSObject::convertInt32ToDouble):
         (JSC::JSObject::convertInt32ToContiguous):
         (JSC::JSObject::convertInt32ToArrayStorage):
         (JSC::JSObject::genericConvertDoubleToContiguous):
         (JSC::JSObject::convertDoubleToContiguous):
         (JSC::JSObject::rageConvertDoubleToContiguous):
         (JSC::JSObject::convertDoubleToArrayStorage):
         (JSC::JSObject::convertContiguousToArrayStorage):
         (JSC::JSObject::convertUndecidedForValue):
         (JSC::JSObject::convertInt32ForValue):
         (JSC::JSObject::setIndexQuicklyToUndecided):
         (JSC::JSObject::convertInt32ToDoubleOrContiguousWhilePerformingSetIndex):
         (JSC::JSObject::convertDoubleToContiguousWhilePerformingSetIndex):
         (JSC::JSObject::ensureInt32Slow):
         (JSC::JSObject::ensureDoubleSlow):
         (JSC::JSObject::ensureContiguousSlow):
         (JSC::JSObject::rageEnsureContiguousSlow):
         (JSC::JSObject::ensureArrayStorageSlow):
         (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
         (JSC::JSObject::switchToSlowPutArrayStorage):
         (JSC::JSObject::putDirectVirtual):
         (JSC::JSObject::setPrototype):
         (JSC::JSObject::setPrototypeWithCycleCheck):
         (JSC::JSObject::putDirectAccessor):
         (JSC::JSObject::deleteProperty):
         (JSC::JSObject::getPropertySpecificValue):
         (JSC::JSObject::getOwnNonIndexPropertyNames):
         (JSC::JSObject::seal):
         (JSC::JSObject::freeze):
         (JSC::JSObject::preventExtensions):
         (JSC::JSObject::reifyStaticFunctionsForDelete):
         (JSC::JSObject::removeDirect):
         (JSC::JSObject::putIndexedDescriptor):
         (JSC::JSObject::defineOwnIndexedProperty):
         (JSC::JSObject::allocateSparseIndexMap):
         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
         (JSC::JSObject::putByIndexBeyondVectorLength):
         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
         (JSC::JSObject::putDirectIndexBeyondVectorLength):
         (JSC::JSObject::putDirectNativeFunction):
         (JSC::JSObject::increaseVectorLength):
         (JSC::JSObject::ensureLengthSlow):
         (JSC::JSObject::growOutOfLineStorage):
         (JSC::JSObject::getOwnPropertyDescriptor):
         (JSC::putDescriptor):
         (JSC::JSObject::putDirectMayBeIndex):
         (JSC::DefineOwnPropertyScope::DefineOwnPropertyScope):
         (JSC::DefineOwnPropertyScope::~DefineOwnPropertyScope):
         (DefineOwnPropertyScope):
         (JSC::JSObject::defineOwnNonIndexProperty):
         * runtime/JSObject.h:
         (JSObject):
         (JSC::JSObject::putByIndexInline):
         (JSC::JSObject::putDirectIndex):
         (JSC::JSObject::setIndexQuickly):
         (JSC::JSObject::initializeIndex):
         (JSC::JSObject::getDirect):
         (JSC::JSObject::getDirectOffset):
         (JSC::JSObject::putDirect):
         (JSC::JSObject::isSealed):
         (JSC::JSObject::isFrozen):
         (JSC::JSObject::flattenDictionaryObject):
         (JSC::JSObject::ensureInt32):
         (JSC::JSObject::ensureDouble):
         (JSC::JSObject::ensureContiguous):
         (JSC::JSObject::rageEnsureContiguous):
         (JSC::JSObject::ensureArrayStorage):
         (JSC::JSObject::finishCreation):
         (JSC::JSObject::createStructure):
         (JSC::JSObject::ensureLength):
         (JSC::JSNonFinalObject::createStructure):
         (JSC::JSNonFinalObject::JSNonFinalObject):
         (JSC::JSNonFinalObject::finishCreation):
         (JSC::JSFinalObject::createStructure):
         (JSC::JSFinalObject::finishCreation):
         (JSC::JSFinalObject::JSFinalObject):
         (JSC::JSFinalObject::create):
         (JSC::JSObject::setButterfly):
         (JSC::JSObject::JSObject):
         (JSC::JSObject::inlineGetOwnPropertySlot):
         (JSC::JSObject::putDirectInternal):
         (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
         (JSC::JSObject::putOwnDataProperty):
         (JSC::JSObject::putDirectWithoutTransition):
         (JSC):
         * runtime/JSPropertyNameIterator.cpp:
         (JSC::JSPropertyNameIterator::JSPropertyNameIterator):
         (JSC::JSPropertyNameIterator::create):
         * runtime/JSPropertyNameIterator.h:
         (JSC::JSPropertyNameIterator::createStructure):
         (JSC::JSPropertyNameIterator::setCachedStructure):
         (JSC::JSPropertyNameIterator::setCachedPrototypeChain):
         (JSC::JSPropertyNameIterator::finishCreation):
         (JSC::StructureRareData::setEnumerationCache):
         * runtime/JSProxy.cpp:
         (JSC::JSProxy::setTarget):
         * runtime/JSProxy.h:
         (JSC::JSProxy::create):
         (JSC::JSProxy::createStructure):
         (JSC::JSProxy::JSProxy):
         (JSC::JSProxy::finishCreation):
         (JSProxy):
         * runtime/JSScope.cpp:
         (JSC::executeResolveOperations):
         (JSC::JSScope::resolveContainingScopeInternal):
         (JSC::JSScope::resolveWithBase):
         (JSC::JSScope::resolveWithThis):
         (JSC::JSScope::resolvePut):
         * runtime/JSScope.h:
         (JSScope):
         (JSC::JSScope::JSScope):
         (JSC::JSScope::vm):
         (JSC::ExecState::vm):
         * runtime/JSSegmentedVariableObject.h:
         (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
         (JSC::JSSegmentedVariableObject::finishCreation):
         * runtime/JSString.cpp:
         (JSC::JSRopeString::RopeBuilder::expand):
         (JSC::StringObject::create):
         * runtime/JSString.h:
         (JSC):
         (JSString):
         (JSC::JSString::JSString):
         (JSC::JSString::finishCreation):
         (JSC::JSString::create):
         (JSC::JSString::createHasOtherOwner):
         (JSC::JSString::createStructure):
         (JSRopeString):
         (JSC::JSRopeString::RopeBuilder::RopeBuilder):
         (JSC::JSRopeString::RopeBuilder::append):
         (RopeBuilder):
         (JSC::JSRopeString::JSRopeString):
         (JSC::JSRopeString::finishCreation):
         (JSC::JSRopeString::append):
         (JSC::JSRopeString::createNull):
         (JSC::JSRopeString::create):
         (JSC::jsEmptyString):
         (JSC::jsSingleCharacterString):
         (JSC::jsSingleCharacterSubstring):
         (JSC::jsNontrivialString):
         (JSC::jsString):
         (JSC::jsSubstring):
         (JSC::jsSubstring8):
         (JSC::jsOwnedString):
         (JSC::jsStringBuilder):
         (JSC::inlineJSValueNotStringtoString):
         * runtime/JSStringJoiner.cpp:
         (JSC::JSStringJoiner::build):
         * runtime/JSSymbolTableObject.h:
         (JSC::JSSymbolTableObject::JSSymbolTableObject):
         (JSC::JSSymbolTableObject::finishCreation):
         (JSC::symbolTablePut):
         (JSC::symbolTablePutWithAttributes):
         * runtime/JSVariableObject.h:
         (JSC::JSVariableObject::JSVariableObject):
         * runtime/JSWithScope.h:
         (JSC::JSWithScope::create):
         (JSC::JSWithScope::createStructure):
         (JSC::JSWithScope::JSWithScope):
         * runtime/JSWrapperObject.h:
         (JSWrapperObject):
         (JSC::JSWrapperObject::createStructure):
         (JSC::JSWrapperObject::JSWrapperObject):
         (JSC::JSWrapperObject::setInternalValue):
         * runtime/LiteralParser.cpp:
         (JSC::::tryJSONPParse):
         (JSC::::makeIdentifier):
         (JSC::::parse):
         * runtime/Lookup.cpp:
         (JSC::HashTable::createTable):
         (JSC::setUpStaticFunctionSlot):
         * runtime/Lookup.h:
         (JSC::HashTable::initializeIfNeeded):
         (JSC::HashTable::entry):
         (JSC::HashTable::begin):
         (JSC::HashTable::end):
         (HashTable):
         (JSC::lookupPut):
         * runtime/MathObject.cpp:
         (JSC::MathObject::MathObject):
         (JSC::MathObject::finishCreation):
         (JSC::mathProtoFuncSin):
         * runtime/MathObject.h:
         (JSC::MathObject::createStructure):
         * runtime/MemoryStatistics.cpp:
         * runtime/MemoryStatistics.h:
         * runtime/NameConstructor.cpp:
         (JSC::NameConstructor::finishCreation):
         (JSC::constructPrivateName):
         * runtime/NameConstructor.h:
         (JSC::NameConstructor::createStructure):
         * runtime/NameInstance.cpp:
         (JSC::NameInstance::NameInstance):
         * runtime/NameInstance.h:
         (JSC::NameInstance::createStructure):
         (JSC::NameInstance::create):
         (NameInstance):
         (JSC::NameInstance::finishCreation):
         * runtime/NamePrototype.cpp:
         (JSC::NamePrototype::NamePrototype):
         (JSC::NamePrototype::finishCreation):
         * runtime/NamePrototype.h:
         (JSC::NamePrototype::createStructure):
         * runtime/NativeErrorConstructor.h:
         (JSC::NativeErrorConstructor::createStructure):
         (JSC::NativeErrorConstructor::finishCreation):
         * runtime/NativeErrorPrototype.cpp:
         (JSC::NativeErrorPrototype::finishCreation):
         * runtime/NumberConstructor.cpp:
         (JSC::NumberConstructor::finishCreation):
         (JSC::constructWithNumberConstructor):
         * runtime/NumberConstructor.h:
         (JSC::NumberConstructor::createStructure):
         * runtime/NumberObject.cpp:
         (JSC::NumberObject::NumberObject):
         (JSC::NumberObject::finishCreation):
         (JSC::constructNumber):
         * runtime/NumberObject.h:
         (NumberObject):
         (JSC::NumberObject::create):
         (JSC::NumberObject::createStructure):
         * runtime/NumberPrototype.cpp:
         (JSC::NumberPrototype::NumberPrototype):
         (JSC::NumberPrototype::finishCreation):
         (JSC::integerValueToString):
         (JSC::numberProtoFuncToString):
         * runtime/NumberPrototype.h:
         (JSC::NumberPrototype::createStructure):
         * runtime/ObjectConstructor.cpp:
         (JSC::ObjectConstructor::finishCreation):
         (JSC::objectConstructorGetOwnPropertyDescriptor):
         (JSC::objectConstructorSeal):
         (JSC::objectConstructorFreeze):
         (JSC::objectConstructorPreventExtensions):
         (JSC::objectConstructorIsSealed):
         (JSC::objectConstructorIsFrozen):
         * runtime/ObjectConstructor.h:
         (JSC::ObjectConstructor::createStructure):
         (JSC::constructEmptyObject):
         * runtime/ObjectPrototype.cpp:
         (JSC::ObjectPrototype::ObjectPrototype):
         (JSC::ObjectPrototype::finishCreation):
         (JSC::objectProtoFuncToString):
         * runtime/ObjectPrototype.h:
         (JSC::ObjectPrototype::createStructure):
         * runtime/Operations.cpp:
         (JSC::jsTypeStringForValue):
         * runtime/Operations.h:
         (JSC):
         (JSC::jsString):
         (JSC::jsStringFromArguments):
         (JSC::normalizePrototypeChainForChainAccess):
         (JSC::normalizePrototypeChain):
         * runtime/PropertyMapHashTable.h:
         (JSC::PropertyMapEntry::PropertyMapEntry):
         (JSC::PropertyTable::createStructure):
         (PropertyTable):
         (JSC::PropertyTable::copy):
         * runtime/PropertyNameArray.h:
         (JSC::PropertyNameArray::PropertyNameArray):
         (JSC::PropertyNameArray::vm):
         (JSC::PropertyNameArray::addKnownUnique):
         (PropertyNameArray):
         * runtime/PropertyTable.cpp:
         (JSC::PropertyTable::create):
         (JSC::PropertyTable::clone):
         (JSC::PropertyTable::PropertyTable):
         * runtime/PrototypeMap.cpp:
         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
         * runtime/RegExp.cpp:
         (JSC::RegExp::RegExp):
         (JSC::RegExp::finishCreation):
         (JSC::RegExp::createWithoutCaching):
         (JSC::RegExp::create):
         (JSC::RegExp::compile):
         (JSC::RegExp::compileIfNecessary):
         (JSC::RegExp::match):
         (JSC::RegExp::compileMatchOnly):
         (JSC::RegExp::compileIfNecessaryMatchOnly):
         * runtime/RegExp.h:
         (JSC):
         (RegExp):
         (JSC::RegExp::createStructure):
         * runtime/RegExpCache.cpp:
         (JSC::RegExpCache::lookupOrCreate):
         (JSC::RegExpCache::RegExpCache):
         (JSC::RegExpCache::addToStrongCache):
         * runtime/RegExpCache.h:
         (RegExpCache):
         * runtime/RegExpCachedResult.cpp:
         (JSC::RegExpCachedResult::lastResult):
         (JSC::RegExpCachedResult::setInput):
         * runtime/RegExpCachedResult.h:
         (JSC::RegExpCachedResult::RegExpCachedResult):
         (JSC::RegExpCachedResult::record):
         * runtime/RegExpConstructor.cpp:
         (JSC::RegExpConstructor::RegExpConstructor):
         (JSC::RegExpConstructor::finishCreation):
         (JSC::constructRegExp):
         * runtime/RegExpConstructor.h:
         (JSC::RegExpConstructor::createStructure):
         (RegExpConstructor):
         (JSC::RegExpConstructor::performMatch):
         * runtime/RegExpMatchesArray.cpp:
         (JSC::RegExpMatchesArray::RegExpMatchesArray):
         (JSC::RegExpMatchesArray::create):
         (JSC::RegExpMatchesArray::finishCreation):
         (JSC::RegExpMatchesArray::reifyAllProperties):
         * runtime/RegExpMatchesArray.h:
         (RegExpMatchesArray):
         (JSC::RegExpMatchesArray::createStructure):
         * runtime/RegExpObject.cpp:
         (JSC::RegExpObject::RegExpObject):
         (JSC::RegExpObject::finishCreation):
         (JSC::RegExpObject::match):
         * runtime/RegExpObject.h:
         (JSC::RegExpObject::create):
         (JSC::RegExpObject::setRegExp):
         (JSC::RegExpObject::setLastIndex):
         (JSC::RegExpObject::createStructure):
         * runtime/RegExpPrototype.cpp:
         (JSC::regExpProtoFuncCompile):
         * runtime/RegExpPrototype.h:
         (JSC::RegExpPrototype::createStructure):
         * runtime/SmallStrings.cpp:
         (JSC::SmallStrings::initializeCommonStrings):
         (JSC::SmallStrings::createEmptyString):
         (JSC::SmallStrings::createSingleCharacterString):
         (JSC::SmallStrings::initialize):
         * runtime/SmallStrings.h:
         (JSC):
         (JSC::SmallStrings::singleCharacterString):
         (SmallStrings):
         * runtime/SparseArrayValueMap.cpp:
         (JSC::SparseArrayValueMap::SparseArrayValueMap):
         (JSC::SparseArrayValueMap::finishCreation):
         (JSC::SparseArrayValueMap::create):
         (JSC::SparseArrayValueMap::createStructure):
         (JSC::SparseArrayValueMap::putDirect):
         (JSC::SparseArrayEntry::put):
         * runtime/SparseArrayValueMap.h:
         * runtime/StrictEvalActivation.cpp:
         (JSC::StrictEvalActivation::StrictEvalActivation):
         * runtime/StrictEvalActivation.h:
         (JSC::StrictEvalActivation::create):
         (JSC::StrictEvalActivation::createStructure):
         * runtime/StringConstructor.cpp:
         (JSC::StringConstructor::finishCreation):
         * runtime/StringConstructor.h:
         (JSC::StringConstructor::createStructure):
         * runtime/StringObject.cpp:
         (JSC::StringObject::StringObject):
         (JSC::StringObject::finishCreation):
         (JSC::constructString):
         * runtime/StringObject.h:
         (JSC::StringObject::create):
         (JSC::StringObject::createStructure):
         (StringObject):
         * runtime/StringPrototype.cpp:
         (JSC::StringPrototype::StringPrototype):
         (JSC::StringPrototype::finishCreation):
         (JSC::removeUsingRegExpSearch):
         (JSC::replaceUsingRegExpSearch):
         (JSC::stringProtoFuncMatch):
         (JSC::stringProtoFuncSearch):
         (JSC::stringProtoFuncSplit):
         * runtime/StringPrototype.h:
         (JSC::StringPrototype::createStructure):
         * runtime/StringRecursionChecker.h:
         (JSC::StringRecursionChecker::performCheck):
         (JSC::StringRecursionChecker::~StringRecursionChecker):
         * runtime/Structure.cpp:
         (JSC::StructureTransitionTable::add):
         (JSC::Structure::Structure):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::despecifyDictionaryFunction):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::removePropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::toCacheableDictionaryTransition):
         (JSC::Structure::toUncacheableDictionaryTransition):
         (JSC::Structure::sealTransition):
         (JSC::Structure::freezeTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::takePropertyTableOrCloneIfPinned):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::isSealed):
         (JSC::Structure::isFrozen):
         (JSC::Structure::flattenDictionaryStructure):
         (JSC::Structure::addPropertyWithoutTransition):
         (JSC::Structure::removePropertyWithoutTransition):
         (JSC::Structure::allocateRareData):
         (JSC::Structure::cloneRareDataFrom):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::get):
         (JSC::Structure::despecifyFunction):
         (JSC::Structure::despecifyAllFunctions):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::createPropertyMap):
         (JSC::Structure::getPropertyNamesFromStructure):
         (JSC::Structure::prototypeChainMayInterceptStoreTo):
         * runtime/Structure.h:
         (Structure):
         (JSC::Structure::finishCreation):
         (JSC::Structure::setPrototypeWithoutTransition):
         (JSC::Structure::setGlobalObject):
         (JSC::Structure::setObjectToStringValue):
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
         (JSC::Structure::setPreviousID):
         * runtime/StructureChain.cpp:
         (JSC::StructureChain::StructureChain):
         * runtime/StructureChain.h:
         (JSC::StructureChain::create):
         (JSC::StructureChain::createStructure):
         (JSC::StructureChain::finishCreation):
         (StructureChain):
         * runtime/StructureInlines.h:
         (JSC::Structure::create):
         (JSC::Structure::createStructure):
         (JSC::Structure::get):
         (JSC::Structure::setEnumerationCache):
         (JSC::Structure::prototypeChain):
         (JSC::Structure::propertyTable):
         * runtime/StructureRareData.cpp:
         (JSC::StructureRareData::createStructure):
         (JSC::StructureRareData::create):
         (JSC::StructureRareData::clone):
         (JSC::StructureRareData::StructureRareData):
         * runtime/StructureRareData.h:
         (StructureRareData):
         * runtime/StructureRareDataInlines.h:
         (JSC::StructureRareData::setPreviousID):
         (JSC::StructureRareData::setObjectToStringValue):
         * runtime/StructureTransitionTable.h:
         (StructureTransitionTable):
         (JSC::StructureTransitionTable::setSingleTransition):
         * runtime/SymbolTable.h:
         (JSC::SharedSymbolTable::create):
         (JSC::SharedSymbolTable::createStructure):
         (JSC::SharedSymbolTable::SharedSymbolTable):
         * runtime/VM.cpp: Copied from Source/JavaScriptCore/runtime/JSGlobalData.cpp.
         (JSC::VM::VM):
         (JSC::VM::~VM):
         (JSC::VM::createContextGroup):
         (JSC::VM::create):
         (JSC::VM::createLeaked):
         (JSC::VM::sharedInstanceExists):
         (JSC::VM::sharedInstance):
         (JSC::VM::sharedInstanceInternal):
         (JSC::VM::getHostFunction):
         (JSC::VM::ClientData::~ClientData):
         (JSC::VM::resetDateCache):
         (JSC::VM::startSampling):
         (JSC::VM::stopSampling):
         (JSC::VM::discardAllCode):
         (JSC::VM::dumpSampleData):
         (JSC::VM::addSourceProviderCache):
         (JSC::VM::clearSourceProviderCaches):
         (JSC::VM::releaseExecutableMemory):
         (JSC::releaseExecutableMemory):
         (JSC::VM::gatherConservativeRoots):
         (JSC::VM::addRegExpToTrace):
         (JSC::VM::dumpRegExpTrace):
         * runtime/VM.h: Copied from Source/JavaScriptCore/runtime/JSGlobalData.h.
         (VM):
         (JSC::VM::isSharedInstance):
         (JSC::VM::usingAPI):
         (JSC::VM::isInitializingObject):
         (JSC::VM::setInitializingObjectClass):
         (JSC::WeakSet::heap):
         * runtime/WriteBarrier.h:
         (JSC):
         (JSC::WriteBarrierBase::set):
         (JSC::WriteBarrierBase::setMayBeNull):
         (JSC::WriteBarrierBase::setEarlyValue):
         (JSC::WriteBarrier::WriteBarrier):
         * testRegExp.cpp:
         (GlobalObject):
         (GlobalObject::create):
         (GlobalObject::createStructure):
         (GlobalObject::finishCreation):
         (main):
         (testOneRegExp):
         (parseRegExpLine):
         (runFromFiles):
         (realMain):
         * yarr/YarrInterpreter.h:
         (BytecodePattern):
         * yarr/YarrJIT.cpp:
         (YarrGenerator):
         (JSC::Yarr::YarrGenerator::compile):
         (JSC::Yarr::jitCompile):
         * yarr/YarrJIT.h:
         (JSC):

 2013-04-18  Xuefei Ren  <xren@blackberry.com>

         remove build warning(unused parameter)
         https://bugs.webkit.org/show_bug.cgi?id=114670

         Reviewed by Rob Buis.

         remove warning in Source/JavaScriptCore/runtime/GCActivityCallbackBlackBerry.cpp

         * runtime/GCActivityCallbackBlackBerry.cpp:
         (JSC::DefaultGCActivityCallback::didAllocate):

 2013-04-18  Jonathan Liu  <net147@gmail.com>

         Implement JIT for MinGW-w64 64-bit
         https://bugs.webkit.org/show_bug.cgi?id=114580

         Reviewed by Jocelyn Turcotte.

         * jit/JITStubs.cpp:
         (JSC):

 2013-04-17  Mark Lam  <mark.lam@apple.com>

         Avoid using a branch range that is too far for some CPU architectures.
         https://bugs.webkit.org/show_bug.cgi?id=114782.

         Reviewed by David Kilzer.

         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:

 2013-04-17  Julien Brianceau  <jbrianceau@nds.com>

         Fix SH4 build (broken since r148639).
         https://bugs.webkit.org/show_bug.cgi?id=114773.

         Allow longer displacements for specific branches in SH4 LLINT.

         Reviewed by Oliver Hunt.

         * offlineasm/sh4.rb:

 2013-04-14  Roger Fong  <roger_fong@apple.com>

         Unreviewed. More Windows build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-14  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Windows build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-17  Mark Lam  <mark.lam@apple.com>

         Fix broken build. Replaced a static const with a #define.
         https://bugs.webkit.org/show_bug.cgi?id=114577.

         Unreviewed.

         * runtime/Watchdog.cpp:
         (JSC::Watchdog::Watchdog):
         (JSC::Watchdog::isEnabled):

 2013-04-17  Mark Lam  <mark.lam@apple.com>

         Add LLINT and baseline JIT support for timing out scripts.
         https://bugs.webkit.org/show_bug.cgi?id=114577.

         Reviewed by Geoffrey Garen.

         Introduces the new Watchdog class which is used to track script
         execution time, and initiate script termination if needed.

         * API/JSContextRef.cpp:
         (internalScriptTimeoutCallback):
         (JSContextGroupSetExecutionTimeLimit):
         (JSContextGroupClearExecutionTimeLimit):
         * API/JSContextRefPrivate.h:
         - Added new script execution time limit APIs.
         * API/tests/testapi.c:
         (currentCPUTime):
         (shouldTerminateCallback):
         (cancelTerminateCallback):
         (extendTerminateCallback):
         (main):
         - Added new API tests for script execution time limit.
         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitLoopHint):
         - loop hints are needed for the llint as well. Hence, it will be
           emitted unconditionally.
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::addStackTraceIfNecessary):
         (JSC::Interpreter::throwException):
         (JSC::Interpreter::execute):
         (JSC::Interpreter::executeCall):
         (JSC::Interpreter::executeConstruct):
         - Added checks for script termination before entering script code.
         * jit/JIT.cpp:
         (JSC::JIT::emitWatchdogTimerCheck):
         * jit/JIT.h:
         (JSC::JIT::emit_op_loop_hint):
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION(void, handle_watchdog_timer)):
         * jit/JITStubs.h:
         * llint/LLIntExceptions.cpp:
         (JSC::LLInt::doThrow):
         - Factored out some common code from returnToThrow() and callToThrow().
         (JSC::LLInt::returnToThrow):
         (JSC::LLInt::callToThrow):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL(slow_path_handle_watchdog_timer)):
         * llint/LLIntSlowPaths.h:
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:
         * runtime/ExceptionHelpers.cpp:
         (JSC::throwTerminatedExecutionException):
         - Also removed the now unused InterruptedExecutionException.
         * runtime/ExceptionHelpers.h:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         - Added watchdog, and removed the now obsolete Terminator.
         * runtime/Terminator.h: Removed.
         * runtime/Watchdog.cpp: Added.
         (JSC::Watchdog::Watchdog):
         (JSC::Watchdog::~Watchdog):
         (JSC::Watchdog::setTimeLimit):
         (JSC::Watchdog::didFire):
         (JSC::Watchdog::isEnabled):
         (JSC::Watchdog::fire):
         (JSC::Watchdog::arm):
         (JSC::Watchdog::disarm):
         (JSC::Watchdog::startCountdownIfNeeded):
         (JSC::Watchdog::startCountdown):
         (JSC::Watchdog::stopCountdown):
         (JSC::Watchdog::Scope::Scope):
         (JSC::Watchdog::Scope::~Scope):
         * runtime/Watchdog.h: Added.
         (Watchdog):
         (JSC::Watchdog::didFire):
         (JSC::Watchdog::timerDidFireAddress):
         (JSC::Watchdog::isArmed):
         (Watchdog::Scope):
         * runtime/WatchdogMac.cpp: Added.
         (JSC::Watchdog::initTimer):
         (JSC::Watchdog::destroyTimer):
         (JSC::Watchdog::startTimer):
         (JSC::Watchdog::stopTimer):
         * runtime/WatchdogNone.cpp: Added.
         (JSC::Watchdog::initTimer):
         (JSC::Watchdog::destroyTimer):
         (JSC::Watchdog::startTimer):
         (JSC::Watchdog::stopTimer):

 2013-04-14  Roger Fong  <roger_fong@apple.com>

         Unreviewed. VS2010 Windows build fix.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:

 2013-04-14  Roger Fong  <roger_fong@apple.com>

         Copy make-file-export-generator script to the the Source folders of the projects that use it.
         <rdar://problem/13675604>

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/make-export-file-generator: Copied from Source/WebCore/make-export-file-generator.

 2013-04-17  Brent Fulgham  <bfulgham@webkit.org>

         [Windows, WinCairo] Stop individually building WTF files in JSC.
         https://bugs.webkit.org/show_bug.cgi?id=114705

         Reviewed by Anders Carlsson.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         Export additional String/fastMalloc symbols needed by JSC program.
         * JavaScriptCore.vcproj/jsc/jsc.vcproj: Don't manually build
         WTF implementation files (a second time!) in this project.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         Export additional String/fastMalloc symbols needed by JSC program.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Don't manually
         build WTF implementation files (a second time!) in this project.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Ditto.

 2013-04-17  Mark Lam  <mark.lam@apple.com>

         releaseExecutableMemory() should canonicalize cell liveness data before
         it scans the GC roots.
         https://bugs.webkit.org/show_bug.cgi?id=114733.

         Reviewed by Mark Hahnenberg.

         * heap/Heap.cpp:
         (JSC::Heap::canonicalizeCellLivenessData):
         * heap/Heap.h:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::releaseExecutableMemory):

 2013-04-16  Commit Queue  <rniwa@webkit.org>

         Unreviewed, rolling out r148576.
         http://trac.webkit.org/changeset/148576
         https://bugs.webkit.org/show_bug.cgi?id=114714

         WebCore is building some of these same files (Requested by
         bfulgham on #webkit).

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcproj/jsc/jsc.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters:

 2013-04-16  Brent Fulgham  <bfulgham@webkit.org>

         [Windows, WinCairo] Stop individually building WTF files in JSC.
         https://bugs.webkit.org/show_bug.cgi?id=114705

         Reviewed by Anders Carlsson.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         Export additional String/fastMalloc symbols needed by JSC program.
         * JavaScriptCore.vcproj/jsc/jsc.vcproj: Don't manually build
         WTF implementation files (a second time!) in this project.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         Export additional String/fastMalloc symbols needed by JSC program.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Don't manually
         build WTF implementation files (a second time!) in this project.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Ditto.

 2013-04-16  Patrick Gansterer  <paroga@webkit.org>

         [CMake] Do not use JAVASCRIPTCORE_DIR in add_custom_command() of JavaScriptCore project
         https://bugs.webkit.org/show_bug.cgi?id=114265

         Reviewed by Brent Fulgham.

         Use CMAKE_CURRENT_SOURCE_DIR instead, since it provides the same value and is more
         understandable. Also move the GENERATE_HASH_LUT macro into the CMakeLists.txt
         of JavaScriptCore to avoid the usage of JAVASCRIPTCORE_DIR there too.

         * CMakeLists.txt:

 2013-04-16  Anders Carlsson  <andersca@apple.com>

         Another Windows build fix attempt.

         * runtime/JSGlobalData.h:
         (JSGlobalData):

 2013-04-16  Anders Carlsson  <andersca@apple.com>

         Try to fix the Windows build.

         * runtime/JSGlobalData.h:

 2013-04-16  Brent Fulgham  <bfulgham@webkit.org>

         [Windows] Unreviewed VS2010 build correction.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:
         Specify proper link library to avoid mixture of ICU 4.0 and 4.6
         symbols during link.

 2013-04-15  Ryosuke Niwa  <rniwa@webkit.org>

         Windows clean build fix after r148479.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-15  Anders Carlsson  <andersca@apple.com>

         ScriptWrappable subclasses shouldn't have to include WeakInlines.h
         https://bugs.webkit.org/show_bug.cgi?id=114641

         Reviewed by Alexey Proskuryakov.

         Move back the Weak constructor, destructor and clear() to Weak.h. Add a new weakClearSlowCase function
         and put it in Weak.cpp.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * heap/Weak.cpp: Added.
         * heap/Weak.h:
         * heap/WeakInlines.h:
         * heap/WeakSetInlines.h:

 2013-04-15  Mark Hahnenberg  <mhahnenberg@apple.com>

         HeapTimer lifetime should be less complicated
         https://bugs.webkit.org/show_bug.cgi?id=114529

         Reviewed by Oliver Hunt.

         Right now our HeapTimer lifetime is rather complicated. HeapTimers are "owned" by the JSGlobalData,
         but there's an issue in that there can be races between a thread that is trying to tear down a JSGlobalData
         and the HeapTimer's fire function. Our current code for tearing down HeapTimers is an intricate and delicate
         dance which probably contains subtle bugs.

         We can make our lives easier by changing things around a bit.

         1) We should free the API lock from being solely owned by the JSGlobalData so we don't have to worry about
            grabbing the lock out of invalid memory when our HeapTimer callback fires.

         2) We should also make it so that we deref the JSGlobalData first, then unlock the API lock so that when we
            have the lock, the JSGlobalData is in one of two states: fully valid or completely destroyed, and we know exactly which one.

         3) The JSLock can tell us this information by keeping a back pointer to the JSGlobalData. When the JSGlobalData's
            destructor is called, it clears this pointer in the JSLock. Other clients of the API lock can then check
            this pointer to determine whether or not the JSGlobalData is still around.

         4) The CFRunLoopTimer will use the API lock as its context rather than the HeapTimer itself. The only way
            the HeapTimer's callback can get to the HeapTimer is through the API lock's JSGlobalData pointer.

         5) The CFRunLoopTimerContext struct has two fields for retain and release callbacks for the context's info field.
            We'll provide these callbacks to ref() and deref() the JSLock as necessary. Thus, the timer becomes the other
            owner of the JSLock apart from the JSGlobalData.

         * API/APIShims.h: Remove the cruft that was required by the previous design, such as RefGlobalDataTag.
         (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock):
         (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock):
         (APIEntryShimWithoutLock):
         (JSC::APIEntryShim::APIEntryShim):
         (JSC::APIEntryShim::~APIEntryShim): Protect the API lock with a RefPtr, deref the JSGlobalData, which could destroy it,
         then unlock the API lock. This ordering prevents others from obtaining the API lock while the JSGlobalData is in the
         middle of being torn down.
         (JSC::APIEntryShim::init): We now take the lock, then ref the JSGlobalData, which is the opposite order of when we
         tear down the shim.
         * heap/Heap.cpp:
         (JSC::Heap::setActivityCallback): Use PassOwnPtr now.
         (JSC::Heap::activityCallback): Ditto.
         (JSC::Heap::sweeper): Ditto.
         (JSC):
         * heap/Heap.h:
         (Heap):
         * heap/HeapTimer.cpp:
         (JSC::retainAPILock): Retain callback for CFRunLoopTimerContext struct.
         (JSC::releaseAPILock): Release callback for the CFRunLoopTimerContext struct.
         (JSC::HeapTimer::HeapTimer): Use the API lock as the context's info field rather than the HeapTimer.
         (JSC::HeapTimer::timerDidFire): Grab the API lock. Return early if the JSGlobalData has already been destroyed.
         Otherwise, figure out which kind of HeapTimer we are based on the CFRunLoopTimerRef passed to the callback and
         call the HeapTimer's callback.
         * heap/HeapTimer.h:
         (HeapTimer):
         * heap/IncrementalSweeper.cpp:
         (JSC::IncrementalSweeper::create): PassOwnPtr all the things.
         * heap/IncrementalSweeper.h:
         (IncrementalSweeper):
         * jsc.cpp:
         (jscmain): We use an APIEntryShim instead of a RefPtr for the JSGlobalData because we need to
         tear down the JSGlobalData while we still hold the lock, which the APIEntryShim handles correctly.
         * runtime/GCActivityCallback.h:
         (DefaultGCActivityCallback):
         (JSC::DefaultGCActivityCallback::create):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         (JSC::JSGlobalData::~JSGlobalData): Notify the API lock that the JSGlobalData is being torn down.
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         (JSC::JSGlobalData::apiLock):
         * runtime/JSLock.cpp:
         (JSC::JSLockHolder::JSLockHolder): Ref, then lock (just like the API shim).
         (JSC):
         (JSC::JSLock::willDestroyGlobalData):
         (JSC::JSLockHolder::init):
         (JSC::JSLockHolder::~JSLockHolder): Protect, deref, then unlock (just like the API shim).
         (JSC::JSLock::JSLock):
         * runtime/JSLock.h: Add back pointer to the JSGlobalData and a callback for when the JSGlobalData is being
         torn down that clears this pointer to notify other clients (i.e. timer callbacks) that the JSGlobalData is no
         longer valid.
         (JSLockHolder):
         (JSLock):
         (JSC::JSLock::globalData):
         * testRegExp.cpp:
         (realMain): We use an APIEntryShim instead of a RefPtr for the JSGlobalData because we need to
         tear down the JSGlobalData while we still hold the lock, which the APIEntryShim handles correctly.

 2013-04-15  Julien Brianceau  <jbrianceau@nds.com>

         LLInt SH4 backend implementation
         https://bugs.webkit.org/show_bug.cgi?id=112886

         Reviewed by Oliver Hunt.

         * dfg/DFGOperations.cpp:
         (JSC):
         * jit/JITStubs.cpp:
         * llint/LLIntOfflineAsmConfig.h:
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * offlineasm/arm.rb:
         * offlineasm/ast.rb:
         * offlineasm/backends.rb:
         * offlineasm/instructions.rb:
         * offlineasm/mips.rb:
         * offlineasm/risc.rb:
         * offlineasm/sh4.rb: Added.

 2013-04-15  Patrick Gansterer  <paroga@webkit.org>

         [CMake] Add WTF_USE_*_UNICODE variables
         https://bugs.webkit.org/show_bug.cgi?id=114556

         Reviewed by Brent Fulgham.

         WTF_USE_ICU_UNICODE and WTF_USE_WCHAR_UNICODE are used to
         reduce duplication in the platform specific CMake files.

         * CMakeLists.txt:
         * PlatformEfl.cmake:

 2013-04-13  Patrick Gansterer  <paroga@webkit.org>

         Add missing export macro to SymbolTableEntry::freeFatEntrySlow()

         * runtime/SymbolTable.h:
         (SymbolTableEntry):

 2013-04-12  Mark Hahnenberg  <mhahnenberg@apple.com>

         Block freeing thread should call Region::destroy instead of delete
         https://bugs.webkit.org/show_bug.cgi?id=114544

         Reviewed by Oliver Hunt.

         Since Region doesn't have a virtual destructor, calling delete will not properly clean up all of
         the state of the Region. We should call destroy() instead.

         * heap/BlockAllocator.cpp:
         (JSC::BlockAllocator::releaseFreeRegions):
         (JSC::BlockAllocator::blockFreeingThreadMain):

 2013-04-11  Benjamin Poulain  <bpoulain@apple.com>

         Merge CharacterClassTable into CharacterClass
         https://bugs.webkit.org/show_bug.cgi?id=114409

         Reviewed by Darin Adler.

         CharacterClassTable is only a pointer and a boolean.
         It is a little overkill to make a separate allocation
         for that.

         * create_regex_tables:
         * yarr/YarrJIT.cpp:
         (JSC::Yarr::YarrGenerator::matchCharacterClass):
         * yarr/YarrPattern.cpp:
         (JSC::Yarr::CharacterClassConstructor::charClass):
         * yarr/YarrPattern.h:
         (CharacterClass):
         (JSC::Yarr::CharacterClass::CharacterClass):

 2013-04-11  Michael Saboff  <msaboff@apple.com>

         Added UNLIKELY() suggested in https://bugs.webkit.org/show_bug.cgi?id=114366
         after checking in the original change.

         Rubber-stamped by Jessie Berlin.

         * dfg/DFGOperations.cpp:

 2013-04-10  Benjamin Poulain  <benjamin@webkit.org>

         Unify JSC Parser's error and error message
         https://bugs.webkit.org/show_bug.cgi?id=114363

         Reviewed by Geoffrey Garen.

         The parser kept the error state over two attributes:
         error and errorMessage. They were changed in sync,
         but had some discrepancy (for example, the error message
         was always defined to something).

         This patch unifies the two. There is an error if
         if the error message is non-null or if the parsing finished
         before the end.

         This also gets rid of the allocation of the error message
         when instantiating a parser.

         * parser/Parser.cpp:
         (JSC::::Parser):
         (JSC::::parseInner):
         (JSC::::parseSourceElements):
         (JSC::::parseVarDeclaration):
         (JSC::::parseConstDeclaration):
         (JSC::::parseForStatement):
         (JSC::::parseSwitchStatement):
         (JSC::::parsePrimaryExpression):
         * parser/Parser.h:
         (JSC::Parser::updateErrorMessage):
         (JSC::Parser::updateErrorWithNameAndMessage):
         (JSC::Parser::hasError):
         (Parser):

 2013-04-10  Oliver Hunt  <oliver@apple.com>

         Set trap is not being called for API objects
         https://bugs.webkit.org/show_bug.cgi?id=114403

         Reviewed by Anders Carlsson.

         Intercept putByIndex on the callback object and add tests
         to make sure we don't regress in future.

         * API/JSCallbackObject.h:
         (JSCallbackObject):
         * API/JSCallbackObjectFunctions.h:
         (JSC::::putByIndex):
         (JSC):
         * API/tests/testapi.c:
         (PropertyCatchalls_setProperty):
         * API/tests/testapi.js:

 2013-04-10  Benjamin Poulain  <bpoulain@apple.com>

         Mass remove all the empty directories

         Rubberstamped by Ryosuke Niwa.

         * qt/api: Removed.
         * qt/benchmarks/qscriptengine: Removed.
         * qt/benchmarks/qscriptvalue: Removed.
         * qt/tests/qscriptengine: Removed.
         * qt/tests/qscriptstring: Removed.
         * qt/tests/qscriptvalue: Removed.
         * qt/tests/qscriptvalueiterator: Removed.

 2013-04-10  Mark Hahnenberg  <mhahnenberg@apple.com>

         JSObject::getOwnNonIndexPropertyNames calculates numCacheableSlots incorrectly
         https://bugs.webkit.org/show_bug.cgi?id=114235

         Reviewed by Filip Pizlo.

         If the object doesn't have any properties but the prototype does, we'll assume those prototype properties are
         accessible in the base object's backing store, which is bad.

         * runtime/JSObject.cpp:
         (JSC::JSObject::getPropertyNames):
         (JSC::JSObject::getOwnNonIndexPropertyNames):
         * runtime/PropertyNameArray.h:
         (JSC::PropertyNameArray::PropertyNameArray):
         (JSC::PropertyNameArray::setNumCacheableSlotsForObject):
         (JSC::PropertyNameArray::setBaseObject):
         (PropertyNameArray):

 2013-04-10  Patrick Gansterer  <paroga@webkit.org>

         Remove code duplicates from MacroAssemblerARM
         https://bugs.webkit.org/show_bug.cgi?id=104457

         Reviewed by Oliver Hunt.

         Reuse some existing methods to avoid duplicated code.

         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::store8):
         (JSC::MacroAssemblerARM::store32):
         (JSC::MacroAssemblerARM::swap):
         (JSC::MacroAssemblerARM::add32):
         (JSC::MacroAssemblerARM::sub32):

 2013-04-10  Michael Saboff  <msaboff@apple.com>

         DFG: Negative size for new Array() interpreted as large unsigned int
         https://bugs.webkit.org/show_bug.cgi?id=114366

         Reviewed by Oliver Hunt.

         Added new check in operationNewArrayWithSize() for a negative
         size.  If size is negative throw a "RangeError: Array size is not a
         small enough positive integer" exception.

         * dfg/DFGOperations.cpp:

 2013-04-10  peavo@outlook.com  <peavo@outlook.com>

         WinCairo build fails to link.
         https://bugs.webkit.org/show_bug.cgi?id=114358

         Reviewed by Brent Fulgham.

         Export the symbol WTF::MD5::checksum().

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-08  Anders Carlsson  <andersca@apple.com>

         Remove unneeded headers from FrameLoader.h
         https://bugs.webkit.org/show_bug.cgi?id=114223

         Reviewed by Geoffrey Garen.

         Update for WTF changes.

         * bytecode/SpeculatedType.h:
         * runtime/JSCJSValue.h:

 2013-04-09  Geoffrey Garen  <ggaren@apple.com>

         Removed bitrotted TimeoutChecker code
         https://bugs.webkit.org/show_bug.cgi?id=114336

         Reviewed by Alexey Proskuryakov.

         This mechanism hasn't worked for a while.

         MarkL is working on a new version of this feature with a distinct
         implementation.

         * API/APIShims.h:
         (JSC::APIEntryShim::~APIEntryShim):
         (JSC::APIEntryShim::init):
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGGPRInfo.h:
         * jit/JIT.cpp:
         * jit/JIT.h:
         * jit/JITStubs.cpp:
         * jit/JITStubs.h:
         * jit/JSInterfaceJIT.h:
         (JSInterfaceJIT):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         * runtime/JSGlobalObject.cpp:
         * runtime/JSONObject.cpp:
         (JSC::Stringifier::appendStringifiedValue):
         (JSC::Walker::walk):
         * runtime/TimeoutChecker.cpp: Removed.
         * runtime/TimeoutChecker.h: Removed.

 2013-04-10  Oliver Hunt  <oliver@apple.com>

         REGRESSION (r148073): WebKit Nightly r148082 crashes on launch in JSObjectSetPrivate
         https://bugs.webkit.org/show_bug.cgi?id=114341

         Reviewed by Alexey Proskuryakov.

         Make JSObjectSetPrivate use uncheckedToJS as some clients
         clear their private data during finalization for some reason.

         * API/JSObjectRef.cpp:
         (JSObjectSetPrivate):

 2013-04-09  Oliver Hunt  <oliver@apple.com>

         Add liveness tests to JSC API entry points
         https://bugs.webkit.org/show_bug.cgi?id=114318

         Reviewed by Geoffrey Garen.

         Add simple checks for the existence of a method table on any
         JSCells passed across the API.  This in turn forces a structure
         validity test.

         * API/APICast.h:
         (toJS):
         (toJSForGC):
         (unsafeToJS):
         * API/JSObjectRef.cpp:
         (JSObjectGetPrivate):

 2013-04-09  Oliver Hunt  <oliver@apple.com>

         Rollout last patch as it destroyed everything

         * API/APICast.h:
         (toJS):
         (toJSForGC):

 2013-04-09  Oliver Hunt  <oliver@apple.com>

         Add liveness tests to JSC API entry points
         https://bugs.webkit.org/show_bug.cgi?id=114318

         Reviewed by Filip Pizlo.

         Add simple checks for the existence of a method table on any
         JSCells passed across the API.  This in turn forces a structure
         validity test.

         * API/APICast.h:
         (toJS):
         (toJSForGC):

 2013-04-09  Balazs Kilvady  <kilvadyb@homejinni.com>

         LLInt conditional branch compilation fault on MIPS.
         https://bugs.webkit.org/show_bug.cgi?id=114264

         Reviewed by Filip Pizlo.

         Fix conditional branch compilation in LLInt offlineasm.

         * offlineasm/mips.rb:

 2013-04-08  Mark Hahnenberg  <mhahnenberg@apple.com>

         JSObject::getOwnNonIndexPropertyNames calculates numCacheableSlots incorrectly
         https://bugs.webkit.org/show_bug.cgi?id=114235

         Reviewed by Geoffrey Garen.

         Due to the way that numCacheableSlots is currently calculated, checking an object's prototype for enumerable
         properties causes us not to cache any properties at all. We should only cache properties on the object itself
         since we currently don't take advantage of any sort of name caching for properties in the prototype chain.
         This fix undoes a ~2% SunSpider regression caused by http://trac.webkit.org/changeset/147570.

         * runtime/JSObject.cpp:
         (JSC::JSObject::getOwnNonIndexPropertyNames):

 2013-04-09  Ryosuke Niwa  <rniwa@webkit.org>

         Remove yarr.gyp
         https://bugs.webkit.org/show_bug.cgi?id=114247

         Reviewed by Benjamin Poulain.

         * yarr/yarr.gyp: Removed.

 2013-04-08  Ryosuke Niwa  <rniwa@webkit.org>

         Remove JavaScriptCore.gyp/gypi
         https://bugs.webkit.org/show_bug.cgi?id=114238

         Reviewed by Benjamin Poulain.

         * JavaScriptCore.gyp: Removed.
         * JavaScriptCore.gyp/.gitignore: Removed.
         * JavaScriptCore.gypi: Removed.

 2013-04-08  Vahag Vardanyan  <vaag@ispras.ru>

         Adds fromCharCode intrinsic support.
         https://bugs.webkit.org/show_bug.cgi?id=104807

         Reviewed by Oliver Hunt.

         Switch to using fromCharCode intrinsic instead of call operation in some cases.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleIntrinsic):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
         (DFG):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * runtime/StringConstructor.cpp:
         (JSC::stringFromCharCode):
         (JSC):
         * runtime/StringConstructor.h:
         (JSC):

 2013-04-08  Benjamin Poulain  <benjamin@webkit.org>

         Remove HTML Notification
         https://bugs.webkit.org/show_bug.cgi?id=114231

         Reviewed by Ryosuke Niwa.

         * Configurations/FeatureDefines.xcconfig:

 2013-04-05  Roger Fong  <roger_fong@apple.com>

         Build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-08  Filip Pizlo  <fpizlo@apple.com>

         DFG should be able to inline string equality comparisons
         https://bugs.webkit.org/show_bug.cgi?id=114224

         Reviewed by Oliver Hunt.

         Inline 8-bit string equality, go to slow path for 16-bit strings. 2x speed-up for string equality
         comparisons on 8-bit strings. 20-50% speed-up on JSRegress/HashMap tests. 30% speed-up on
         string-fasta. 2% speed-up on SunSpider overall. Some small speed-ups elsewhere.

         This is a gnarly change but we have loads of test coverage already between the HashMap tests and
         preexisting DFG string equality tests (which appear to have been designed to test OSR exits, but
         also give us good overall coverage on string equality behavior).

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
         (JSC::DFG::SpeculativeJIT::compare):
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         (JSC::DFG::SpeculativeJIT::compileStringEquality):
         (DFG):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):

 2013-04-08  Geoffrey Garen  <ggaren@apple.com>

         Stop #include-ing all of JavaScriptCore in every DOM-related file
         https://bugs.webkit.org/show_bug.cgi?id=114220

         Reviewed by Sam Weinig.

         I separated WeakInlines.h from Weak.h so WebCore data types that need
         to declare a Weak<T> data member don't have to #include all of the
         infrastructure for accessing that data member.

         This also required separating Weak<T> from PassWeak<T> by removing the
         WeakImplAccessor class template and pushing code down into its subclasses.

         * API/JSWeakObjectMapRefPrivate.cpp:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * bytecode/UnlinkedCodeBlock.h:
         * heap/PassWeak.h:
         (JSC):
         (PassWeak):
         (JSC::::PassWeak):
         (JSC::::operator):
         (JSC::::get):
         * heap/SlotVisitorInlines.h:
         * heap/Weak.h:
         (JSC):
         (Weak):
         * heap/WeakInlines.h: Copied from Source/JavaScriptCore/heap/Weak.h.
         (JSC):
         (JSC::::Weak):
         (JSC::::operator):
         (JSC::::get):
         (JSC::::was):
         (JSC::weakClear):
         * jit/JITThunks.h:
         * runtime/RegExpCache.h:
         * runtime/Structure.h:
         * runtime/WeakGCMap.h:

 2013-04-05  Roger Fong  <roger_fong@apple.com>

         Windows build fix fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-04-05  Roger Fong  <roger_fong@apple.com>

         Windows build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-08  Oliver Hunt  <oliver@apple.com>

         Make resolve more robust in the face of lookup misses
         https://bugs.webkit.org/show_bug.cgi?id=114211

         Reviewed by Filip Pizlo.

         This simply short circuits the resolve operations in the
         event that we don't find a path to a property.  There's no
         repro case for this happening unfortunately.

         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):

 2013-04-08  Oliver Hunt  <oliver@apple.com>

         Build fix.

         * assembler/ARMv7Assembler.h:
         (ARMv7Assembler):

 2013-04-08  Justin Haygood  <jhaygood@reaktix.com>

         Allow KeywordLookupGenerator.py to work on Windows with Windows style line endings
         https://bugs.webkit.org/show_bug.cgi?id=63234

         Reviewed by Oliver Hunt.

         * KeywordLookupGenerator.py:
         (parseKeywords):

 2013-04-08  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION(r146669): Assertion hit in JSC::DFG::SpeculativeJIT::fillSpeculateCell() running webgl tests
         https://bugs.webkit.org/show_bug.cgi?id=114129
         <rdar://problem/13594898>

         Reviewed by Darin Adler.

         The check to see if we need a cell check when simplifying a GetById or PutById needs to be hoisted to
         above where we abstractly execute the instruction, since after we abstracting execute it, it will
         seem like it no longer needs the cell check.

         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):

 2013-04-07  Oliver Hunt  <oliver@apple.com>

         Add bounds checking for WTF::Vector::operator[]
         https://bugs.webkit.org/show_bug.cgi?id=89600

         Reviewed by Filip Pizlo.

         Make a few JSC classes opt-out of release mode bounds checking.

         * assembler/AssemblerBuffer.h:
         (AssemblerBuffer):
         * assembler/AssemblerBufferWithConstantPool.h:
         (AssemblerBufferWithConstantPool):
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):
         (JSC::CodeBlock::bytecodeOffset):
         (JSC):
         (JSC::replaceExistingEntries):
         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::bytecodeOffsetForCallAtIndex):
         (JSC::CodeBlock::callReturnIndexVector):
         (JSC::CodeBlock::codeOrigins):
         (RareData):
         * bytecode/UnlinkedCodeBlock.h:
         (JSC::UnlinkedEvalCodeBlock::adoptVariables):
         (UnlinkedEvalCodeBlock):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::BytecodeGenerator):
         (JSC::BytecodeGenerator::emitNewArray):
         (JSC::BytecodeGenerator::emitCall):
         (JSC::BytecodeGenerator::emitConstruct):
         * bytecompiler/BytecodeGenerator.h:
         (CallArguments):
         (JSC::BytecodeGenerator::instructions):
         (BytecodeGenerator):
         * bytecompiler/StaticPropertyAnalysis.h:
         (JSC::StaticPropertyAnalysis::create):
         (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
         (StaticPropertyAnalysis):
         * bytecompiler/StaticPropertyAnalyzer.h:
         (StaticPropertyAnalyzer):
         (JSC::StaticPropertyAnalyzer::StaticPropertyAnalyzer):
         * dfg/DFGJITCompiler.cpp:
         (JSC::DFG::JITCompiler::link):
         * parser/ASTBuilder.h:
         (ASTBuilder):
         * runtime/ArgList.h:
         (MarkedArgumentBuffer):
         * runtime/ArrayPrototype.cpp:
         (JSC::arrayProtoFuncSort):

 2013-04-07  Benjamin Poulain  <benjamin@webkit.org>

         Use Vector::reserveInitialCapacity() when possible in JavaScriptCore runtime
         https://bugs.webkit.org/show_bug.cgi?id=114111

         Reviewed by Andreas Kling.

         Almost all the code was already using Vector::reserveInitialCapacity()
         and Vector::uncheckedAppend(). Fix the remaining parts.

         * runtime/ArgList.h:
         (MarkedArgumentBuffer): The type VectorType is unused.

         * runtime/ArrayPrototype.cpp:
         (JSC::arrayProtoFuncSort):
         Move the variable closer to where it is needed.

         * runtime/JSArray.cpp:
         (JSC::JSArray::setLengthWithArrayStorage):
         * runtime/JSObject.cpp:
         (JSC::JSObject::getOwnPropertyNames):

 2013-04-07  Patrick Gansterer  <paroga@webkit.org>

         Remove references to Skia and V8 from CMake files
         https://bugs.webkit.org/show_bug.cgi?id=114130

         Reviewed by Geoffrey Garen.

         * shell/PlatformBlackBerry.cmake:

 2013-04-07  David Kilzer  <ddkilzer@apple.com>

         Remove the rest of SVG_DOM_OBJC_BINDINGS
         <http://webkit.org/b/114112>

         Reviewed by Geoffrey Garen.

         * Configurations/FeatureDefines.xcconfig:
         - Remove ENABLE_SVG_DOM_OBJC_BINDINGS macro.

 2013-04-07  Oliver Hunt  <oliver@apple.com>

         Inspector should display information about non-object exceptions
         https://bugs.webkit.org/show_bug.cgi?id=114123

         Reviewed by Adele Peterson.

         Make sure we store the right stack information, even when throwing
         a primitive.

         * interpreter/CallFrame.h:
         (JSC::ExecState::clearSupplementaryExceptionInfo):
         (ExecState):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::addStackTraceIfNecessary):
         (JSC::Interpreter::throwException):

 2013-04-06  Oliver Hunt  <oliver@apple.com>

         Unify the many and varied stack trace mechanisms, and make the result sane.
         https://bugs.webkit.org/show_bug.cgi?id=114072

         Reviewed by Filip Pizlo.

         Makes JSC::StackFrame record the bytecode offset and other necessary data
         rather than requiring us to perform eager evaluation of the line number, etc.
         Then remove most of the users of retrieveLastCaller, as most of them were
         using it to create a stack trace in a fairly incomplete and inefficient way.

         StackFrame now also has a couple of helpers to get the line and column info.

         * API/JSContextRef.cpp:
         (JSContextCreateBacktrace):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitDebugHook):
         * interpreter/Interpreter.cpp:
         (JSC):
         (JSC::Interpreter::dumpRegisters):
         (JSC::Interpreter::unwindCallFrame):
         (JSC::getBytecodeOffsetForCallFrame):
         (JSC::getCallerInfo):
         (JSC::StackFrame::line):
         (JSC::StackFrame::column):
         (JSC::StackFrame::expressionInfo):
         (JSC::StackFrame::toString):
         (JSC::Interpreter::getStackTrace):
         (JSC::Interpreter::addStackTraceIfNecessary):
         (JSC::Interpreter::retrieveCallerFromVMCode):
         * interpreter/Interpreter.h:
         (StackFrame):
         (Interpreter):
         * runtime/Error.cpp:
         (JSC::throwError):
         * runtime/JSGlobalData.h:
         (JSC):
         (JSGlobalData):
         * runtime/JSGlobalObject.cpp:
         (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):

 2013-04-06  Geoffrey Garen  <ggaren@apple.com>

         Removed v8 bindings hooks from IDL files
         https://bugs.webkit.org/show_bug.cgi?id=114091

         Reviewed by Anders Carlsson and Sam Weinig.

         * heap/HeapStatistics.h:

 2013-04-03  Roger Fong  <roger_fong@apple.com>

         Windows VS2010 build fix.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-06  Zan Dobersek  <zdobersek@igalia.com>

         Remove the remaining PLATFORM(CHROMIUM) guard in JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=114082

         Reviewed by Ryosuke Niwa.

         * runtime/JSExportMacros.h: Remove the remaining PLATFORM(CHROMIUM) guard.

 2013-04-06  Ed Bartosh  <bartosh@gmail.com>

         --minimal build fails with error: control reaches end of non-void function
         https://bugs.webkit.org/show_bug.cgi?id=114085

         Reviewed by Oliver Hunt.

         * interpreter/Interpreter.cpp: return 0 if JIT is not enabled
         (JSC::getBytecodeOffsetForCallFrame):

 2013-04-06  Geoffrey Garen  <ggaren@apple.com>

         Try to fix the Windows build.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         Added back a symbol that is exported.

 2013-04-06  Geoffrey Garen  <ggaren@apple.com>

         Try to fix the Windows build.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         Removed symbols that aren't exported.

 2013-04-06  Geoffrey Garen  <ggaren@apple.com>

         Rolled out 147820 and 147818 because they caused plugins tests to ASSERT
         https://bugs.webkit.org/show_bug.cgi?id=114094

         Reviewed by Anders Carlsson.

         * API/JSContextRef.cpp:
         (JSContextCreateBacktrace):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitDebugHook):
         * interpreter/Interpreter.cpp:
         (JSC):
         (JSC::Interpreter::dumpRegisters):
         (JSC::Interpreter::unwindCallFrame):
         (JSC::getLineNumberForCallFrame):
         (JSC::getCallerInfo):
         (JSC::Interpreter::getStackTrace):
         (JSC::Interpreter::addStackTraceIfNecessary):
         (JSC::Interpreter::retrieveCallerFromVMCode):
         * interpreter/Interpreter.h:
         (StackFrame):
         (JSC::StackFrame::toString):
         (JSC::StackFrame::friendlyLineNumber):
         (Interpreter):
         * runtime/Error.cpp:
         (JSC::throwError):
         * runtime/JSGlobalData.h:
         (JSC):
         (JSGlobalData):
         * runtime/JSGlobalObject.cpp:
         (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):

 2013-04-06  Patrick Gansterer  <paroga@webkit.org>

         Unreviewed build fix after r146932.

         * profiler/ProfilerDatabase.cpp:
         (Profiler):

 2013-04-06  Patrick Gansterer  <paroga@webkit.org>

         Do not call getenv() on Windows CE where it does not exist.

         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):

 2013-04-05  Benjamin Poulain  <benjamin@webkit.org>

         Second attempt to fix the Windows bot

         Unreviewed.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-05  Benjamin Poulain  <bpoulain@apple.com>

         Attempt to fix the Windows bot

         Unreviewed.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         r147825 removed the symbol for nullptr_t. Add it back.

 2013-04-02  Roger Fong  <roger_fong@apple.com>

         Build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-05  Oliver Hunt  <oliver@apple.com>

         Build fix.

         * interpreter/Interpreter.cpp:
         (JSC::getBytecodeOffsetForCallFrame):

 2013-04-05  Oliver Hunt  <oliver@apple.com>

         Unify the many and varied stack trace mechanisms, and make the result sane.
         https://bugs.webkit.org/show_bug.cgi?id=114072

         Reviewed by Filip Pizlo.

         Makes JSC::StackFrame record the bytecode offset and other necessary data
         rather than requiring us to perform eager evaluation of the line number, etc.
         Then remove most of the users of retrieveLastCaller, as most of them were
         using it to create a stack trace in a fairly incomplete and inefficient way.

         StackFrame now also has a couple of helpers to get the line and column info.

         * API/JSContextRef.cpp:
         (JSContextCreateBacktrace):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitDebugHook):
         * interpreter/Interpreter.cpp:
         (JSC):
         (JSC::Interpreter::dumpRegisters):
         (JSC::Interpreter::unwindCallFrame):
         (JSC::getBytecodeOffsetForCallFrame):
         (JSC::getCallerInfo):
         (JSC::StackFrame::line):
         (JSC::StackFrame::column):
         (JSC::StackFrame::expressionInfo):
         (JSC::StackFrame::toString):
         (JSC::Interpreter::getStackTrace):
         (JSC::Interpreter::addStackTraceIfNecessary):
         (JSC::Interpreter::retrieveCallerFromVMCode):
         * interpreter/Interpreter.h:
         (StackFrame):
         (Interpreter):
         * runtime/Error.cpp:
         (JSC::throwError):
         * runtime/JSGlobalData.h:
         (JSC):
         (JSGlobalData):
         * runtime/JSGlobalObject.cpp:
         (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):

 2013-04-05  Mark Hahnenberg  <mhahnenberg@apple.com>

         tryCacheGetByID sets StructureStubInfo accessType to an incorrect value
         https://bugs.webkit.org/show_bug.cgi?id=114068

         Reviewed by Geoffrey Garen.

         In the case where we have a non-Value cacheable property, we set the StructureStubInfo accessType to
         get_by_id_self, but then we don't patch self and instead patch in a get_by_id_self_fail. This leads to
         incorrect profiling data so when the DFG compiles the function, it uses a GetByOffset rather than a GetById,
         which leads to loading a GetterSetter directly out of an object.

         * jit/JITStubs.cpp:
         (JSC::tryCacheGetByID):
         (JSC::DEFINE_STUB_FUNCTION):

 2013-04-05  Filip Pizlo  <fpizlo@apple.com>

         If CallFrame::trueCallFrame() knows that it's about to read garbage instead of a valid CodeOrigin/InlineCallFrame, then it should give up and return 0 and all callers should be robust against this
         https://bugs.webkit.org/show_bug.cgi?id=114062

         Reviewed by Oliver Hunt.

         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::canGetCodeOrigin):
         (CodeBlock):
         * interpreter/CallFrame.cpp:
         (JSC::CallFrame::trueCallFrame):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::getStackTrace):

 2013-04-05  Geoffrey Garen  <ggaren@apple.com>

         Made USE(JSC) unconditional
         https://bugs.webkit.org/show_bug.cgi?id=114058

         Reviewed by Anders Carlsson.

         * config.h:

 2013-04-05  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, rolling out http://trac.webkit.org/changeset/147729

         It's causing a bunch of breakage on some more strict compilers:
         <inline asm>:1267:2: error: ambiguous instructions require an explicit suffix (could be 'ficomps', or 'ficompl')

         * offlineasm/x86.rb:

 2013-04-05  Roger Fong  <roger_fong@apple.com>

         More VS2010 solution makefile fixes.
         <rdar://problem/13588964>

         * JavaScriptCore.vcxproj/JavaScriptCore.make:

 2013-04-05  Allan Sandfeld Jensen  <allan.jensen@digia.com>

         LLint should be able to use x87 instead of SSE for floating pointer

         https://bugs.webkit.org/show_bug.cgi?id=112239

         Reviewed by Filip Pizlo.

         Implements LLInt floating point operations in x87, to ensure we support
         x86 without SSE2.

         X86 (except 64bit) now defaults to using x87 instructions in order to
         support all 32bit x86 back to i686. The implementation uses the fucomi
         instruction from i686 which sets the new minimum.

         * offlineasm/x86.rb:

 2013-04-04  Christophe Dumez  <ch.dumez@sisa.samsung.com>

         Unreviewed EFL build fix.

         We had undefined reference to `JSC::CodeOrigin::maximumBytecodeIndex'.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::findClosureCallForReturnPC):
         (JSC::CodeBlock::bytecodeOffset):

 2013-04-04  Geoffrey Garen  <ggaren@apple.com>

         Stop pretending that statements return a value
         https://bugs.webkit.org/show_bug.cgi?id=113969

         Reviewed by Oliver Hunt.

         Expressions have an intrinsic value, which they return to their parent
         in the AST.

         Statements just execute for effect in sequence.

         This patch moves emitBytecode into the ExpressionNode and StatementNode
         subclasses, and changes the SatementNode subclass to return void. This
         eliminates some cruft where we used to return 0, or try to save a bogus
         register and return it, as if a statement had a consuming parent in the
         AST.

         * bytecompiler/BytecodeGenerator.h:
         (JSC::BytecodeGenerator::emitNode):
         (BytecodeGenerator):
         (JSC::BytecodeGenerator::emitNodeInConditionContext):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::ConstStatementNode::emitBytecode):
         (JSC::BlockNode::emitBytecode):
         (JSC::EmptyStatementNode::emitBytecode):
         (JSC::DebuggerStatementNode::emitBytecode):
         (JSC::ExprStatementNode::emitBytecode):
         (JSC::VarStatementNode::emitBytecode):
         (JSC::IfNode::emitBytecode):
         (JSC::IfElseNode::emitBytecode):
         (JSC::DoWhileNode::emitBytecode):
         (JSC::WhileNode::emitBytecode):
         (JSC::ForNode::emitBytecode):
         (JSC::ForInNode::emitBytecode):
         (JSC::ContinueNode::emitBytecode):
         (JSC::BreakNode::emitBytecode):
         (JSC::ReturnNode::emitBytecode):
         (JSC::WithNode::emitBytecode):
         (JSC::CaseClauseNode::emitBytecode):
         (JSC::CaseBlockNode::emitBytecodeForBlock):
         (JSC::SwitchNode::emitBytecode):
         (JSC::LabelNode::emitBytecode):
         (JSC::ThrowNode::emitBytecode):
         (JSC::TryNode::emitBytecode):
         (JSC::ScopeNode::emitStatementsBytecode):
         (JSC::ProgramNode::emitBytecode):
         (JSC::EvalNode::emitBytecode):
         (JSC::FunctionBodyNode::emitBytecode):
         (JSC::FuncDeclNode::emitBytecode):
         * parser/NodeConstructors.h:
         (JSC::PropertyListNode::PropertyListNode):
         (JSC::ArgumentListNode::ArgumentListNode):
         * parser/Nodes.h:
         (Node):
         (ExpressionNode):
         (StatementNode):
         (ConstStatementNode):
         (BlockNode):
         (EmptyStatementNode):
         (DebuggerStatementNode):
         (ExprStatementNode):
         (VarStatementNode):
         (IfNode):
         (IfElseNode):
         (DoWhileNode):
         (WhileNode):
         (ForNode):
         (ForInNode):
         (ContinueNode):
         (BreakNode):
         (ReturnNode):
         (WithNode):
         (LabelNode):
         (ThrowNode):
         (TryNode):
         (ProgramNode):
         (EvalNode):
         (FunctionBodyNode):
         (FuncDeclNode):
         (CaseBlockNode):
         (SwitchNode):

 2013-04-04  Oliver Hunt  <oliver@apple.com>

         Exception stack unwinding doesn't handle inline callframes correctly
         https://bugs.webkit.org/show_bug.cgi?id=113952

         Reviewed by Geoffrey Garen.

         The basic problem here is that the exception stack unwinding was
         attempting to be "clever" and avoid doing a correct stack walk
         as it "knew" inline callframes couldn't have exception handlers.

         This used to be safe as the exception handling machinery was
         designed to fail gently and just claim that no handler existed.
         This was "safe" and even "correct" inasmuch as we currently
         don't run any code with exception handlers through the dfg.

         This patch fixes the logic by simply making everything uniformly
         use the safe stack walking machinery, and making the correct
         boundary checks occur everywhere that they should.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::findClosureCallForReturnPC):
         (JSC::CodeBlock::bytecodeOffset):
         * interpreter/Interpreter.cpp:
         (JSC):
         (JSC::Interpreter::dumpRegisters):
         (JSC::Interpreter::unwindCallFrame):
         (JSC::getCallerInfo):
         (JSC::Interpreter::getStackTrace):
         (JSC::Interpreter::retrieveCallerFromVMCode):

 2013-04-04  Geoffrey Garen  <ggaren@apple.com>

         Removed a defunct comment
         https://bugs.webkit.org/show_bug.cgi?id=113948

         Reviewed by Oliver Hunt.

         This is also a convenient way to test the EWS.

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC):

 2013-04-04  Martin Robinson  <mrobinson@igalia.com>

         [GTK] Remove the gyp build
         https://bugs.webkit.org/show_bug.cgi?id=113942

         Reviewed by Gustavo Noronha Silva.

         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Removed.
         * JavaScriptCore.gyp/redirect-stdout.sh: Removed.

 2013-04-04  Geoffrey Garen  <ggaren@apple.com>

         Simplified bytecode generation by merging prefix and postfix nodes
         https://bugs.webkit.org/show_bug.cgi?id=113925

         Reviewed by Filip Pizlo.

         PostfixNode now inherits from PrefixNode, so when we detect that we're
         in a context where postifx and prefix are equivalent, PostFixNode can
         just call through to PrefixNode codegen, instead of duplicating the
         logic.

         * bytecompiler/NodesCodegen.cpp:
         (JSC::PostfixNode::emitResolve):
         (JSC::PostfixNode::emitBracket):
         (JSC::PostfixNode::emitDot):
         * parser/NodeConstructors.h:
         (JSC::PostfixNode::PostfixNode):
         * parser/Nodes.h:
         (JSC):
         (PrefixNode):
         (PostfixNode):

 2013-04-04  Andras Becsi  <andras.becsi@digia.com>

         Fix the build with GCC 4.8
         https://bugs.webkit.org/show_bug.cgi?id=113147

         Reviewed by Allan Sandfeld Jensen.

         Initialize JSObject* exception to suppress warnings that make
         the build fail because of -Werror=maybe-uninitialized.

         * runtime/Executable.cpp:
         (JSC::FunctionExecutable::compileForCallInternal):
         (JSC::FunctionExecutable::compileForConstructInternal):

 2013-04-02  Mark Hahnenberg  <mhahnenberg@apple.com>

         get_by_pname can become confused when iterating over objects with static properties
         https://bugs.webkit.org/show_bug.cgi?id=113831

         Reviewed by Geoffrey Garen.

         get_by_pname doesn't take static properties into account when using a JSPropertyNameIterator to directly
         access an object's backing store. One way to fix this is to not cache any properties when iterating over
         objects with static properties. This patch fixes the bug that was originally reported on swisscom.ch.

         * runtime/JSObject.cpp:
         (JSC::JSObject::getOwnNonIndexPropertyNames):
         * runtime/JSPropertyNameIterator.cpp:
         (JSC::JSPropertyNameIterator::create):
         * runtime/PropertyNameArray.h:
         (JSC::PropertyNameArray::PropertyNameArray):
         (JSC::PropertyNameArray::numCacheableSlots):
         (JSC::PropertyNameArray::setNumCacheableSlots):
         (PropertyNameArray):

 2013-04-02  Geoffrey Garen  <ggaren@apple.com>

         DFG should compile a little sooner
         https://bugs.webkit.org/show_bug.cgi?id=113835

         Unreviewed.

         Rolled out r147511 because it was based on incorrect performance
         measurement.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::optimizationThresholdScalingFactor):

 2013-04-02  Geoffrey Garen  <ggaren@apple.com>

         DFG should compile a little sooner
         https://bugs.webkit.org/show_bug.cgi?id=113835

         Reviewed by Michael Saboff.

         2% speedup on SunSpider.

         2% speedup on JSRegress.

         Neutral on Octane, v8, and Kraken.

         The worst-hit single sub-test is kraken-stanford-crypto-ccm.js, which gets
         18% slower. Since Kraken is neutral overall in its preferred mean, I
         think that's OK for now.

         (Our array indexing speculation fails pathologically on
         kraken-stanford-crypto-ccm.js. Compiling sooner is a regression because
         it triggers those failures sooner. I'm going to file some follow-up bugs
         explaining how to fix our speculations on this sub-test, at which point
         compiling earlier should become a slight speedup on Kraken overall.)

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::optimizationThresholdScalingFactor): I experimented
         with a few different options, including reducing the coefficient 'a'.
         A simple linear reduction on instruction count worked best.

 2013-04-01  Benjamin Poulain  <benjamin@webkit.org>

         Use Vector::reserveInitialCapacity and Vector::uncheckedAppend for JSC's APIs
         https://bugs.webkit.org/show_bug.cgi?id=113651

         Reviewed by Andreas Kling.

         This removes a bunch of branches on initialization and when
         filling the vector.

         * API/JSCallbackConstructor.cpp:
         (JSC::constructJSCallback):
         * API/JSCallbackFunction.cpp:
         (JSC::JSCallbackFunction::call):
         * API/JSCallbackObjectFunctions.h:
         (JSC::::construct):
         (JSC::::call):
         * API/JSObjectRef.cpp:
         (JSObjectCopyPropertyNames):

 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         Fixing borked VS 2010 project file

         Unreviewed bot greening.

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         One more Windows build fix

         Unreviewed.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         More build fallout fixes.

         Unreviewed build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add new export symbols.
         * heap/SuperRegion.cpp: Windows didn't like "LLU".

 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         r147324 broke the world
         https://bugs.webkit.org/show_bug.cgi?id=113704

         Unreviewed build fix.

         Remove a bunch of unused variables and use the correctly sized types for 32-bit platforms.

         * heap/BlockAllocator.cpp:
         (JSC::BlockAllocator::BlockAllocator):
         * heap/BlockAllocator.h:
         (BlockAllocator):
         * heap/Heap.cpp:
         (JSC::Heap::Heap):
         * heap/SuperRegion.cpp:
         (JSC::SuperRegion::SuperRegion):
         * heap/SuperRegion.h:
         (SuperRegion):

 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         32-bit Windows build fix

         Unreviewed build fix.

         * heap/SuperRegion.cpp:
         * heap/SuperRegion.h: Use uint64_t instead of size_t.
         (SuperRegion):

 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         EFL build fix

         Unreviewed build fix.

         * CMakeLists.txt:

 2013-03-31  Mark Hahnenberg  <mhahnenberg@apple.com>

         Regions should be allocated from the same contiguous segment of virtual memory
         https://bugs.webkit.org/show_bug.cgi?id=113662

         Reviewed by Filip Pizlo.

         Instead of letting the OS spread our Regions all over the place, we should allocate them all within
         some range of each other. This change will open the door to some other optimizations, e.g. doing simple
         range checks for our write barriers and compressing JSCell pointers to 32-bits.

         Added new SuperRegion class that encapsulates allocating Regions from a contiguous reserved chunk of
         virtual address space. It functions very similarly to the FixedVMPoolExecutableAllocator class used by the JIT.

         Also added two new subclasses of Region, NormalRegion and ExcessRegion.

         NormalRegion is the type of Region that is normally allocated when there is available space remaining
         in the SuperRegion. If we ever run out of space in the SuperRegion, we fall back to allocating
         ExcessRegions, which are identical to how Regions have behaved up until now, i.e. they contain a
         PageAllocationAligned.

         We only use the SuperRegion (and NormalRegions) on 64-bit systems, since it doesn't make sense to reserve the
         entire 4 GB address space on 32-bit systems just for the JS heap.

         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * heap/BlockAllocator.cpp:
         (JSC::BlockAllocator::BlockAllocator):
         * heap/BlockAllocator.h:
         (JSC):
         (BlockAllocator):
         (JSC::BlockAllocator::allocate):
         (JSC::BlockAllocator::allocateCustomSize):
         (JSC::BlockAllocator::deallocateCustomSize):
         * heap/Heap.cpp:
         (JSC::Heap::Heap):
         (JSC):
         (JSC::Heap::didExceedFixedHeapSizeLimit):
         * heap/Heap.h:
         (Heap):
         * heap/MarkedBlock.cpp:
         (JSC::MarkedBlock::create):
         * heap/Region.h:
         (Region):
         (JSC):
         (NormalRegion):
         (JSC::NormalRegion::base):
         (JSC::NormalRegion::size):
         (ExcessRegion):
         (JSC::ExcessRegion::base):
         (JSC::ExcessRegion::size):
         (JSC::NormalRegion::NormalRegion):
         (JSC::NormalRegion::tryCreate):
         (JSC::NormalRegion::tryCreateCustomSize):
         (JSC::NormalRegion::reset):
         (JSC::ExcessRegion::ExcessRegion):
         (JSC::ExcessRegion::~ExcessRegion):
         (JSC::ExcessRegion::create):
         (JSC::ExcessRegion::createCustomSize):
         (JSC::ExcessRegion::reset):
         (JSC::Region::Region):
         (JSC::Region::initializeBlockList):
         (JSC::Region::create):
         (JSC::Region::createCustomSize):
         (JSC::Region::~Region):
         (JSC::Region::destroy):
         (JSC::Region::reset):
         (JSC::Region::deallocate):
         (JSC::Region::base):
         (JSC::Region::size):
         * heap/SuperRegion.cpp: Added.
         (JSC):
         (JSC::SuperRegion::SuperRegion):
         (JSC::SuperRegion::getAlignedBase):
         (JSC::SuperRegion::allocateNewSpace):
         (JSC::SuperRegion::notifyNeedPage):
         (JSC::SuperRegion::notifyPageIsFree):
         * heap/SuperRegion.h: Added.
         (JSC):
         (SuperRegion):

 2013-04-01  Benjamin Poulain  <benjamin@webkit.org>

         Remove an unused variable from the ARMv7 Assembler
         https://bugs.webkit.org/show_bug.cgi?id=113653

         Reviewed by Andreas Kling.

         * assembler/ARMv7Assembler.h:
         (ARMv7Assembler):

 2013-03-31  Adam Barth  <abarth@webkit.org>

         [Chromium] Yarr should build using a separate GYP file from JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=113652

         Reviewed by Nico Weber.

         This patch moves JavaScriptCore.gyp to yarr.gyp because Chromium only
         uses this GYP file to build yarr.

         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp:
         * JavaScriptCore.gypi:
         * yarr/yarr.gyp: Renamed from Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCore.gyp.

 2013-03-31  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, fix a comment. While thinking about TBAA for array accesses,
         I realized that we have to be super careful about aliasing of typed arrays.

         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::getByValLoadElimination):

 2013-03-30  Mark Hahnenberg  <mhahnenberg@apple.com>

         Move Region into its own header
         https://bugs.webkit.org/show_bug.cgi?id=113617

         Reviewed by Geoffrey Garen.

         BlockAllocator.h is getting a little crowded. We should move the Region class into its own
         header, since it's pretty independent from the BlockAllocator.

         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * heap/BlockAllocator.h:
         (JSC):
         * heap/Region.h: Added.
         (JSC):
         (DeadBlock):
         (JSC::DeadBlock::DeadBlock):
         (Region):
         (JSC::Region::blockSize):
         (JSC::Region::isFull):
         (JSC::Region::isEmpty):
         (JSC::Region::isCustomSize):
         (JSC::Region::create):
         (JSC::Region::createCustomSize):
         (JSC::Region::Region):
         (JSC::Region::~Region):
         (JSC::Region::reset):
         (JSC::Region::allocate):
         (JSC::Region::deallocate):

 2013-03-29  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Remove -[JSManagedValue managedValueWithValue:owner:]
         https://bugs.webkit.org/show_bug.cgi?id=113602

         Reviewed by Geoffrey Garen.

         Since we put the primary way of keeping track of external object graphs (i.e. "managed" references)
         in JSVirtualMachine, there is some overlap in the functionality of that interface and JSManagedValue.
         Specifically, we no longer need the methods that include an owner, since ownership is now tracked
         by JSVirtualMachine. These JSManagedValues will become weak pointers unless they are used
         with [JSVirtualMachine addManagedReference:withOwner:], in which case their lifetime is tied to that
         of their owner.

         * API/JSManagedValue.h:
         * API/JSManagedValue.mm:
         (-[JSManagedValue init]):
         (-[JSManagedValue initWithValue:]):
         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
         * API/JSVirtualMachine.mm:
         (getInternalObjcObject):
         * API/tests/testapi.mm:
         (-[TextXYZ setOnclick:]):
         (-[TextXYZ dealloc]):

 2013-03-29  Geoffrey Garen  <ggaren@apple.com>

         Simplified bytecode generation by unforking "condition context" codegen
         https://bugs.webkit.org/show_bug.cgi?id=113554

         Reviewed by Mark Hahnenberg.

         Now, a node that establishes a condition context can always ask its child
         nodes to generate into that context.

         This has a few advantages:

         (*) Removes a bunch of code;

         (*) Optimizes a few missed cases like "if (!(x < 2))", "if (!!x)", and
         "if (!x || !y)";

         (*) Paves the way to removing more opcodes.

         * bytecode/Opcode.h:
         (JSC): Separated out the branching opcodes for clarity.
         * bytecompiler/NodesCodegen.cpp:
         (JSC::ExpressionNode::emitBytecodeInConditionContext): All expressions
         can be emitted in a condition context now -- the default behavior is
         to branch based on the expression's value.

         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
         (JSC::ConditionalNode::emitBytecode):
         (JSC::IfNode::emitBytecode):
         (JSC::IfElseNode::emitBytecode):
         (JSC::DoWhileNode::emitBytecode):
         (JSC::WhileNode::emitBytecode):
         (JSC::ForNode::emitBytecode):
         * parser/Nodes.h:
         (JSC::ExpressionNode::isSubtract):
         (ExpressionNode):
         (LogicalNotNode):
         (LogicalOpNode): Removed lots of code for handling expressions
         that couldn't generate into a condition context because all expressions
         can now.

 2013-03-28  Geoffrey Garen  <ggaren@apple.com>

         Simplified the bytecode by removing op_loop and op_loop_if_*
         https://bugs.webkit.org/show_bug.cgi?id=113548

         Reviewed by Filip Pizlo.

         Regular jumps will suffice.

         These opcodes are identical to branches, except they also do timeout
         checking. That style of timeout checking has been broken for a long
         time, and when we add back timeout checking, it won't use these opcodes.

         * JavaScriptCore.order:
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         * bytecode/Opcode.h:
         (JSC):
         (JSC::padOpcodeName):
         * bytecode/PreciseJumpTargets.cpp:
         (JSC::computePreciseJumpTargets):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitJump):
         (JSC::BytecodeGenerator::emitJumpIfTrue):
         (JSC::BytecodeGenerator::emitJumpIfFalse):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCapabilities.h:
         (JSC::DFG::canCompileOpcode):
         * jit/JIT.cpp:
         (JSC::JIT::privateCompileMainPass):
         (JSC::JIT::privateCompileSlowCases):
         * jit/JIT.h:
         (JIT):
         (JSC):
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:

 2013-03-28  Geoffrey Garen  <ggaren@apple.com>

         Simplified the bytecode by removing op_jmp_scopes
         https://bugs.webkit.org/show_bug.cgi?id=113545

         Reviewed by Filip Pizlo.

         We already have op_pop_scope and op_jmp, so we don't need op_jmp_scopes.
         Using op_jmp_scopes was also adding a "jump to self" to codegen for
         return statements, which was pretty silly.

         * JavaScriptCore.order:
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         * bytecode/Opcode.h:
         (JSC::padOpcodeName):
         * bytecode/PreciseJumpTargets.cpp:
         (JSC::computePreciseJumpTargets):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitComplexPopScopes):
         (JSC::BytecodeGenerator::emitPopScopes):
         * bytecompiler/BytecodeGenerator.h:
         (BytecodeGenerator):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::ContinueNode::emitBytecode):
         (JSC::BreakNode::emitBytecode):
         (JSC::ReturnNode::emitBytecode):
         * jit/JIT.cpp:
         (JSC::JIT::privateCompileMainPass):
         * jit/JIT.h:
         * jit/JITOpcodes.cpp:
         * jit/JITOpcodes32_64.cpp:
         * jit/JITStubs.cpp:
         * jit/JITStubs.h:
         * llint/LLIntSlowPaths.cpp:
         * llint/LLIntSlowPaths.h:
         * llint/LowLevelInterpreter.asm:

 2013-03-28  Mark Hahnenberg  <mhahnenberg@apple.com>

         Safari hangs during test262 run in CodeCache::pruneSlowCase
         https://bugs.webkit.org/show_bug.cgi?id=113469

         Reviewed by Geoffrey Garen.

         We can end up hanging for quite some time if we add a lot of small keys to the CodeCache.
         By the time we get around to pruning the cache, we have a potentially tens or hundreds of
         thousands of small entries, which can cause a noticeable hang when pruning them.

         To fix this issue we added a hard cap to the number of entries in the cache because we
         could potentially have to remove every element in the map.

         * runtime/CodeCache.cpp:
         (JSC::CodeCacheMap::pruneSlowCase): We need to prune until we're both under the hard cap and the
         capacity in bytes.
         * runtime/CodeCache.h:
         (CodeCacheMap):
         (JSC::CodeCacheMap::numberOfEntries): Convenience accessor function to the number of entries in
         the map that does the cast to size_t of m_map.size() for us.
         (JSC::CodeCacheMap::canPruneQuickly): Checks that the total number is under the hard cap. We put this
         check inside a function to more accurately describe why we're doing the check and to abstract out
         the actual calculation in case we want to coalesce calls to pruneSlowCase in the future.
         (JSC::CodeCacheMap::prune): Check the number of entries against our hard cap. If it's greater than
         the cap then we need to drop down to pruneSlowCase.

 2013-03-28  Zan Dobersek  <zdobersek@igalia.com>

         Unreviewed build fix for the EFL and GTK ports.

         * runtime/CodeCache.cpp:
         (JSC::CodeCacheMap::pruneSlowCase): Pass a 0 casted to the int64_t type instead of 0LL
         to the std::max call so the arguments' types match.

 2013-03-27  Geoffrey Garen  <ggaren@apple.com>

         Unreviewed build fix: Removed a dead field.

         Pointed out by Mark Lam.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::ByteCodeParser):
         (ByteCodeParser):

 2013-03-27  Geoffrey Garen  <ggaren@apple.com>

         Unreviewed build fix: Removed a dead field.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::ByteCodeParser):
         (ByteCodeParser):

 2013-03-27  Geoffrey Garen  <ggaren@apple.com>

         Removed some dead code in the DFG bytecode parser
         https://bugs.webkit.org/show_bug.cgi?id=113472

         Reviewed by Sam Weinig.

         Now that Phi creation and liveness analysis are separate passes, we can
         remove the vestiges of code that used to do that in the bytecode
         parser.

         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::addToGraph):
         (JSC::DFG::ByteCodeParser::parse):

 2013-03-27  Filip Pizlo  <fpizlo@apple.com>

         JIT and DFG should NaN-check loads from Float32 arrays
         https://bugs.webkit.org/show_bug.cgi?id=113462
         <rdar://problem/13490804>

         Reviewed by Mark Hahnenberg.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::emitFloatTypedArrayGetByVal):

 2013-03-27  Mark Hahnenberg  <mhahnenberg@apple.com>

         CodeCache::m_capacity can becoming negative, producing undefined results in pruneSlowCase
         https://bugs.webkit.org/show_bug.cgi?id=113453

         Reviewed by Geoffrey Garen.

         * runtime/CodeCache.cpp:
         (JSC::CodeCacheMap::pruneSlowCase): We make sure that m_minCapacity doesn't drop below zero now.
         This prevents m_capacity from doing the same.

 2013-03-27  Filip Pizlo  <fpizlo@apple.com>

         DFG should use CheckStructure for typed array checks whenever possible
         https://bugs.webkit.org/show_bug.cgi?id=113374

         Reviewed by Geoffrey Garen.

         We used to do the right thing, but it appears that this regressed at some point. Since the
         FixupPhase now has the ability to outright remove spurious CheckStructures on array
         operations, it is profitable for the ByteCodeParser to insert CheckStructures whenver there
         is a chance that it might be profitable, and when the profiling tells us what structure to
         check.

         Also added some code for doing ArrayProfile debugging.

         This is a slightly speed-up. Maybe 3% on Mandreel.

         * bytecode/ArrayProfile.cpp:
         (JSC::ArrayProfile::computeUpdatedPrediction):
         * dfg/DFGArrayMode.h:
         (JSC::DFG::ArrayMode::benefitsFromStructureCheck):

 2013-03-27  Zeno Albisser  <zeno@webkit.org>

         [Qt] Remove Qt specific WorkQueueItem definitions.
         https://bugs.webkit.org/show_bug.cgi?id=112891

         This patch is preparation work for removing
         WorkQueue related code from TestRunnerQt and
         replacing it with generic TestRunner code.

         Reviewed by Benjamin Poulain.

         * API/JSStringRefQt.cpp:
         (JSStringCreateWithQString):
             Adding a convenience function to create a
             JSStringRef from a QString.
         * API/JSStringRefQt.h:

 2013-03-26  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION: Sometimes, operations on proven strings ignore changes to the string prototype
         https://bugs.webkit.org/show_bug.cgi?id=113353
         <rdar://problem/13510778>

         Reviewed by Mark Hahnenberg and Geoffrey Garen.

         ToString should call speculateStringObject() even if you know that it's a string object, since
         it calls it to also get the watchpoint. Note that even with this change, if you do
         Phantom(Check:StringObject:@a), it might get eliminated just because we proved that @a is a
         string object (thereby eliminating the prototype watchpoint); that's fine since ToString is
         MustGenerate and never decays to Phantom.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
         (JSC::DFG::SpeculativeJIT::speculateStringObject):
         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):

 2013-03-26  Mark Hahnenberg  <mhahnenberg@apple.com>

         REGRESSION(r144131): It made fast/js/regress/string-repeat-arith.html assert on 32 bit
         https://bugs.webkit.org/show_bug.cgi?id=112106

         Rubber stamped by Filip Pizlo.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): Get rid of the case for constants because
         we would have done constant folding anyways on a ValueToInt32.
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): Fixed a random compile error with this flag enabled.

 2013-03-26  Filip Pizlo  <fpizlo@apple.com>

         JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
         https://bugs.webkit.org/show_bug.cgi?id=113144

         Reviewed by Geoffrey Garen.

         Forgot to include Geoff's requested change in the original commit.

         * profiler/ProfilerDatabase.cpp:
         (Profiler):

 2013-03-25  Filip Pizlo  <fpizlo@apple.com>

         JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
         https://bugs.webkit.org/show_bug.cgi?id=113144

         Reviewed by Geoffrey Garen.

         Added the ability to save profiler output with JSC_enableProfiler=true. It will save it
         to the current directory, or JSC_PROFILER_PATH if the latter was specified.

         This works by saving the Profiler::Database either when it is destroyed or atexit(),
         whichever happens first.

         This allows use of the profiler from any WebKit client.

         * jsc.cpp:
         (jscmain):
         * profiler/ProfilerDatabase.cpp:
         (Profiler):
         (JSC::Profiler::Database::Database):
         (JSC::Profiler::Database::~Database):
         (JSC::Profiler::Database::registerToSaveAtExit):
         (JSC::Profiler::Database::addDatabaseToAtExit):
         (JSC::Profiler::Database::removeDatabaseFromAtExit):
         (JSC::Profiler::Database::performAtExitSave):
         (JSC::Profiler::Database::removeFirstAtExitDatabase):
         (JSC::Profiler::Database::atExitCallback):
         * profiler/ProfilerDatabase.h:
         (JSC::Profiler::Database::databaseID):
         (Database):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):

 2013-03-25  Filip Pizlo  <fpizlo@apple.com>

         ArrayMode should not consider SpecOther when refining the base
         https://bugs.webkit.org/show_bug.cgi?id=113271

         Reviewed by Geoffrey Garen.

         9% speed-up on Octane/pdfjs.

         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::refine):

 2013-03-26  Csaba Osztrogonác  <ossy@webkit.org>

         Fix unused parameter warnings in JITInlines.h
         https://bugs.webkit.org/show_bug.cgi?id=112560

         Reviewed by Zoltan Herczeg.

         * jit/JITInlines.h:
         (JSC::JIT::beginUninterruptedSequence):
         (JSC::JIT::endUninterruptedSequence):
         (JSC):

 2013-03-25  Kent Tamura  <tkent@chromium.org>

         Rename ENABLE_INPUT_TYPE_DATETIME
         https://bugs.webkit.org/show_bug.cgi?id=113254

         Reviewed by Kentaro Hara.

         Rename ENABLE_INPUT_TYPE_DATETIME to ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE.
         Actually I'd like to remove the code, but we shouldn't remove it yet
         because we shipped products with it on some platforms.

         * Configurations/FeatureDefines.xcconfig:

 2013-03-25  Mark Lam  <mark.lam@apple.com>

         Offlineasm cloop backend compiles op+branch incorrectly.
         https://bugs.webkit.org/show_bug.cgi?id=113146.

         Reviewed by Geoffrey Garen.

         * dfg/DFGRepatch.h:
         (JSC::DFG::dfgResetGetByID):
         (JSC::DFG::dfgResetPutByID):
         - These functions never return when the DFG is dsiabled, not just when
           asserts are enabled. Changing the attribute from NO_RETURN_DUE_TO_ASSERT
           to NO_RETURN.
         * llint/LLIntOfflineAsmConfig.h:
         - Added some #defines needed to get the cloop building again.
         * offlineasm/cloop.rb:
         - Fix cloopEmitOpAndBranchIfOverflow() and cloopEmitOpAndBranch() to
           emit code that unconditionally executes the specified operation before
           doing the conditional branch.

 2013-03-25  Mark Hahnenberg  <mhahnenberg@apple.com>

         JSObject::enterDictionaryIndexingMode doesn't have a case for ALL_BLANK_INDEXING_TYPES
         https://bugs.webkit.org/show_bug.cgi?id=113236

         Reviewed by Geoffrey Garen.

         * runtime/JSObject.cpp:
         (JSC::JSObject::enterDictionaryIndexingMode): We forgot blank indexing types.

 2013-03-23  Mark Hahnenberg  <mhahnenberg@apple.com>

         HandleSet should use HeapBlocks for storing handles
         https://bugs.webkit.org/show_bug.cgi?id=113145

         Reviewed by Geoffrey Garen.

         * GNUmakefile.list.am: Build project changes.
         * JavaScriptCore.gypi: Ditto.
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
         * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
         * heap/BlockAllocator.cpp: Rename the RegionSet to m_fourKBBlockRegionSet because there are
         too many block types to include them all in the name now.
         (JSC::BlockAllocator::BlockAllocator):
         * heap/BlockAllocator.h:
         (BlockAllocator): Add the appropriate override for regionSetFor.
         (JSC::WeakBlock):
         (JSC::MarkStackSegment):
         (JSC::HandleBlock):
         * heap/HandleBlock.h: Added.
         (HandleBlock): New class for HandleBlocks.
         (JSC::HandleBlock::blockFor): Static method to get the block of the given HandleNode pointer. Allows
         us to quickly figure out which HandleSet the HandleNode belongs to without storing the pointer to it
         in the HandleNode.
         (JSC::HandleBlock::handleSet): Getter.
         * heap/HandleBlockInlines.h: Added.
         (JSC::HandleBlock::create):
         (JSC::HandleBlock::HandleBlock):
         (JSC::HandleBlock::payloadEnd):
         (JSC::HandleBlock::payload):
         (JSC::HandleBlock::nodes):
         (JSC::HandleBlock::nodeAtIndex):
         (JSC::HandleBlock::nodeCapacity):
         * heap/HandleSet.cpp:
         (JSC::HandleSet::~HandleSet):
         (JSC::HandleSet::grow):
         * heap/HandleSet.h:
         (HandleNode): Move the internal Node class from HandleSet to be its own public class so it can be
         used by HandleBlock.
         (HandleSet): Add a typedef so that Node refers to the new HandleNode class.
         (JSC::HandleSet::toHandle):
         (JSC::HandleSet::toNode):
         (JSC::HandleSet::allocate):
         (JSC::HandleSet::deallocate):
         (JSC::HandleNode::HandleNode):
         (JSC::HandleNode::slot):
         (JSC::HandleNode::handleSet): Use the new blockFor static function to get the right HandleBlock and lookup
         the HandleSet.
         (JSC::HandleNode::setPrev):
         (JSC::HandleNode::prev):
         (JSC::HandleNode::setNext):
         (JSC::HandleNode::next):
         (JSC::HandleSet::forEachStrongHandle):
         * heap/Heap.h: Friend HandleSet so that it can access the BlockAllocator when allocating HandleBlocks.

 2013-03-22  David Kilzer  <ddkilzer@apple.com>

         BUILD FIX (r145119): Make JSValue* properties default to (assign)
         <rdar://problem/13380794>

         Reviewed by Mark Hahnenberg.

         Fixes the following build failures:

             Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
             @property JSValue *onclick;
             ^
             Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: default property attrib ute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
             Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
             @property JSValue *weakOnclick;
             ^
             Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: default property attribute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
             4 errors generated.

         * API/tests/testapi.mm: Default to (assign) for JSValue*
         properties.

 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

         testLeakingPrototypesAcrossContexts added in r146682 doesn't compile on Win and fails on Mac
         https://bugs.webkit.org/show_bug.cgi?id=113125

         Reviewed by Mark Hahnenberg

         Remove the test added in r146682 as it's now failing on Mac.
         This is the test that was causing a compilation failure on Windows.

         * API/tests/testapi.c:
         (main):

 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

         Fix the typo: WIN -> WINDOWS.

         * API/tests/testapi.c:
         (main):

 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

         I really can't figure out what's wrong with this one.
         Temporarily disable the test added by r146682 on Windows since it doesn't compile.

         * API/tests/testapi.c:
         (main):

 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

         Another build fix (after r146693) for r146682.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-03-22  Roger Fong  <roger_fong@apple.com>

         Unreviewed. AppleWin build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
         * JavaScriptCore.vcxproj/copy-files.cmd:

 2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>

         -[TinyDOMNode dealloc] should call [super dealloc] when ARC is not enabled
         https://bugs.webkit.org/show_bug.cgi?id=113054

         Reviewed by Geoffrey Garen.

         * API/tests/testapi.mm:
         (-[TinyDOMNode dealloc]):

 2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>

         opaqueJSClassData should be cached on JSGlobalObject, not the JSGlobalData
         https://bugs.webkit.org/show_bug.cgi?id=113086

         Reviewed by Geoffrey Garen.

         opaqueJSClassData stores cached prototypes for JSClassRefs in the C API. It doesn't make sense to
         share these prototypes within a JSGlobalData across JSGlobalObjects, and in fact doing so will cause
         a leak of the original JSGlobalObject that these prototypes were created in. Therefore we should move
         this cache to JSGlobalObject where it belongs and where it won't cause memory leaks.

         * API/JSBase.cpp: Needed to add an extern "C" so that testapi.c can use the super secret GC function.
         * API/JSClassRef.cpp: We now grab the cached context data from the global object rather than the global data.
         (OpaqueJSClass::contextData):
         * API/JSClassRef.h: Remove this header because it's unnecessary and causes circular dependencies.
         * API/tests/testapi.c: Added a new test that makes sure that using the same JSClassRef in two different contexts
         doesn't cause leaks of the original global object.
         (leakFinalize):
         (nestedAllocateObject): This is a hack to bypass the conservative scan of the GC, which was unnecessarily marking
         objects and keeping them alive, ruining the test result.
         (testLeakingPrototypesAcrossContexts):
         (main):
         * API/tests/testapi.mm: extern "C" this so we can continue using it here.
         * runtime/JSGlobalData.cpp: Remove JSClassRef related stuff.
         (JSC::JSGlobalData::~JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSGlobalObject.h: Add the stuff that JSGlobalData had. We add it to JSGlobalObjectRareData so that
         clients who don't use the C API don't have to pay the memory cost of this extra HashMap.
         (JSGlobalObject):
         (JSGlobalObjectRareData):
         (JSC::JSGlobalObject::opaqueJSClassData):

 2013-03-19  Martin Robinson  <mrobinson@igalia.com>

         [GTK] Add support for building the WebCore bindings to the gyp build
         https://bugs.webkit.org/show_bug.cgi?id=112638

         Reviewed by Nico Weber.

         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Export all include directories to direct
         dependents and fix the indentation of the libjavascriptcore target.

 2013-03-21  Filip Pizlo  <fpizlo@apple.com>

         Fix some minor issues in the DFG's profiling of heap accesses
         https://bugs.webkit.org/show_bug.cgi?id=113010

         Reviewed by Goeffrey Garen.

         1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.

         2) If a CodeBlock clears a structure stub during GC, it should record this, and
         the DFG should prefer to not inline that access (i.e. treat it as if it had an
         exit site).

         3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
         but it chose not to, then assume that it will take slow path.

         4) If we frequently exited because of a structure check on a weak constant,
         don't try to inline that access in the future.

         5) Treat all exits that were counted as being frequent.

         81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::finalizeUnconditionally):
         (JSC):
         (JSC::CodeBlock::resetStubDuringGCInternal):
         (JSC::CodeBlock::reoptimize):
         (JSC::CodeBlock::jettison):
         (JSC::ProgramCodeBlock::jettisonImpl):
         (JSC::EvalCodeBlock::jettisonImpl):
         (JSC::FunctionCodeBlock::jettisonImpl):
         (JSC::CodeBlock::tallyFrequentExitSites):
         * bytecode/CodeBlock.h:
         (CodeBlock):
         (JSC::CodeBlock::tallyFrequentExitSites):
         (ProgramCodeBlock):
         (EvalCodeBlock):
         (FunctionCodeBlock):
         * bytecode/GetByIdStatus.cpp:
         (JSC::GetByIdStatus::computeFor):
         * bytecode/PutByIdStatus.cpp:
         (JSC::PutByIdStatus::computeFor):
         * bytecode/StructureStubInfo.h:
         (JSC::StructureStubInfo::StructureStubInfo):
         (StructureStubInfo):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleGetById):
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGOSRExit.cpp:
         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
         * dfg/DFGOSRExit.h:
         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
         (OSRExit):
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION):
         * runtime/Options.h:
         (JSC):

 2013-03-22  Filip Pizlo  <fpizlo@apple.com>

         DFG folding of PutById to SimpleReplace should consider the specialized function case
         https://bugs.webkit.org/show_bug.cgi?id=113093

         Reviewed by Geoffrey Garen and Mark Hahnenberg.

         * bytecode/PutByIdStatus.cpp:
         (JSC::PutByIdStatus::computeFor):

 2013-03-22  David Kilzer  <ddkilzer@apple.com>

         BUILD FIX (r146558): Build testapi.mm with ARC enabled for armv7s
         <http://webkit.org/b/112608>

         Fixes the following build failure:

             Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
             }
             ^
             1 error generated.

         * Configurations/ToolExecutable.xcconfig: Enable ARC for armv7s
         architecture.

 2013-03-22  David Kilzer  <ddkilzer@apple.com>

         Revert "BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]"

         This fixes a build failure introduced by this change:

             Source/JavaScriptCore/API/tests/testapi.mm:206:6: error: ARC forbids explicit message send of 'dealloc'
                 [super dealloc];
                  ^     ~~~~~~~
             1 error generated.

         Not sure why this didn't fail locally on my Mac Pro.

         * API/tests/testapi.mm:
         (-[TinyDOMNode dealloc]): Remove call to [super dealloc].

 2013-03-22  David Kilzer  <ddkilzer@apple.com>

         BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]
         <http://webkit.org/b/112608>

         Fixes the following build failure:

             Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
             }
             ^
             1 error generated.

         * API/tests/testapi.mm:
         (-[TinyDOMNode dealloc]): Call [super dealloc].

 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

         Leak bots erroneously report JSC::WatchpointSet as leaking
         https://bugs.webkit.org/show_bug.cgi?id=107781

         Reviewed by Filip Pizlo.

         Since leaks doesn't support tagged pointers, avoid using it by flipping the bit flag to indicate
         the entry is "fat". We set the flag when the entry is NOT fat; i.e. slim.

         Replaced FatFlag by SlimFlag and initialized m_bits with this flag to indicate that the entry is
         initially "slim".

         * runtime/SymbolTable.cpp:
         (JSC::SymbolTableEntry::copySlow): Don't set FatFlag since it has been replaced by SlimFlag.
         (JSC::SymbolTableEntry::inflateSlow): Ditto.

         * runtime/SymbolTable.h:
         (JSC::SymbolTableEntry::Fast::Fast): Set SlimFlag by default.
         (JSC::SymbolTableEntry::Fast::isNull): Ignore SlimFlag.
         (JSC::SymbolTableEntry::Fast::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag
         is not set.

         (JSC::SymbolTableEntry::SymbolTableEntry): Set SlimFlag by default.
         (JSC::SymbolTableEntry::SymbolTableEntry::getFast): Set SlimFlag when creating Fast from a fat entry.
         (JSC::SymbolTableEntry::isNull): Ignore SlimFlag.
         (JSC::SymbolTableEntry::FatEntry::FatEntry): Strip SlimFlag.
         (JSC::SymbolTableEntry::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag is unset.
         (JSC::SymbolTableEntry::fatEntry): Don't strip FatFlag as this flag doesn't exist anymore.
         (JSC::SymbolTableEntry::pack): Preserve SlimFlag.

         (JSC::SymbolTableIndexHashTraits): empty value is no longer zero so don't set emptyValueIsZero true.

 2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Need a good way to preserve custom properties on JS wrappers
         https://bugs.webkit.org/show_bug.cgi?id=112608

         Reviewed by Geoffrey Garen.

         Currently, we just use a weak map, which means that garbage collection can cause a wrapper to
         disappear if it isn't directly exported to JavaScript.

         The most straightforward and safe way (with respect to garbage collection and concurrency) is to have
         clients add and remove their external references along with their owners. Effectively, the client is
         recording the structure of the external object graph so that the garbage collector can make sure to
         mark any wrappers that are reachable through either the JS object graph of the external Obj-C object
         graph. By keeping these wrappers alive, this has the effect that custom properties on these wrappers
         will also remain alive.

         The rule for if an object needs to be tracked by the runtime (and therefore whether the client should report it) is as follows:
         For a particular object, its references to its children should be added if:
         1. The child is referenced from JavaScript.
         2. The child contains references to other objects for which (1) or (2) are true.

         * API/JSAPIWrapperObject.mm:
         (JSAPIWrapperObjectHandleOwner::finalize):
         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots): A wrapper object is kept alive only if its JSGlobalObject
         is marked and its corresponding Objective-C object was added to the set of opaque roots.
         (JSC::JSAPIWrapperObject::visitChildren): We now call out to scanExternalObjectGraph, which handles adding all Objective-C
         objects to the set of opaque roots.
         * API/JSAPIWrapperObject.h:
         (JSAPIWrapperObject):
         * API/JSContext.mm: Moved dealloc to its proper place in the main implementation.
         (-[JSContext dealloc]):
         * API/JSVirtualMachine.h:
         * API/JSVirtualMachine.mm:
         (-[JSVirtualMachine initWithContextGroupRef:]):
         (-[JSVirtualMachine dealloc]):
         (getInternalObjcObject): Helper funciton to get the Objective-C object out of JSManagedValues or JSValues if there is one.
         (-[JSVirtualMachine addManagedReference:withOwner:]): Adds the Objective-C object to the set of objects
         owned by the owner object in that particular virtual machine.
         (-[JSVirtualMachine removeManagedReference:withOwner:]): Removes the relationship between the two objects.
         (-[JSVirtualMachine externalObjectGraph]):
         (scanExternalObjectGraph): Does a depth-first search of the external object graph in a particular virtual machine starting at
         the specified root. Each new object it encounters it adds to the set of opaque roots. These opaque roots will keep their
         corresponding wrapper objects alive if they have them.
         * API/JSManagedReferenceInternal.h: Added.
         * API/JSVirtualMachine.mm: Added the per-JSVirtualMachine map between objects and the objects they own, which is more formally
         known as that virtual machine's external object graph.
         * API/JSWrapperMap.mm:
         (-[JSWrapperMap dealloc]): We were leaking this before :-(
         (-[JSVirtualMachine initWithContextGroupRef:]):
         (-[JSVirtualMachine dealloc]):
         (-[JSVirtualMachine externalObjectGraph]):
         * API/JSVirtualMachineInternal.h:
         * API/tests/testapi.mm: Added two new tests using the TinyDOMNode class. The first tests that a custom property added to a wrapper
         doesn't vanish after GC, even though that wrapper isn't directly accessible to the JS garbage collector but is accessible through
         the external Objective-C object graph. The second test makes sure that adding an object to the external object graph with the same
         owner doesn't cause any sort of problems.
         (+[TinyDOMNode sharedVirtualMachine]):
         (-[TinyDOMNode init]):
         (-[TinyDOMNode dealloc]):
         (-[TinyDOMNode appendChild:]):
         (-[TinyDOMNode numberOfChildren]):
         (-[TinyDOMNode childAtIndex:]):
         (-[TinyDOMNode removeChildAtIndex:]):
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * heap/SlotVisitor.h:
         (SlotVisitor):
         * heap/SlotVisitorInlines.h:
         (JSC::SlotVisitor::containsOpaqueRootTriState): Added a new method to SlotVisitor to allow scanExternalObjectGraph to have a
         thread-safe view of opaque roots during parallel marking. The set of opaque roots available to any one SlotVisitor isn't guaranteed
         to be 100% correct, but that just results in a small duplication of work in scanExternalObjectGraph. To indicate this change for
         false negatives we return a TriState that's either true or mixed, but never false.

 2013-03-21  Mark Lam  <mark.lam@apple.com>

         Fix O(n^2) op_debug bytecode charPosition to column computation.
         https://bugs.webkit.org/show_bug.cgi?id=112957.

         Reviewed by Geoffrey Garen.

         The previous algorithm does a linear reverse scan of the source string
         to find the line start for any given char position. This results in a
         O(n^2) algortithm when the source string has no line breaks.

         The new algorithm computes a line start column table for a
         SourceProvider on first use. This line start table is used to fix up
         op_debug's charPosition operand into a column operand when an
         UnlinkedCodeBlock is linked into a CodeBlock. The initialization of
         the line start table is O(n), and the CodeBlock column fix up is
         O(log(n)).

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::CodeBlock): - do column fix up.
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::debug): - no need to do column fixup anymore.
         * interpreter/Interpreter.h:
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         * parser/SourceProvider.cpp:
         (JSC::SourceProvider::lineStarts):
         (JSC::charPositionExtractor):
         (JSC::SourceProvider::charPositionToColumnNumber):
         - initialize line start column table if needed.
         - look up line start for the given char position.
         * parser/SourceProvider.h:

 2013-03-21  Filip Pizlo  <fpizlo@apple.com>

         JSC profiler should have an at-a-glance report of the success of DFG optimization
         https://bugs.webkit.org/show_bug.cgi?id=112988

         Reviewed by Geoffrey Garen.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleCall):
         (JSC::DFG::ByteCodeParser::handleGetById):
         (JSC::DFG::ByteCodeParser::parseBlock):
         * profiler/ProfilerCompilation.cpp:
         (JSC::Profiler::Compilation::Compilation):
         (JSC::Profiler::Compilation::toJS):
         * profiler/ProfilerCompilation.h:
         (JSC::Profiler::Compilation::noticeInlinedGetById):
         (JSC::Profiler::Compilation::noticeInlinedPutById):
         (JSC::Profiler::Compilation::noticeInlinedCall):
         (Compilation):
         * runtime/CommonIdentifiers.h:

 2013-03-21  Mark Lam  <mark.lam@apple.com>

         Fix lexer charPosition computation when "rewind"ing the lexer.
         https://bugs.webkit.org/show_bug.cgi?id=112952.

         Reviewed by Michael Saboff.

         Changed the Lexer to no longer keep a m_charPosition. Instead, we compute
         currentCharPosition() from m_code and m_codeStartPlusOffset, where
         m_codeStartPlusOffset is the SourceProvider m_codeStart + the SourceCode
         start offset. This ensures that the charPosition is always in sync with
         m_code.

         * parser/Lexer.cpp:
         (JSC::::setCode):
         (JSC::::internalShift):
         (JSC::::shift):
         (JSC::::lex):
         * parser/Lexer.h:
         (JSC::Lexer::currentCharPosition):
         (JSC::::lexExpectIdentifier):

 2013-03-21  Alberto Garcia  <agarcia@igalia.com>

         [BlackBerry] GCActivityCallback: replace JSLock with JSLockHolder
         https://bugs.webkit.org/show_bug.cgi?id=112448

         Reviewed by Xan Lopez.

         This changed in r121381.

         * runtime/GCActivityCallbackBlackBerry.cpp:
         (JSC::DefaultGCActivityCallback::doWork):

 2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: wrapperClass holds a static JSClassRef, which causes JSGlobalObjects to leak
         https://bugs.webkit.org/show_bug.cgi?id=112856

         Reviewed by Geoffrey Garen.

         Through a very convoluted path that involves the caching of prototypes on the JSClassRef, we can leak
         JSGlobalObjects when inserting an Objective-C object into multiple independent JSContexts.

         * API/JSAPIWrapperObject.cpp: Removed.
         * API/JSAPIWrapperObject.h:
         (JSAPIWrapperObject):
         * API/JSAPIWrapperObject.mm: Copied from Source/JavaScriptCore/API/JSAPIWrapperObject.cpp. Made this an
         Objective-C++ file so that we can call release on the wrappedObject. Also added a WeakHandleOwner for
         JSAPIWrapperObjects. This will also be used in a future patch for https://bugs.webkit.org/show_bug.cgi?id=112608.
         (JSAPIWrapperObjectHandleOwner):
         (jsAPIWrapperObjectHandleOwner):
         (JSAPIWrapperObjectHandleOwner::finalize): This finalize replaces the old finalize that was done through
         the C API.
         (JSC::JSAPIWrapperObject::finishCreation): Allocate the WeakImpl. Balanced in finalize.
         (JSC::JSAPIWrapperObject::setWrappedObject): We now do the retain of the wrappedObject here rather than in random
         places scattered around JSWrapperMap.mm
         * API/JSObjectRef.cpp: Added some ifdefs for platforms that don't support the Obj-C API.
         (JSObjectGetPrivate): Ditto.
         (JSObjectSetPrivate): Ditto.
         (JSObjectGetPrivateProperty): Ditto.
         (JSObjectSetPrivateProperty): Ditto.
         (JSObjectDeletePrivateProperty): Ditto.
         * API/JSValueRef.cpp: Ditto.
         (JSValueIsObjectOfClass): Ditto.
         * API/JSWrapperMap.mm: Remove wrapperClass().
         (objectWithCustomBrand): Change to no longer use a parent class, which was only used to give the ability to
         finalize wrapper objects.
         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Change to no longer use wrapperClass().
         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Ditto.
         (tryUnwrapObjcObject): We now check if the object inherits from JSAPIWrapperObject.
         * API/tests/testapi.mm: Added a test that exports an Objective-C object to two different JSContexts and makes
         sure that the first one is collected properly by using a weak JSManagedValue for the wrapper in the first JSContext.
         * CMakeLists.txt: Build file modifications.
         * GNUmakefile.list.am: Ditto.
         * JavaScriptCore.gypi: Ditto.
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
         * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
         * runtime/JSGlobalObject.cpp: More ifdefs for unsupported platforms.
         (JSC::JSGlobalObject::reset): Ditto.
         (JSC::JSGlobalObject::visitChildren): Ditto.
         * runtime/JSGlobalObject.h: Ditto.
         (JSGlobalObject): Ditto.
         (JSC::JSGlobalObject::objcCallbackFunctionStructure): Ditto.

 2013-03-21  Anton Muhin  <antonm@chromium.org>

         Unreviewed, rolling out r146483.
         http://trac.webkit.org/changeset/146483
         https://bugs.webkit.org/show_bug.cgi?id=111695

         Breaks debug builds.

         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.

 2013-03-21  Gabor Rapcsanyi  <rgabor@webkit.org>

         Implement LLInt for CPU(ARM_TRADITIONAL)
         https://bugs.webkit.org/show_bug.cgi?id=97589

         Reviewed by Zoltan Herczeg.

         Enable LLInt for ARMv5 and ARMv7 traditional as well.

         * llint/LLIntOfflineAsmConfig.h:
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * offlineasm/arm.rb:
         * offlineasm/backends.rb:
         * offlineasm/instructions.rb:

 2013-03-20  Cosmin Truta  <ctruta@blackberry.com>

         [QNX][ARM] REGRESSION(r135330): Various failures in Octane
         https://bugs.webkit.org/show_bug.cgi?id=112863

         Reviewed by Yong Li.

         This was fixed in http://trac.webkit.org/changeset/146396 on Linux only.
         Enable this fix on QNX.

         * assembler/ARMv7Assembler.h:
         (ARMv7Assembler):
         (JSC::ARMv7Assembler::replaceWithJump):
         (JSC::ARMv7Assembler::maxJumpReplacementSize):
         * assembler/MacroAssemblerARMv7.h:
         (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):

 2013-03-20  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation of JSString.h

         Rubber stamped by Mark Hahnenberg.

         * runtime/JSString.h:

 2013-03-20  Filip Pizlo  <fpizlo@apple.com>

         "" + x where x is not a string should be optimized by the DFG to some manner of ToString conversion
         https://bugs.webkit.org/show_bug.cgi?id=112845

         Reviewed by Mark Hahnenberg.

         I like to do "" + x. So I decided to make DFG recognize it, and related idioms.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::fixupToPrimitive):
         (FixupPhase):
         (JSC::DFG::FixupPhase::fixupToString):
         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::resultOfToPrimitive):
         (DFG):
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGPredictionPropagationPhase.h:
         (DFG):

 2013-03-20  Zoltan Herczeg  <zherczeg@webkit.org>

         ARMv7 replaceWithJump ASSERT failure after r135330.
         https://bugs.webkit.org/show_bug.cgi?id=103146

         Reviewed by Filip Pizlo.

         On Linux, the 24 bit distance range of jumps sometimes does not
         enough to cover all targets addresses. This patch supports jumps
         outside of this range using a mov/movt/bx 10 byte long sequence.

         * assembler/ARMv7Assembler.h:
         (ARMv7Assembler):
         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
         (JSC::ARMv7Assembler::nopw):
         (JSC::ARMv7Assembler::label):
         (JSC::ARMv7Assembler::replaceWithJump):
         (JSC::ARMv7Assembler::maxJumpReplacementSize):
         * assembler/MacroAssemblerARMv7.h:
         (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):

 2013-03-20  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Fix over-releasing in allocateConstructorAndPrototypeWithSuperClassInfo:
         https://bugs.webkit.org/show_bug.cgi?id=112832

         Reviewed by Geoffrey Garen.

         If either the m_constructor or m_prototype (but not both) is collected, we will call
         allocateConstructorAndPrototypeWithSuperClassInfo, which will create a new object to replace the one
         that was collected, but at the end of the method we call release on both of them.
         This is incorrect since we autorelease the JSValue in the case that the object doesn't need to be
         reallocated. Thus we'll end up overreleasing later during the drain of the autorelease pool.

         * API/JSWrapperMap.mm:
         (objectWithCustomBrand): We no longer alloc here. We instead call the JSValue valueWithValue class method,
         which autoreleases for us.
         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We no longer call release on the
         constructor or prototype JSValues.
         * API/tests/testapi.mm: Added a new test that crashes on ToT due to over-releasing.

 2013-03-19  Filip Pizlo  <fpizlo@apple.com>

         It's called "Hash Consing" not "Hash Consting"
         https://bugs.webkit.org/show_bug.cgi?id=112768

         Rubber stamped by Mark Hahnenberg.

         See http://en.wikipedia.org/wiki/Hash_consing

         * heap/GCThreadSharedData.cpp:
         (JSC::GCThreadSharedData::GCThreadSharedData):
         (JSC::GCThreadSharedData::reset):
         * heap/GCThreadSharedData.h:
         (GCThreadSharedData):
         * heap/SlotVisitor.cpp:
         (JSC::SlotVisitor::SlotVisitor):
         (JSC::SlotVisitor::setup):
         (JSC::SlotVisitor::reset):
         (JSC::JSString::tryHashConsLock):
         (JSC::JSString::releaseHashConsLock):
         (JSC::JSString::shouldTryHashCons):
         (JSC::SlotVisitor::internalAppend):
         * heap/SlotVisitor.h:
         (SlotVisitor):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         (JSC::JSGlobalData::haveEnoughNewStringsToHashCons):
         (JSC::JSGlobalData::resetNewStringsSinceLastHashCons):
         * runtime/JSString.h:
         (JSC::JSString::finishCreation):
         (JSString):
         (JSC::JSString::isHashConsSingleton):
         (JSC::JSString::clearHashConsSingleton):
         (JSC::JSString::setHashConsSingleton):

 2013-03-20  Filip Pizlo  <fpizlo@apple.com>

         DFG implementation of op_strcat should inline rope allocations
         https://bugs.webkit.org/show_bug.cgi?id=112780

         Reviewed by Oliver Hunt.

         This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can
         take either two or three operands, and allocates a rope string with either two or
         three fibers. (The magic choice of three children for non-VarArg nodes happens to
         match exactly with the magic choice of three fibers for rope strings.)

         ValueAdd on KnownString is replaced with MakeRope with two children.

         StrCat gets replaced by an appropriate sequence of MakeRope's.

         MakeRope does not do the dynamic check to see if its children are empty strings.
         This is replaced by a static check, instead. The downside is that we may use more
         memory if the strings passed to MakeRope turn out to dynamically be empty. The
         upside is that we do fewer checks in the cases where either the strings are not
         empty, or where the strings are statically known to be empty. I suspect both of
         those cases are more common, than the case where the string is dynamically empty.

         This also results in some badness for X86. MakeRope needs six registers if it is
         allocating a three-rope. We don't have six registers to spare on X86. Currently,
         the code side-steps this problem by just never usign three-ropes in optimized
         code on X86. All other architectures, including X86_64, don't have this problem.

         This is a shocking speed-up. 9% progressions on both V8/splay and
         SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression
         on SunSpider. 2x speed-up on microbenchmarks that test op_strcat.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGAdjacencyList.h:
         (AdjacencyList):
         (JSC::DFG::AdjacencyList::removeEdge):
         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
         * dfg/DFGBackwardsPropagationPhase.cpp:
         (JSC::DFG::BackwardsPropagationPhase::propagate):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::putStructureStoreElimination):
         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGDCEPhase.cpp:
         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::createToString):
         (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
         (JSC::DFG::FixupPhase::convertStringAddUse):
         (FixupPhase):
         (JSC::DFG::FixupPhase::convertToMakeRope):
         (JSC::DFG::FixupPhase::fixupMakeRope):
         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileAdd):
         (JSC::DFG::SpeculativeJIT::compileMakeRope):
         (DFG):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):
         (SpeculativeJIT):
         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
         (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand):
         (JSC::DFG::SpeculateCellOperand::gpr):
         (JSC::DFG::SpeculateCellOperand::use):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * runtime/JSString.h:
         (JSRopeString):

 2013-03-20  Peter Gal  <galpeter@inf.u-szeged.hu>

         Implement and32 on MIPS platform
         https://bugs.webkit.org/show_bug.cgi?id=112665

         Reviewed by Zoltan Herczeg.

         * assembler/MacroAssemblerMIPS.h:
         (JSC::MacroAssemblerMIPS::and32): Added missing method.
         (MacroAssemblerMIPS):

 2013-03-20  Mark Lam  <mark.lam@apple.com>

         Fix incorrect debugger column number value.
         https://bugs.webkit.org/show_bug.cgi?id=112741.

         Reviewed by Oliver Hunt.

         1. In lexer, parser, and debugger code, renamed column to charPosition.
         2. Convert the charPosition to the equivalent column number before
            passing it to the debugger.
         3. Changed ScopeNodes to take both a startLocation and an endLocation.
            This allows FunctionBodyNodes, ProgramNodes, and EvalNodess to emit
            correct debug hooks with correct starting line and column numbers.
         4. Fixed the Lexer to not reset the charPosition (previously
            columnNumber) in Lexer::lex().

         * JavaScriptCore.order:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitDebugHook):
         * bytecompiler/BytecodeGenerator.h:
         (JSC::BytecodeGenerator::emitExpressionInfo):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::ArrayNode::toArgumentList):
         (JSC::ConstStatementNode::emitBytecode):
         (JSC::EmptyStatementNode::emitBytecode):
         (JSC::DebuggerStatementNode::emitBytecode):
         (JSC::ExprStatementNode::emitBytecode):
         (JSC::VarStatementNode::emitBytecode):
         (JSC::IfNode::emitBytecode):
         (JSC::IfElseNode::emitBytecode):
         (JSC::DoWhileNode::emitBytecode):
         (JSC::WhileNode::emitBytecode):
         (JSC::ForNode::emitBytecode):
         (JSC::ForInNode::emitBytecode):
         (JSC::ContinueNode::emitBytecode):
         (JSC::BreakNode::emitBytecode):
         (JSC::ReturnNode::emitBytecode):
         (JSC::WithNode::emitBytecode):
         (JSC::SwitchNode::emitBytecode):
         (JSC::LabelNode::emitBytecode):
         (JSC::ThrowNode::emitBytecode):
         (JSC::TryNode::emitBytecode):
         (JSC::ProgramNode::emitBytecode):
         (JSC::EvalNode::emitBytecode):
         (JSC::FunctionBodyNode::emitBytecode):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::debug):
         - convert charPosition to column for the debugger.
         * interpreter/Interpreter.h:
         * jit/JITStubs.cpp:
         (DEFINE_STUB_FUNCTION(void, op_debug)):
         * llint/LLIntSlowPaths.cpp:
         (LLINT_SLOW_PATH_DECL(slow_op_debug)):
         * parser/ASTBuilder.h:
         (JSC::ASTBuilder::createFunctionExpr):
         (JSC::ASTBuilder::createFunctionBody):
         (JSC::ASTBuilder::createGetterOrSetterProperty):
         (JSC::ASTBuilder::createFuncDeclStatement):
         (JSC::ASTBuilder::createBlockStatement):
         (JSC::ASTBuilder::createExprStatement):
         (JSC::ASTBuilder::createIfStatement):
         (JSC::ASTBuilder::createForLoop):
         (JSC::ASTBuilder::createForInLoop):
         (JSC::ASTBuilder::createVarStatement):
         (JSC::ASTBuilder::createReturnStatement):
         (JSC::ASTBuilder::createBreakStatement):
         (JSC::ASTBuilder::createContinueStatement):
         (JSC::ASTBuilder::createTryStatement):
         (JSC::ASTBuilder::createSwitchStatement):
         (JSC::ASTBuilder::createWhileStatement):
         (JSC::ASTBuilder::createDoWhileStatement):
         (JSC::ASTBuilder::createWithStatement):
         (JSC::ASTBuilder::createThrowStatement):
         (JSC::ASTBuilder::createDebugger):
         (JSC::ASTBuilder::createConstStatement):
         * parser/Lexer.cpp:
         (JSC::::setCode):
         (JSC::::internalShift):
         (JSC::::shift):
         (JSC::::lex):
         * parser/Lexer.h:
         (JSC::Lexer::currentCharPosition):
         (Lexer):
         (JSC::::lexExpectIdentifier):
         * parser/NodeConstructors.h:
         (JSC::Node::Node):
         * parser/Nodes.cpp:
         (JSC::StatementNode::setLoc):
         (JSC::ScopeNode::ScopeNode):
         (JSC::ProgramNode::ProgramNode):
         (JSC::ProgramNode::create):
         (JSC::EvalNode::EvalNode):
         (JSC::EvalNode::create):
         (JSC::FunctionBodyNode::FunctionBodyNode):
         (JSC::FunctionBodyNode::create):
         * parser/Nodes.h:
         (JSC::Node::charPosition):
         (Node):
         (StatementNode):
         (JSC::StatementNode::lastLine):
         (ScopeNode):
         (JSC::ScopeNode::startLine):
         (JSC::ScopeNode::startCharPosition):
         (ProgramNode):
         (EvalNode):
         (FunctionBodyNode):
         * parser/Parser.cpp:
         (JSC::::Parser):
         (JSC::::parseFunctionBody):
         (JSC::::parseFunctionInfo):
         * parser/Parser.h:
         (JSC::::parse):
         * parser/ParserTokens.h:
         (JSC::JSTokenLocation::JSTokenLocation):
         (JSTokenLocation):
         * parser/SyntaxChecker.h:
         (JSC::SyntaxChecker::createFunctionBody):

 2013-03-20  Csaba Osztrogonác  <ossy@webkit.org>

         REGRESSION(r146089): It broke 20 sputnik tests on ARM traditional and Thumb2
         https://bugs.webkit.org/show_bug.cgi?id=112676

         Rubber-stamped by Filip Pizlo.

         Add one more EABI_32BIT_DUMMY_ARG to make DFG JIT ARM EABI compatible
         again after r146089 similar to https://bugs.webkit.org/show_bug.cgi?id=84449

         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):

 2013-03-19  Michael Saboff  <msaboff@apple.com>

         Crash when loading http://www.jqchart.com/jquery/gauges/RadialGauge/LiveData
         https://bugs.webkit.org/show_bug.cgi?id=112694

         Reviewed by Filip Pizlo.

         We were trying to convert an NewArray to a Phantom, but convertToPhantom doesn't handle
         nodes with variable arguments.  Added code to insert a Phantom node in front of all the
         live children of a var args node.  Added ASSERT not var args for convertToPhantom to
         catch any other similar cases.  Added a new convertToPhantomUnchecked() for converting
         var arg nodes.

         * dfg/DFGDCEPhase.cpp:
         (JSC::DFG::DCEPhase::run):
         * dfg/DFGNode.h:
         (Node):
         (JSC::DFG::Node::setOpAndDefaultNonExitFlags): Added ASSERT(!(m_flags & NodeHasVarArgs))
         (JSC::DFG::Node::setOpAndDefaultNonExitFlagsUnchecked):
         (JSC::DFG::Node::convertToPhantomUnchecked):

 2013-03-19  Mark Hahnenberg  <mhahnenberg@apple.com>

         Crash in SpeculativeJIT::fillSpeculateIntInternal<false> on http://bellard.org/jslinux
         https://bugs.webkit.org/show_bug.cgi?id=112738

         Reviewed by Filip Pizlo.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixIntEdge): We shouldn't be killing this node because it could be
         referenced by other people.

 2013-03-19  Oliver Hunt  <oliver@apple.com>

         RELEASE_ASSERT fires in exception handler lookup

         RS=Geoff Garen.

         Temporarily switch this RELEASE_ASSERT into a regular ASSERT
         as currently this is producing fairly bad crashiness.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::handlerForBytecodeOffset):

 2013-03-18  Filip Pizlo  <fpizlo@apple.com>

         DFG should optimize StringObject.length and StringOrStringObject.length
         https://bugs.webkit.org/show_bug.cgi?id=112658

         Reviewed by Mark Hahnenberg.

         Implemented by injecting a ToString(StringObject:@a) or ToString(StringOrStringObject:@a) prior
         to GetArrayLength with ArrayMode(Array::String) if @a is predicted StringObject or
         StringOrStringObject.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::createToString):
         (FixupPhase):
         (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
         (JSC::DFG::FixupPhase::convertStringAddUse):

 2013-03-19  Gabor Rapcsanyi  <rgabor@webkit.org>

         Implement and32 on ARMv7 and ARM traditional platforms
         https://bugs.webkit.org/show_bug.cgi?id=112663

         Reviewed by Zoltan Herczeg.

         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::and32): Add missing method.
         (MacroAssemblerARM):
         * assembler/MacroAssemblerARMv7.h:
         (JSC::MacroAssemblerARMv7::and32): Add missing method.
         (MacroAssemblerARMv7):

 2013-03-18  Filip Pizlo  <fpizlo@apple.com>

         DFG ToString generic cases should work correctly
         https://bugs.webkit.org/show_bug.cgi?id=112654
         <rdar://problem/13447250>

         Reviewed by Geoffrey Garen.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-18  Michael Saboff  <msaboff@apple.com>

         Unreviewed build fix for 32 bit builds.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-18  Michael Saboff  <msaboff@apple.com>

         EFL: Unsafe branch detected in compilePutByValForFloatTypedArray()
         https://bugs.webkit.org/show_bug.cgi?id=112609

         Reviewed by Geoffrey Garen.

         Created local valueFPR and scratchFPR and filled them with valueOp.fpr() and scratch.fpr()
         respectively so that if valueOp.fpr() causes a spill during allocation, it occurs before the
         branch and also to follow convention.  Added register allocation checks to FPRTemporary.
         Cleaned up a couple of other places to follow the "AllocatVirtualRegType foo, get machine
         reg from foo" pattern.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::fprAllocate):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::convertToDouble):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-18  Filip Pizlo  <fpizlo@apple.com>

         DFG should inline binary string concatenations (i.e. ValueAdd with string children)
         https://bugs.webkit.org/show_bug.cgi?id=112599

         Reviewed by Oliver Hunt.

         This does as advertised: if you do x + y where x and y are strings, you'll get
         a fast inlined JSRopeString allocation (along with whatever checks are necessary).
         It also does good things if either x or y (or both) are StringObjects, or some
         other thing like StringOrStringObject. It also lays the groundwork for making this
         fast if either x or y are numbers, or some other reasonably-cheap-to-convert
         value.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (FixupPhase):
         (JSC::DFG::FixupPhase::isStringObjectUse):
         (JSC::DFG::FixupPhase::convertStringAddUse):
         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileAdd):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):
         (SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
         * runtime/JSString.h:
         (JSC::JSString::offsetOfFlags):
         (JSString):
         (JSRopeString):
         (JSC::JSRopeString::offsetOfFibers):

 2013-03-18  Filip Pizlo  <fpizlo@apple.com>

         JSC_NATIVE_FUNCTION() takes an identifier for the name and then uses #name, which is unsafe if name was already #define'd to something else
         https://bugs.webkit.org/show_bug.cgi?id=112639

         Reviewed by Michael Saboff.

         Change it to take a string instead.

         * runtime/JSObject.h:
         (JSC):
         * runtime/ObjectPrototype.cpp:
         (JSC::ObjectPrototype::finishCreation):
         * runtime/StringPrototype.cpp:
         (JSC::StringPrototype::finishCreation):

 2013-03-18  Brent Fulgham  <bfulgham@webkit.org>

         [WinCairo] Get build working under VS2010.
         https://bugs.webkit.org/show_bug.cgi?id=112604

         Reviewed by Tim Horton.

         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Use CFLite-specific
         build target (standard version links against CoreFoundation.lib
         instead of CFLite.lib).
         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Added.
         * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Added.
         * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Added.

 2013-03-18  Roger Fong  <roger_fong@apple.com>

         AppleWin VS2010 Debug configuration build fix..

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

 2013-03-18  Brent Fulgham  <bfulgham@webkit.org>

         [WinCairo] Get build working under VS2010.
         https://bugs.webkit.org/show_bug.cgi?id=112604

         Reviewed by Tim Horton.

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add build targets for
         Debug_WinCairo and Release_WinCairo using CFLite.
         * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
         Add Debug_WinCairo and Release_WinCairo build targets to
         make sure headers are copied to proper build folder.
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Ditto.
         * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Added.
         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
         Add Debug_WinCairo and Release_WinCairo build targets to
         make sure headers are copied to proper build folder.
         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
         Ditto.
         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
         Ditto.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto.
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto.
         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto.

 2013-03-18  Michael Saboff  <msaboff@apple.com>

         Potentially unsafe register allocations in DFG code generation
         https://bugs.webkit.org/show_bug.cgi?id=112477

         Reviewed by Geoffrey Garen.

         Moved allocation of temporary GPRs to be before any generated branches in the functions below.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):

 2013-03-15  Filip Pizlo  <fpizlo@apple.com>

         DFG string conversions and allocations should be inlined
         https://bugs.webkit.org/show_bug.cgi?id=112376

         Reviewed by Geoffrey Garen.

         This turns new String(), String(), String.prototype.valueOf(), and
         String.prototype.toString() into intrinsics. It gives the DFG the ability to handle
         conversions from StringObject to JSString and vice-versa, and also gives it the
         ability to handle cases where a variable may be either a StringObject or a JSString.
         To do this, I added StringObject to value profiling (and removed the stale
         distinction between Myarguments and Foreignarguments). I also cleaned up ToPrimitive
         handling, using some of the new functionality but also taking advantage of the
         existence of Identity(String:@a).

         This is a 2% SunSpider speed-up. Also there are some speed-ups on V8v7 and Kraken.
         On microbenchmarks that stress new String() this is a 14x speed-up.

         * CMakeLists.txt:
         * DerivedSources.make:
         * DerivedSources.pri:
         * GNUmakefile.list.am:
         * bytecode/CodeBlock.h:
         (CodeBlock):
         (JSC::CodeBlock::hasExitSite):
         (JSC):
         * bytecode/DFGExitProfile.cpp:
         (JSC::DFG::ExitProfile::hasExitSite):
         (DFG):
         * bytecode/DFGExitProfile.h:
         (ExitProfile):
         (JSC::DFG::ExitProfile::hasExitSite):
         * bytecode/ExitKind.cpp:
         (JSC::exitKindToString):
         * bytecode/ExitKind.h:
         * bytecode/SpeculatedType.cpp:
         (JSC::dumpSpeculation):
         (JSC::speculationToAbbreviatedString):
         (JSC::speculationFromClassInfo):
         * bytecode/SpeculatedType.h:
         (JSC):
         (JSC::isStringObjectSpeculation):
         (JSC::isStringOrStringObjectSpeculation):
         * create_hash_table:
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGAbstractState.h:
         (JSC::DFG::AbstractState::filterEdgeByUse):
         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::handleCall):
         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
         (DFG):
         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::putStructureStoreElimination):
         * dfg/DFGEdge.h:
         (JSC::DFG::Edge::shift):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
         (FixupPhase):
         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
         (JSC::DFG::FixupPhase::observeUseKindOnNode):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::hasGlobalExitSite):
         (Graph):
         (JSC::DFG::Graph::hasExitSite):
         (JSC::DFG::Graph::clobbersWorld):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::convertToToString):
         (Node):
         (JSC::DFG::Node::hasStructure):
         (JSC::DFG::Node::shouldSpeculateStringObject):
         (JSC::DFG::Node::shouldSpeculateStringOrStringObject):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
         (DFG):
         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
         (JSC::DFG::SpeculativeJIT::speculateObject):
         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
         (JSC::DFG::SpeculativeJIT::speculateString):
         (JSC::DFG::SpeculativeJIT::speculateStringObject):
         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
         (JSC::DFG::SpeculativeJIT::speculate):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):
         (SpeculativeJIT):
         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
         (DFG):
         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGUseKind.cpp:
         (WTF::printInternal):
         * dfg/DFGUseKind.h:
         (JSC::DFG::typeFilterFor):
         * interpreter/CallFrame.h:
         (JSC::ExecState::regExpPrototypeTable):
         * runtime/CommonIdentifiers.h:
         * runtime/Intrinsic.h:
         * runtime/JSDestructibleObject.h:
         (JSDestructibleObject):
         (JSC::JSDestructibleObject::classInfoOffset):
         * runtime/JSGlobalData.cpp:
         (JSC):
         (JSC::JSGlobalData::JSGlobalData):
         (JSC::JSGlobalData::~JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSObject.cpp:
         * runtime/JSObject.h:
         (JSC):
         * runtime/JSWrapperObject.h:
         (JSC::JSWrapperObject::allocationSize):
         (JSWrapperObject):
         (JSC::JSWrapperObject::internalValueOffset):
         (JSC::JSWrapperObject::internalValueCellOffset):
         * runtime/StringPrototype.cpp:
         (JSC):
         (JSC::StringPrototype::finishCreation):
         (JSC::StringPrototype::create):
         * runtime/StringPrototype.h:
         (StringPrototype):

 2013-03-18  Filip Pizlo  <fpizlo@apple.com>

         ObjectPrototype properties should be eagerly created rather than lazily via static tables
         https://bugs.webkit.org/show_bug.cgi?id=112539

         Reviewed by Oliver Hunt.

         This is the first part of https://bugs.webkit.org/show_bug.cgi?id=112233. Rolling this
         in first since it's the less-likely-to-be-broken part.

         * CMakeLists.txt:
         * DerivedSources.make:
         * DerivedSources.pri:
         * GNUmakefile.list.am:
         * interpreter/CallFrame.h:
         (JSC::ExecState::objectConstructorTable):
         * runtime/CommonIdentifiers.h:
         * runtime/JSGlobalData.cpp:
         (JSC):
         (JSC::JSGlobalData::JSGlobalData):
         (JSC::JSGlobalData::~JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSObject.cpp:
         (JSC::JSObject::putDirectNativeFunction):
         (JSC):
         * runtime/JSObject.h:
         (JSObject):
         (JSC):
         * runtime/Lookup.cpp:
         (JSC::setUpStaticFunctionSlot):
         * runtime/ObjectPrototype.cpp:
         (JSC):
         (JSC::ObjectPrototype::finishCreation):
         (JSC::ObjectPrototype::create):
         * runtime/ObjectPrototype.h:
         (ObjectPrototype):

 2013-03-16  Pratik Solanki  <psolanki@apple.com>

         Disable High DPI Canvas on iOS
         https://bugs.webkit.org/show_bug.cgi?id=112511

         Reviewed by Joseph Pecoraro.

         * Configurations/FeatureDefines.xcconfig:

 2013-03-15  Andreas Kling  <akling@apple.com>

         Don't also clone StructureRareData when cloning Structure.
         <http://webkit.org/b/111672>

         Reviewed by Mark Hahnenberg.

         We were cloning a lot of StructureRareData with only the previousID pointer set since
         the enumerationCache is not shared between clones.

         Let the Structure copy constructor decide whether it wants to clone the rare data.
         The decision is made by StructureRareData::needsCloning() and will currently always
         return false, since StructureRareData only holds on to caches at present.
         This may change in the future as more members are added to StructureRareData.

         * runtime/Structure.cpp:
         (JSC::Structure::Structure):
         (JSC::Structure::cloneRareDataFrom):
         * runtime/StructureInlines.h:
         (JSC::Structure::create):

 2013-03-15  Mark Hahnenberg  <mhahnenberg@apple.com>

         Roll out r145838
         https://bugs.webkit.org/show_bug.cgi?id=112458

         Unreviewed. Requested by Filip Pizlo.

         * CMakeLists.txt:
         * DerivedSources.make:
         * DerivedSources.pri:
         * GNUmakefile.list.am:
         * dfg/DFGOperations.cpp:
         * interpreter/CallFrame.h:
         (JSC::ExecState::objectPrototypeTable):
         * jit/JITStubs.cpp:
         (JSC::getByVal):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::getByVal):
         * runtime/CommonIdentifiers.h:
         * runtime/JSCell.cpp:
         (JSC):
         * runtime/JSCell.h:
         (JSCell):
         * runtime/JSCellInlines.h:
         (JSC):
         (JSC::JSCell::fastGetOwnProperty):
         * runtime/JSGlobalData.cpp:
         (JSC):
         (JSC::JSGlobalData::JSGlobalData):
         (JSC::JSGlobalData::~JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSObject.cpp:
         (JSC):
         * runtime/JSObject.h:
         (JSObject):
         (JSC):
         * runtime/Lookup.cpp:
         (JSC::setUpStaticFunctionSlot):
         * runtime/ObjectPrototype.cpp:
         (JSC):
         (JSC::ObjectPrototype::finishCreation):
         (JSC::ObjectPrototype::getOwnPropertySlot):
         (JSC::ObjectPrototype::getOwnPropertyDescriptor):
         * runtime/ObjectPrototype.h:
         (JSC::ObjectPrototype::create):
         (ObjectPrototype):
         * runtime/PropertyMapHashTable.h:
         (JSC::PropertyTable::findWithString):
         * runtime/Structure.h:
         (Structure):
         * runtime/StructureInlines.h:
         (JSC::Structure::get):

 2013-03-15  Michael Saboff  <msaboff@apple.com>

         Cleanup of DFG and Baseline JIT debugging code
         https://bugs.webkit.org/show_bug.cgi?id=111871

         Reviewed by Geoffrey Garen.

         Fixed various debug related issue in baseline and DFG JITs. See below.

         * dfg/DFGRepatch.cpp:
         (JSC::DFG::dfgLinkClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
         * dfg/DFGScratchRegisterAllocator.h: Now use ScratchBuffer::activeLengthPtr() to get
         pointer to scratch register length.
         (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
         (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::checkConsistency): Added missing case labels for DataFormatOSRMarker,
         DataFormatDead, and DataFormatArguments and made them RELEASE_ASSERT_NOT_REACHED();
         * jit/JITCall.cpp:
         (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
         * jit/JITCall32_64.cpp:
         (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
         * runtime/JSGlobalData.h:
         (JSC::ScratchBuffer::ScratchBuffer): Fixed buffer allocation alignment to
         be on a double boundary.
         (JSC::ScratchBuffer::setActiveLength):
         (JSC::ScratchBuffer::activeLength):
         (JSC::ScratchBuffer::activeLengthPtr):

 2013-03-15  Michael Saboff  <msaboff@apple.com>

         Add runtime check for improper register allocations in DFG
         https://bugs.webkit.org/show_bug.cgi?id=112380

         Reviewed by Geoffrey Garen.

         Added framework to check for register allocation within a branch source - target range.  All register allocations
         are saved using the offset in the code stream where the allocation occurred.  Later when a jump is linked, the
         currently saved register allocations are checked to make sure that they didn't occur in the range of code that was
         jumped over.  This protects against the case where an allocation could have spilled register contents to free up
         a register and that spill only occurs on one path of a many through the code.  A subsequent fill of the spilled
         register may load garbage.  See https://bugs.webkit.org/show_bug.cgi?id=111777 for one such bug.
         This code is protected by the compile time check of #if ENABLE(DFG_REGISTER_ALLOCATION_VALIDATION).
         The check is only done during the processing of SpeculativeJIT::compile(Node* node) and its callees.

         * assembler/AbstractMacroAssembler.h:
         (JSC::AbstractMacroAssembler::Jump::link): Invoke register allocation checks using source and target of link.
         (JSC::AbstractMacroAssembler::Jump::linkTo): Invoke register allocation checks using source and target of link.
         (AbstractMacroAssembler):
         (RegisterAllocationOffset): New helper class to store the instruction stream offset and compare against a
         jump range.
         (JSC::AbstractMacroAssembler::RegisterAllocationOffset::RegisterAllocationOffset):
         (JSC::AbstractMacroAssembler::RegisterAllocationOffset::check):
         (JSC::AbstractMacroAssembler::addRegisterAllocationAtOffset):
         (JSC::AbstractMacroAssembler::clearRegisterAllocationOffsets):
         (JSC::AbstractMacroAssembler::checkRegisterAllocationAgainstBranchRange):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::allocate):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-14  Oliver Hunt  <oliver@apple.com>

         REGRESSION(r145000): Crash loading arstechnica.com when Safari Web Inspector is open
         https://bugs.webkit.org/show_bug.cgi?id=111868

         Reviewed by Antti Koivisto.

         Don't allow non-local property lookup when the debugger is enabled.

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::resolve):

 2013-03-11  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Objective-C functions exposed to JavaScript have the wrong type (object instead of function)
         https://bugs.webkit.org/show_bug.cgi?id=105892

         Reviewed by Geoffrey Garen.

         Changed ObjCCallbackFunction to subclass JSCallbackFunction which already has all of the machinery to call
         functions using the C API. Since ObjCCallbackFunction is now a JSCell, we changed the old implementation of
         ObjCCallbackFunction to be the internal implementation and keep track of all the proper data so that we
         don't have to put all of that in the header, which will now be included from C++ files (e.g. JSGlobalObject.cpp).

         * API/JSCallbackFunction.cpp: Change JSCallbackFunction to allow subclassing. Originally it was internally
         passing its own Structure up the chain of constructors, but we now want to be able to pass other Structures as well.
         (JSC::JSCallbackFunction::JSCallbackFunction):
         (JSC::JSCallbackFunction::create):
         * API/JSCallbackFunction.h:
         (JSCallbackFunction):
         * API/JSWrapperMap.mm: Changed interface to tryUnwrapBlock.
         (tryUnwrapObjcObject):
         * API/ObjCCallbackFunction.h:
         (ObjCCallbackFunction): Moved into the JSC namespace, just like JSCallbackFunction.
         (JSC::ObjCCallbackFunction::createStructure): Overridden so that the correct ClassInfo gets used since we have
         a destructor.
         (JSC::ObjCCallbackFunction::impl): Getter for the internal impl.
         * API/ObjCCallbackFunction.mm:
         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): What used to be ObjCCallbackFunction is now
         ObjCCallbackFunctionImpl. It handles the Objective-C specific parts of managing callback functions.
         (JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl):
         (JSC::objCCallbackFunctionCallAsFunction): Same as the old one, but now it casts to ObjCCallbackFunction and grabs the impl
         rather than using JSObjectGetPrivate.
         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): New bits to allow being part of the JSCell hierarchy.
         (JSC::ObjCCallbackFunction::create):
         (JSC::ObjCCallbackFunction::destroy):
         (JSC::ObjCCallbackFunctionImpl::call): Handles the actual invocation, just like it used to.
         (objCCallbackFunctionForInvocation):
         (tryUnwrapBlock): Changed to check the ClassInfo for inheritance directly, rather than going through the C API call.
         * API/tests/testapi.mm: Added new test to make sure that doing Function.prototype.toString.call(f) won't result in
         an error when f is an Objective-C method or block underneath the covers.
         * runtime/JSGlobalObject.cpp: Added new Structure for ObjCCallbackFunction.
         (JSC::JSGlobalObject::reset):
         (JSC::JSGlobalObject::visitChildren):
         * runtime/JSGlobalObject.h:
         (JSGlobalObject):
         (JSC::JSGlobalObject::objcCallbackFunctionStructure):

 2013-03-14  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Nested dictionaries are not converted properly in the Objective-C binding
         https://bugs.webkit.org/show_bug.cgi?id=112377

         Reviewed by Oliver Hunt.

         Accidental reassignment of the root task in the container conversion logic was causing the last
         array or dictionary processed to be returned in the case of nested containers.

         * API/JSValue.mm:
         (containerValueToObject):
         * API/tests/testapi.mm:

 2013-03-13  Filip Pizlo  <fpizlo@apple.com>

         JSObject fast by-string access optimizations should work even on the prototype chain, and even when the result is undefined
         https://bugs.webkit.org/show_bug.cgi?id=112233

         Reviewed by Oliver Hunt.

         Extended the existing fast access path for String keys to work over the entire prototype chain,
         not just the self access case. This will fail as soon as it sees an object that intercepts
         getOwnPropertySlot, so this patch also ensures that ObjectPrototype does not fall into that
         category. This is accomplished by making ObjectPrototype eagerly reify all of its properties.
         This is safe for ObjectPrototype because it's so common and we expect all of its properties to
         be reified for any interesting programs anyway. A new idiom for adding native functions to
         prototypes is introduced, which ought to work well for any other prototypes that we wish to do
         this conversion for.

         This is a >60% speed-up in the case that you frequently do by-string lookups that "miss", i.e.
         they don't turn up anything.

         * CMakeLists.txt:
         * DerivedSources.make:
         * DerivedSources.pri:
         * GNUmakefile.list.am:
         * dfg/DFGOperations.cpp:
         * interpreter/CallFrame.h:
         (JSC::ExecState::objectConstructorTable):
         * jit/JITStubs.cpp:
         (JSC::getByVal):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::getByVal):
         * runtime/CommonIdentifiers.h:
         * runtime/JSCell.cpp:
         (JSC::JSCell::getByStringSlow):
         (JSC):
         * runtime/JSCell.h:
         (JSCell):
         * runtime/JSCellInlines.h:
         (JSC):
         (JSC::JSCell::getByStringAndKey):
         (JSC::JSCell::getByString):
         * runtime/JSGlobalData.cpp:
         (JSC):
         (JSC::JSGlobalData::JSGlobalData):
         (JSC::JSGlobalData::~JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSObject.cpp:
         (JSC::JSObject::putDirectNativeFunction):
         (JSC):
         * runtime/JSObject.h:
         (JSObject):
         (JSC):
         * runtime/Lookup.cpp:
         (JSC::setUpStaticFunctionSlot):
         * runtime/ObjectPrototype.cpp:
         (JSC):
         (JSC::ObjectPrototype::finishCreation):
         (JSC::ObjectPrototype::create):
         * runtime/ObjectPrototype.h:
         (ObjectPrototype):
         * runtime/PropertyMapHashTable.h:
         (JSC::PropertyTable::findWithString):
         * runtime/Structure.h:
         (Structure):
         * runtime/StructureInlines.h:
         (JSC::Structure::get):
         (JSC):

 2013-03-13  Filip Pizlo  <fpizlo@apple.com>

         DFG bytecode parser is too aggressive about getting rid of GetLocals on captured variables
         https://bugs.webkit.org/show_bug.cgi?id=112287
         <rdar://problem/13342340>

         Reviewed by Oliver Hunt.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::finalizeUnconditionally):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::getLocal):

 2013-03-13  Ryosuke Niwa  <rniwa@webkit.org>

         Threaded HTML Parser is missing feature define flags in all but Chromium port's build files
         https://bugs.webkit.org/show_bug.cgi?id=112277

         Reviewed by Adam Barth.

         * Configurations/FeatureDefines.xcconfig:

 2013-03-13  Csaba Osztrogonác  <ossy@webkit.org>

         LLINT C loop warning fix for GCC
         https://bugs.webkit.org/show_bug.cgi?id=112145

         Reviewed by Filip Pizlo.

         * llint/LowLevelInterpreter.cpp:
         (JSC::CLoop::execute):

 2013-02-13  Simon Hausmann  <simon.hausmann@digia.com>

         Add support for convenient conversion from JSStringRef to QString
         https://bugs.webkit.org/show_bug.cgi?id=109694

         Reviewed by Allan Sandfeld Jensen.

         Add JSStringCopyQString helper function that allows for the convenient
         extraction of a QString out of a JSStringRef.

         * API/JSStringRefQt.cpp: Added.
         (JSStringCopyQString):
         * API/JSStringRefQt.h: Added.
         * API/OpaqueJSString.h:
         (OpaqueJSString):
         (OpaqueJSString::qString):
         (OpaqueJSString::OpaqueJSString):
         * Target.pri:

 2013-03-13  Peter Gal  <galpeter@inf.u-szeged.hu>

         Token 'not' is ignored in the offlineasm.
         https://bugs.webkit.org/show_bug.cgi?id=111568

         Reviewed by Filip Pizlo.

         * offlineasm/parser.rb: Build the Not AST node if the 'not' token is found.

 2013-03-12  Tim Horton  <timothy_horton@apple.com>

         WTF uses macros for exports. Try to fix the Windows build. Unreviewed.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-03-12  Filip Pizlo  <fpizlo@apple.com>

         Array.prototype.sort should at least try to be PTIME even when the array is in some bizarre mode
         https://bugs.webkit.org/show_bug.cgi?id=112187
         <rdar://problem/13393550>

         Reviewed by Michael Saboff and Gavin Barraclough.

         If we have an array-like object in crazy mode passed into Array.prototype.sort, and its length is large,
         then first copy all elements into a separate, compact, un-holy array and sort that. Then copy back.
         This means that sorting will be at worst O(n^2) in the actual number of things in the array, rather than
         O(n^2) in the array's length.

         * runtime/ArrayPrototype.cpp:
         (JSC::attemptFastSort):
         (JSC::performSlowSort):
         (JSC):
         (JSC::arrayProtoFuncSort):

 2013-03-12  Tim Horton  <timothy_horton@apple.com>

         Try to fix the Windows build.

         Not reviewed.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-03-12  Geoffrey Garen  <ggaren@apple.com>

         Try to fix the Windows build.

         Not reviewed.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         Export a thing.

 2013-03-11  Oliver Hunt  <oliver@apple.com>

         Harden JSStringJoiner
         https://bugs.webkit.org/show_bug.cgi?id=112093

         Reviewed by Filip Pizlo.

         Harden JSStringJoiner, make it use our CheckedArithmetic
         class to simplify everything.

         * runtime/JSStringJoiner.cpp:
         (JSC::JSStringJoiner::build):
         * runtime/JSStringJoiner.h:
         (JSStringJoiner):
         (JSC::JSStringJoiner::JSStringJoiner):
         (JSC::JSStringJoiner::append):

 2013-03-12  Filip Pizlo  <fpizlo@apple.com>

         DFG generic array access cases should not be guarded by CheckStructure even of the profiling tells us that it could be
         https://bugs.webkit.org/show_bug.cgi?id=112183

         Reviewed by Oliver Hunt.

         Slight speed-up on string-unpack-code.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::findAndRemoveUnnecessaryStructureCheck):
         (FixupPhase):
         (JSC::DFG::FixupPhase::checkArray):
         (JSC::DFG::FixupPhase::blessArrayOperation):

 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>

         https://bugs.webkit.org/show_bug.cgi?id=112141
         LLInt CLoop backend misses Double2Ints() on 32bit architectures

         Reviewed by Filip Pizlo.

         Implement Double2Ints() in CLoop backend of LLInt on 32bit architectures.

         * llint/LowLevelInterpreter.cpp:
         (LLInt):
         (JSC::LLInt::Double2Ints):
         * offlineasm/cloop.rb:

 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>

         Making more sophisticated cache flush on ARM Linux platform
         https://bugs.webkit.org/show_bug.cgi?id=111854

         Reviewed by Zoltan Herczeg.

         The cache flush on ARM Linux invalidates whole pages
         instead of just the required area.

         * assembler/ARMAssembler.h:
         (ARMAssembler):
         (JSC::ARMAssembler::linuxPageFlush):
         (JSC::ARMAssembler::cacheFlush):
         * assembler/ARMv7Assembler.h:
         (ARMv7Assembler):
         (JSC::ARMv7Assembler::linuxPageFlush):
         (JSC::ARMv7Assembler::cacheFlush):

 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>

         Renaming the armv7.rb LLINT backend to arm.rb
         https://bugs.webkit.org/show_bug.cgi?id=110565

         Reviewed by Zoltan Herczeg.

         This is the first step of a unified ARM backend for
         all ARM 32 bit architectures in LLInt.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * LLIntOffsetsExtractor.pro:
         * offlineasm/arm.rb: Copied from Source/JavaScriptCore/offlineasm/armv7.rb.
         * offlineasm/armv7.rb: Removed.
         * offlineasm/backends.rb:
         * offlineasm/risc.rb:

 2013-03-12  Csaba Osztrogonác  <ossy@webkit.org>

         REGRESSION(r145482): It broke 33 jsc tests and zillion layout tests on all platform
         https://bugs.webkit.org/show_bug.cgi?id=112112

         Reviewed by Oliver Hunt.

         Rolling out https://trac.webkit.org/changeset/145482 to unbreak the bots.

         * runtime/JSStringJoiner.cpp:
         (JSC::JSStringJoiner::build):
         * runtime/JSStringJoiner.h:
         (JSStringJoiner):
         (JSC::JSStringJoiner::JSStringJoiner):
         (JSC::JSStringJoiner::append):

 2013-03-12  Filip Pizlo  <fpizlo@apple.com>

         DFG prediction propagation phase should not rerun forward propagation if double voting has already converged
         https://bugs.webkit.org/show_bug.cgi?id=111920

         Reviewed by Oliver Hunt.

         I don't know why we weren't exiting early after double voting if !m_changed.

         This change also removes backwards propagation from the voting fixpoint, since at that
         point short-circuiting loops is probably not particularly profitable. Profiling shows
         that this reduces the time spent in prediction propagation even further.

         This change appears to be a 1% SunSpider speed-up.

         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::run):

 2013-03-11  Filip Pizlo  <fpizlo@apple.com>

         DFG overflow check elimination is too smart for its own good
         https://bugs.webkit.org/show_bug.cgi?id=111832

         Reviewed by Oliver Hunt and Gavin Barraclough.

         Rolling this back in after fixing accidental misuse of JSValue. The code was doing value < someInt
         rather than value.asInt32() < someInt. This "worked" when isWithinPowerOfTwo wasn't templatized.
         It worked by always being false and always disabling the relvant optimization.

         This improves overflow check elimination in three ways:

         1) It reduces the amount of time the compiler will spend doing it.

         2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation
            over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children)
            are int32's and then perform a possibly-overflowing operation, we must be careful not to assume
            that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that
            @b->children are int32's and that hence @b might produce a large enough result that doubles would
            start chopping low bits. The specific implication of this is that for a binary operation to not
            propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one
            of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such
            operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the
            latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that
            large won't even make it into the DFG currently.

         3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub
            are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate
            NodeUsedAsNumber to either @a or @b.

         This is neutral on V8v7 and a slight speed-up on compile time benchmarks.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::refine):
         * dfg/DFGBackwardsPropagationPhase.cpp: Added.
         (DFG):
         (BackwardsPropagationPhase):
         (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase):
         (JSC::DFG::BackwardsPropagationPhase::run):
         (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
         (JSC::DFG::BackwardsPropagationPhase::isNotZero):
         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant):
         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive):
         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
         (JSC::DFG::BackwardsPropagationPhase::propagate):
         (JSC::DFG::performBackwardsPropagation):
         * dfg/DFGBackwardsPropagationPhase.h: Added.
         (DFG):
         * dfg/DFGCPSRethreadingPhase.cpp:
         (JSC::DFG::CPSRethreadingPhase::run):
         (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom):
         (CPSRethreadingPhase):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dump):
         * dfg/DFGNodeFlags.cpp:
         (JSC::DFG::dumpNodeFlags):
         (DFG):
         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (PredictionPropagationPhase):
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGUnificationPhase.cpp:
         (JSC::DFG::UnificationPhase::run):
         * dfg/DFGVariableAccessData.h:
         (JSC::DFG::VariableAccessData::VariableAccessData):
         (JSC::DFG::VariableAccessData::mergeIsLoadedFrom):
         (VariableAccessData):
         (JSC::DFG::VariableAccessData::setIsLoadedFrom):
         (JSC::DFG::VariableAccessData::isLoadedFrom):

 2013-03-11  Oliver Hunt  <oliver@apple.com>

         Harden JSStringJoiner
         https://bugs.webkit.org/show_bug.cgi?id=112093

         Reviewed by Filip Pizlo.

         Harden JSStringJoiner, make it use our CheckedArithmetic
         class to simplify everything.

         * runtime/JSStringJoiner.cpp:
         (JSC::JSStringJoiner::build):
         * runtime/JSStringJoiner.h:
         (JSStringJoiner):
         (JSC::JSStringJoiner::JSStringJoiner):
         (JSC::JSStringJoiner::append):

 2013-03-11  Michael Saboff  <msaboff@apple.com>

         Crash beneath operationCreateInlinedArguments running fast/js/dfg-create-inlined-arguments-in-closure-inline.html (32-bit only)
         https://bugs.webkit.org/show_bug.cgi?id=112067

         Reviewed by Geoffrey Garen.

         We weren't setting the tag in SetCallee.  Therefore set it to CellTag.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-11  Oliver Hunt  <oliver@apple.com>

         Make SegmentedVector Noncopyable
         https://bugs.webkit.org/show_bug.cgi?id=112059

         Reviewed by Geoffrey Garen.

         Copying a SegmentedVector is very expensive, and really shouldn't
         be necessary.  So I've taken the one place where we currently copy
         and replaced it with a regular Vector, and replaced the address
         dependent logic with a indexing ref instead.

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::newLabelScope):
         (JSC::BytecodeGenerator::emitComplexJumpScopes):
         * bytecompiler/BytecodeGenerator.h:
         (BytecodeGenerator):
         * bytecompiler/LabelScope.h:
         (JSC):
         (JSC::LabelScopePtr::LabelScopePtr):
         (LabelScopePtr):
         (JSC::LabelScopePtr::operator=):
         (JSC::LabelScopePtr::~LabelScopePtr):
         (JSC::LabelScopePtr::operator*):
         (JSC::LabelScopePtr::operator->):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::DoWhileNode::emitBytecode):
         (JSC::WhileNode::emitBytecode):
         (JSC::ForNode::emitBytecode):
         (JSC::ForInNode::emitBytecode):
         (JSC::SwitchNode::emitBytecode):
         (JSC::LabelNode::emitBytecode):

 2013-03-10  Andreas Kling  <akling@apple.com>

         SpeculativeJIT should use OwnPtr<SlowPathGenerator>.
         <http://webkit.org/b/111942>

         Reviewed by Anders Carlsson.

         There's no need to include DFGSlowPathGenerator.h from the header as long as the destructor is out-of-line,
         so let's use OwnPtr instead of raw pointers + deleteAllValues().

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):

 2013-03-09  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r145299.
         http://trac.webkit.org/changeset/145299
         https://bugs.webkit.org/show_bug.cgi?id=111928

         compilation failure with recent clang
         (DFGBackwardsPropagationPhase.cpp:132:35: error: comparison of
         constant 10 with expression of type 'bool' is always false)
         (Requested by thorton on #webkit).

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::refine):
         * dfg/DFGBackwardsPropagationPhase.cpp: Removed.
         * dfg/DFGBackwardsPropagationPhase.h: Removed.
         * dfg/DFGCPSRethreadingPhase.cpp:
         (JSC::DFG::CPSRethreadingPhase::run):
         (CPSRethreadingPhase):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dump):
         * dfg/DFGNodeFlags.cpp:
         (JSC::DFG::nodeFlagsAsString):
         (DFG):
         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::isNotNegZero):
         (PredictionPropagationPhase):
         (JSC::DFG::PredictionPropagationPhase::isNotZero):
         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant):
         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive):
         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo):
         (JSC::DFG::PredictionPropagationPhase::propagate):
         (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags):
         * dfg/DFGUnificationPhase.cpp:
         (JSC::DFG::UnificationPhase::run):
         * dfg/DFGVariableAccessData.h:
         (JSC::DFG::VariableAccessData::VariableAccessData):
         (VariableAccessData):

 2013-03-08  Filip Pizlo  <fpizlo@apple.com>

         DFG overflow check elimination is too smart for its own good
         https://bugs.webkit.org/show_bug.cgi?id=111832

         Reviewed by Oliver Hunt and Gavin Barraclough.

         This improves overflow check elimination in three ways:

         1) It reduces the amount of time the compiler will spend doing it.

         2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation
            over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children)
            are int32's and then perform a possibly-overflowing operation, we must be careful not to assume
            that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that
            @b->children are int32's and that hence @b might produce a large enough result that doubles would
            start chopping low bits. The specific implication of this is that for a binary operation to not
            propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one
            of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such
            operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the
            latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that
            large won't even make it into the DFG currently.

         3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub
            are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate
            NodeUsedAsNumber to either @a or @b.

         This is neutral on V8v7 and a slight speed-up on compile time benchmarks.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::refine):
         * dfg/DFGBackwardsPropagationPhase.cpp: Added.
         (DFG):
         (BackwardsPropagationPhase):
         (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase):
         (JSC::DFG::BackwardsPropagationPhase::run):
         (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
         (JSC::DFG::BackwardsPropagationPhase::isNotZero):
         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant):
         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive):
         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
         (JSC::DFG::BackwardsPropagationPhase::propagate):
         (JSC::DFG::performBackwardsPropagation):
         * dfg/DFGBackwardsPropagationPhase.h: Added.
         (DFG):
         * dfg/DFGCPSRethreadingPhase.cpp:
         (JSC::DFG::CPSRethreadingPhase::run):
         (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom):
         (CPSRethreadingPhase):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dump):
         * dfg/DFGNodeFlags.cpp:
         (JSC::DFG::dumpNodeFlags):
         (DFG):
         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (PredictionPropagationPhase):
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGUnificationPhase.cpp:
         (JSC::DFG::UnificationPhase::run):
         * dfg/DFGVariableAccessData.h:
         (JSC::DFG::VariableAccessData::VariableAccessData):
         (JSC::DFG::VariableAccessData::mergeIsLoadedFrom):
         (VariableAccessData):
         (JSC::DFG::VariableAccessData::setIsLoadedFrom):
         (JSC::DFG::VariableAccessData::isLoadedFrom):

 2013-03-08  Roger Fong  <roger_fong@apple.com>

         Makefile fixes.

         * JavaScriptCore.vcxproj/JavaScriptCore.make:

 2013-03-08  Gabor Rapcsanyi  <rgabor@webkit.org>

         Cache flush problem on ARMv7 JSC
         https://bugs.webkit.org/show_bug.cgi?id=111441

         Reviewed by Zoltan Herczeg.

         Not proper cache flush causing random crashes on ARMv7 Linux with V8 tests.
         The problem is similar to https://bugs.webkit.org/show_bug.cgi?id=77712.
         Change the cache fulsh mechanism similar to ARM traditinal and revert the
         temporary fix.

         * assembler/ARMv7Assembler.h:
         (JSC::ARMv7Assembler::cacheFlush):

 2013-03-07  Geoffrey Garen  <ggaren@apple.com>

         REGRESSION (r143759): 40% JSBench regression, 20% Octane/closure regression, 40% Octane/jquery regression, 2% Octane regression
         https://bugs.webkit.org/show_bug.cgi?id=111797

         Reviewed by Oliver Hunt.

         The bot's testing configuration stresses the cache's starting guess
         of 1MB.

         This patch removes any starting guess, and just uses wall clock time
         to discover the initial working set size of an app, in code size.

         * runtime/CodeCache.cpp:
         (JSC::CodeCacheMap::pruneSlowCase): Update our timer as we go.

         Also fixed a bug where pruning from 0 to 0 would hang -- that case is
         a possibility now that we start with a capacity of 0.

         * runtime/CodeCache.h:
         (CodeCacheMap):
         (JSC::CodeCacheMap::CodeCacheMap):
         (JSC::CodeCacheMap::add):
         (JSC::CodeCacheMap::prune): Don't prune if we're in the middle of
         discovering the working set size of an app, in code size.

 2013-03-07  Michael Saboff  <msaboff@apple.com>

         Crash when updating predictions below JSC::arrayProtoFuncForEach on tuaw.com article
         https://bugs.webkit.org/show_bug.cgi?id=111777

         Reviewed by Filip Pizlo.

         Moved register allocations to be above any generated control flow so that any
         resulting spill would be visible to all subsequently generated code.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-07  Filip Pizlo  <fpizlo@apple.com>

         DFG should not get corrupted IR in the case of code that is dead, unreachable, and contains a chain of nodes that use each other in an untyped way
         https://bugs.webkit.org/show_bug.cgi?id=111783

         Reviewed by Mark Hahnenberg.

         Unreachable code is not touched by CFA and so thinks that even untyped uses are checked.
         But dead untyped uses don't need checks and hence don't need to be Phantom'd. The DCE knew
         this in findTypeCheckRoot() but not in eliminateIrrelevantPhantomChildren(), leading to a
         Phantom node that had another Phantom node as one of its kids.

         * dfg/DFGDCEPhase.cpp:
         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):

 2013-03-07  Filip Pizlo  <fpizlo@apple.com>

         The DFG fixpoint is not strictly profitable, and should be straight-lined
         https://bugs.webkit.org/show_bug.cgi?id=111764

         Reviewed by Oliver Hunt and Geoffrey Garen.

         The DFG previously ran optimizations to fixpoint because there exists a circular dependency:

         CSE depends on CFG simplification: CFG simplification merges blocks, and CSE is block-local.

         CFG simplification depends on CFA and constant folding: constant folding reveals branches on
         constants.

         CFA depends on CSE: CSE reveals must-alias relationships by proving that two operations
         always produce identical values.

         Arguments simplification also depends on CSE, but it ought not depend on anything else.

         Hence we get a cycle like: CFA -> folding -> CFG -> CSE -> CFA.

         Note that before we had sparse conditional CFA, we also had CFA depending on CFG. This ought
         not be the case anymore: CFG simplification should not by itself lead to better CFA results.

         My guess is that the weakest link in this cycle is CFG -> CSE. CSE cuts both ways: if you
         CSE too much then you increase register pressure. Hence it's not clear that you always want
         to CSE after simplifying control flow. This leads to an order of optimization as follows:

         CSE -> arguments -> CFA -> folding -> CFG

         This is a 2.5% speed-up on SunSpider, a 4% speed-up on V8Spider, a possible 0.3% slow-down
         on V8v7, nothing on Kraken, and 1.2% speed-up in the JSRegress geomean. I'll take a 2.5%
         speed-up over a 0.3% V8v7 speed-up.

         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):

 2013-03-07  Roger Fong  <roger_fong@apple.com>

         Build fix for AppleWin VS2010.

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

 2013-03-05  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Need a good way to reference event handlers without causing cycles
         https://bugs.webkit.org/show_bug.cgi?id=111088

         Reviewed by Geoffrey Garen.

         JSManagedValue is like a special kind of weak value. When you create a JSManagedValue, you can
         supply an Objective-C object as its "owner". As long as the Objective-C owner object remains
         alive and its wrapper remains accessible to the JSC garbage collector (e.g. by being marked by
         the global object), the reference to the JavaScript value is strong. As soon as the Objective-C
         owner is deallocated or its wrapper becomes inaccessible to the garbage collector, the reference
         becomes weak.

         If you do not supply an owner or you use the weakValueWithValue: convenience class method, the
         returned JSManagedValue behaves as a normal weak reference.

         This new class allows clients to maintain references to JavaScript values in the Objective-C
         heap without creating reference cycles/leaking memory.

         * API/JSAPIWrapperObject.cpp: Added.
         (JSC):
         (JSC::::createStructure):
         (JSC::JSAPIWrapperObject::JSAPIWrapperObject): This is a special JSObject for the Objective-C API that knows
         for the purposes of garbage collection/marking that it wraps an opaque Objective-C object.
         (JSC::JSAPIWrapperObject::visitChildren): We add the pointer to the wrapped Objective-C object to the set of
         opaque roots so that the weak handle owner for JSManagedValues can find it later.
         * API/JSAPIWrapperObject.h: Added.
         (JSC):
         (JSAPIWrapperObject):
         (JSC::JSAPIWrapperObject::wrappedObject):
         (JSC::JSAPIWrapperObject::setWrappedObject):
         * API/JSBase.cpp:
         (JSSynchronousGarbageCollect):
         * API/JSBasePrivate.h:
         * API/JSCallbackObject.cpp:
         (JSC):
         * API/JSCallbackObject.h:
         (JSC::JSCallbackObject::destroy): Moved this to the header so that we don't get link errors with JSAPIWrapperObject.
         * API/JSContext.mm:
         (-[JSContext initWithVirtualMachine:]): We weren't adding manually allocated/initialized JSVirtualMachine objects to
         the global cache of virtual machines. The init methods handle this now rather than contextWithGlobalContextRef, since
         not everyone is guaranteed to use the latter.
         (-[JSContext initWithGlobalContextRef:]):
         (+[JSContext contextWithGlobalContextRef:]):
         * API/JSManagedValue.h: Added.
         * API/JSManagedValue.mm: Added.
         (JSManagedValueHandleOwner):
         (managedValueHandleOwner):
         (+[JSManagedValue weakValueWithValue:]):
         (+[JSManagedValue managedValueWithValue:owner:]):
         (-[JSManagedValue init]): We explicitly call the ARC entrypoints to initialize/get the weak owner field since we don't
         use ARC when building our framework.
         (-[JSManagedValue initWithValue:]):
         (-[JSManagedValue initWithValue:owner:]):
         (-[JSManagedValue dealloc]):
         (-[JSManagedValue value]):
         (-[JSManagedValue weakOwner]):
         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots): If the Objective-C owner is still alive (i.e. loading the weak field
         returns non-nil) and that value was added to the set of opaque roots by the wrapper for that Objective-C owner, then the the
         JSObject to which the JSManagedObject refers is still alive.
         * API/JSObjectRef.cpp: We have to add explicit checks for the JSAPIWrapperObject, just like the other types of JSCallbackObjects.
         (JSObjectGetPrivate):
         (JSObjectSetPrivate):
         (JSObjectGetPrivateProperty):
         (JSObjectSetPrivateProperty):
         (JSObjectDeletePrivateProperty):
         * API/JSValue.mm:
         (objectToValueWithoutCopy):
         * API/JSValueRef.cpp:
         (JSValueIsObjectOfClass):
         * API/JSVirtualMachine.mm:
         (-[JSVirtualMachine initWithContextGroupRef:]):
         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
         * API/JSWrapperMap.mm:
         (wrapperFinalize):
         (makeWrapper): This is our own internal version of JSObjectMake which creates JSAPIWrapperObjects, the Obj-C API
         version of JSCallbackObjects.
         (createObjectWithCustomBrand):
         (-[JSObjCClassInfo wrapperForObject:]):
         (tryUnwrapObjcObject):
         * API/JavaScriptCore.h:
         * API/tests/testapi.mm: Added new tests for the strong and weak uses of JSManagedValue in the context of an
         onclick handler for an Objective-C object inserted into a JSContext.
         (-[TextXYZ setWeakOnclick:]):
         (-[TextXYZ setOnclick:]):
         (-[TextXYZ weakOnclick]):
         (-[TextXYZ onclick]):
         (-[TextXYZ click]):
         * CMakeLists.txt: Various build system additions.
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * runtime/JSGlobalObject.cpp: Added the new canonical Structure for the JSAPIWrapperObject class.
         (JSC::JSGlobalObject::reset):
         (JSC):
         (JSC::JSGlobalObject::visitChildren):
         * runtime/JSGlobalObject.h:
         (JSGlobalObject):
         (JSC::JSGlobalObject::objcWrapperObjectStructure):

 2013-03-06  Filip Pizlo  <fpizlo@apple.com>

         ConvertThis should be turned into Identity based on predictions in Fixup, rather than based on proofs in ConstantFolding
         https://bugs.webkit.org/show_bug.cgi?id=111674

         Reviewed by Oliver Hunt.

         This gets rid of the speculated forms of ConvertThis in the backend, and has Fixup
         convert them to either Identity(Object:@child) if the child is predicted object, or
         Phantom(Other:@child) ; WeakJSConstant(global this object) if it's predicted Other.

         The goal of this is to ensure that the optimization fixpoint doesn't create
         Identity's, since doing so requires a rerun of CSE. So far this isn't a speed-up
         but I'm hoping this will be a step towards reducing the need to rerun the fixpoint
         so as to ultimately reduce compile times.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         * dfg/DFGAssemblyHelpers.h:
         (AssemblyHelpers):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (FixupPhase):
         (JSC::DFG::FixupPhase::observeUseKindOnNode):
         (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::globalThisObjectFor):
         (Graph):
         * dfg/DFGNode.h:
         (Node):
         (JSC::DFG::Node::convertToIdentity):
         (JSC::DFG::Node::convertToWeakConstant):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-03-07  Peter Gal  <galpeter@inf.u-szeged.hu>

         Children method in LLINT AST Not class should return [@child]
         https://bugs.webkit.org/show_bug.cgi?id=90740

         Reviewed by Filip Pizlo.

         * offlineasm/ast.rb: Fixed the return value of the children method in the Not AST class.

 2013-03-05  Oliver Hunt  <oliver@apple.com>

         Bring back eager resolution of function scoped variables
         https://bugs.webkit.org/show_bug.cgi?id=111497

         Reviewed by Geoffrey Garen.

         This reverts the get/put_scoped_var part of the great non-local
         variable resolution refactoring.  This still leaves all the lazy
         variable resolution logic as it's necessary for global property
         resolution, and i don't want to make the patch bigger than it
         already is.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::CodeBlock):
         * bytecode/CodeBlock.h:
         (CodeBlock):
         * bytecode/Opcode.h:
         (JSC):
         (JSC::padOpcodeName):
         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::generateFunctionCodeBlock):
         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
         * bytecode/UnlinkedCodeBlock.h:
         (JSC):
         (UnlinkedFunctionExecutable):
         (UnlinkedCodeBlock):
         (JSC::UnlinkedCodeBlock::usesGlobalObject):
         (JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
         (JSC::UnlinkedCodeBlock::globalObjectRegister):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::ResolveResult::checkValidity):
         (JSC::BytecodeGenerator::BytecodeGenerator):
         (JSC::BytecodeGenerator::emitLoadGlobalObject):
         (JSC):
         (JSC::BytecodeGenerator::resolve):
         (JSC::BytecodeGenerator::resolveConstDecl):
         (JSC::BytecodeGenerator::emitResolve):
         (JSC::BytecodeGenerator::emitResolveBase):
         (JSC::BytecodeGenerator::emitResolveBaseForPut):
         (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
         (JSC::BytecodeGenerator::emitResolveWithThis):
         (JSC::BytecodeGenerator::emitGetStaticVar):
         (JSC::BytecodeGenerator::emitPutStaticVar):
         * bytecompiler/BytecodeGenerator.h:
         (JSC::ResolveResult::lexicalResolve):
         (JSC::ResolveResult::isStatic):
         (JSC::ResolveResult::depth):
         (JSC::ResolveResult::index):
         (ResolveResult):
         (JSC::ResolveResult::ResolveResult):
         (BytecodeGenerator):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::ResolveNode::isPure):
         (JSC::FunctionCallResolveNode::emitBytecode):
         (JSC::PostfixNode::emitResolve):
         (JSC::TypeOfResolveNode::emitBytecode):
         (JSC::PrefixNode::emitResolve):
         (JSC::ReadModifyResolveNode::emitBytecode):
         (JSC::AssignResolveNode::emitBytecode):
         (JSC::ConstDeclNode::emitCodeSingle):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCapabilities.cpp:
         (JSC::DFG::debugFail):
         * dfg/DFGCapabilities.h:
         (JSC::DFG::canCompileOpcode):
         (JSC::DFG::canInlineOpcode):
         * jit/JIT.cpp:
         (JSC::JIT::privateCompileMainPass):
         * jit/JIT.h:
         (JIT):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::emit_op_get_scoped_var):
         (JSC):
         (JSC::JIT::emit_op_put_scoped_var):
         * jit/JITPropertyAccess32_64.cpp:
         (JSC::JIT::emit_op_get_scoped_var):
         (JSC):
         (JSC::JIT::emit_op_put_scoped_var):
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:
         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getCodeBlock):
         (JSC::CodeCache::getProgramCodeBlock):
         (JSC::CodeCache::getEvalCodeBlock):
         * runtime/CodeCache.h:
         (JSC):
         (CodeCache):
         * runtime/Executable.cpp:
         (JSC::EvalExecutable::compileInternal):
         (JSC::FunctionExecutable::produceCodeBlockFor):
         * runtime/JSGlobalObject.cpp:
         (JSC::JSGlobalObject::createEvalCodeBlock):
         * runtime/JSGlobalObject.h:
         (JSGlobalObject):
         * runtime/Options.cpp:
         (JSC::Options::initialize):

 2013-03-06  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, roll out http://trac.webkit.org/changeset/144989

         I think we want the assertion that I removed.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::merge):
         (JSC::DFG::AbstractState::mergeVariableBetweenBlocks):
         * dfg/DFGAbstractState.h:
         (AbstractState):

 2013-03-06  Filip Pizlo  <fpizlo@apple.com>

         DFG::AbstractState::merge() is still more complicated than it needs to be
         https://bugs.webkit.org/show_bug.cgi?id=111619

         Reviewed by Mark Hahnenberg.

         This method is the one place where we still do some minimal amount of liveness pruning, but the style with
         which it is written is awkward, and it makes an assertion about variablesAtTail that will be invalidated
         by https://bugs.webkit.org/show_bug.cgi?id=111539.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::merge):
         (JSC::DFG::AbstractState::mergeVariableBetweenBlocks):
         * dfg/DFGAbstractState.h:
         (AbstractState):

 2013-03-06  Filip Pizlo  <fpizlo@apple.com>

         DFG should not run full CSE after the optimization fixpoint, since it really just wants store elimination
         https://bugs.webkit.org/show_bug.cgi?id=111536

         Reviewed by Oliver Hunt and Mark Hahnenberg.

         The fixpoint will do aggressive load elimination and pure CSE. There's no need to do it after the fixpoint.
         On the other hand, the fixpoint does not profit from doing store elimination (except for SetLocal/Flush).
         Previously we had CSE do both, and had it avoid doing some store elimination during the fixpoint by querying
         the fixpoint state. This changes CSE to be templated on mode - either NormalCSE or StoreElimination - so
         that we explicitly put it into one of those modes depending on where we call it from. The goal is to reduce
         time spent doing load elimination after the fixpoint, since that is just wasted cycles.

         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::CSEPhase):
         (JSC::DFG::CSEPhase::run):
         (JSC::DFG::CSEPhase::performNodeCSE):
         (JSC::DFG::CSEPhase::performBlockCSE):
         (JSC::DFG::performCSE):
         (DFG):
         (JSC::DFG::performStoreElimination):
         * dfg/DFGCSEPhase.h:
         (DFG):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):

 2013-03-06  Andreas Kling  <akling@apple.com>

         Pack Structure members better.
         <http://webkit.org/b/111593>
         <rdar://problem/13359200>

         Reviewed by Mark Hahnenberg.

         Shrink Structure by 8 bytes (now at 104 bytes) on 64-bit by packing the members better.

         * runtime/Structure.cpp:
         (JSC::Structure::Structure):
         * runtime/Structure.h:
         (Structure):

 2013-03-06  Andreas Kling  <akling@apple.com>

         Unreviewed, fix Windows build after r144910.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:

 2013-03-05  Filip Pizlo  <fpizlo@apple.com>

         DFG should not check if nodes are shouldGenerate prior to DCE
         https://bugs.webkit.org/show_bug.cgi?id=111520

         Reviewed by Geoffrey Garen.

         All nodes are live before DCE. We don't need to check that they aren't, because they
         definitely will be.

         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         * dfg/DFGCFAPhase.cpp:
         (JSC::DFG::CFAPhase::performBlockCFA):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::pureCSE):
         (JSC::DFG::CSEPhase::int32ToDoubleCSE):
         (JSC::DFG::CSEPhase::constantCSE):
         (JSC::DFG::CSEPhase::weakConstantCSE):
         (JSC::DFG::CSEPhase::getCalleeLoadElimination):
         (JSC::DFG::CSEPhase::getArrayLengthElimination):
         (JSC::DFG::CSEPhase::globalVarLoadElimination):
         (JSC::DFG::CSEPhase::scopedVarLoadElimination):
         (JSC::DFG::CSEPhase::globalVarWatchpointElimination):
         (JSC::DFG::CSEPhase::globalVarStoreElimination):
         (JSC::DFG::CSEPhase::scopedVarStoreElimination):
         (JSC::DFG::CSEPhase::getByValLoadElimination):
         (JSC::DFG::CSEPhase::checkStructureElimination):
         (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
         (JSC::DFG::CSEPhase::putStructureStoreElimination):
         (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
         (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
         (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
         (JSC::DFG::CSEPhase::checkArrayElimination):
         (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
         (JSC::DFG::CSEPhase::getLocalLoadElimination):
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):

 2013-03-06  Csaba Osztrogonác  <ossy@webkit.org>

         Fix unused parameter warnings in ARM assembler
         https://bugs.webkit.org/show_bug.cgi?id=111433

         Reviewed by Kentaro Hara.

         * assembler/ARMAssembler.h: Remove unreachable revertJump() after r143346.
         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::moveIntsToDouble): Remove unused scratch parameter instead of UNUSED_PARAM.
         (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): Remove unused fpTemp parameter.
         (JSC::MacroAssemblerARM::revertJumpReplacementToPatchableBranchPtrWithPatch): Remove unused parameters.

 2013-03-06  Andreas Kling  <akling@apple.com>

         Unused Structure property tables waste 14MB on Membuster.
         <http://webkit.org/b/110854>
         <rdar://problem/13292104>

         Reviewed by Geoffrey Garen.

         Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking.
         14 MB progression on Membuster3.

         This time it should stick; I've been through all the tests with COLLECT_ON_EVERY_ALLOCATION.
         The issue with the last version was that Structure::m_offset could be used uninitialized
         when re-materializing a previously GC'd property table, causing some sanity checks to fail.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:

             Added PropertyTable.cpp.

         * runtime/PropertyTable.cpp: Added.
         (JSC::PropertyTable::create):
         (JSC::PropertyTable::clone):
         (JSC::PropertyTable::PropertyTable):
         (JSC::PropertyTable::destroy):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::visitChildren):

             Moved marking of property table values here from Structure::visitChildren().

         * runtime/WriteBarrier.h:
         (JSC::WriteBarrierBase::get):

             Move m_cell to a local before using it multiple times. This avoids a multiple-access race when
             Structure::checkOffsetConsistency() is used in assertions on the main thread while a marking thread
             zaps the property table.

         * runtime/Structure.h:
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
         * runtime/StructureInlines.h:
         (JSC::Structure::propertyTable):

             Added a getter for the Structure's PropertyTable that ASSERTs GC currently isn't active.
             Because GC can zap an unpinned property table at any time, it's not entirely safe to access it.
             Renamed the variable itself to m_propertyTableUnsafe to force call sites into explaining themselves.

         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::checkOffsetConsistency):

             Moved these out of Structure.h to break header dependency cycle between Structure/PropertyTable.

         * runtime/Structure.cpp:
         (JSC::Structure::visitChildren):

             Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd.

         (JSC::Structure::takePropertyTableOrCloneIfPinned):

             Added for setting up the property table in a new transition, this code is now shared between
             addPropertyTransition() and nonPropertyTransition().

         * runtime/JSGlobalData.h:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):

             Add a global propertyTableStructure.

         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::createStructure):
         (JSC::PropertyTable::copy):

             Make PropertyTable a GC object.

         * runtime/Structure.cpp:
         (JSC::Structure::dumpStatistics):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::despecifyDictionaryFunction):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::sealTransition):
         (JSC::Structure::freezeTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::isSealed):
         (JSC::Structure::isFrozen):
         (JSC::Structure::flattenDictionaryStructure):
         (JSC::Structure::pin):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::get):
         (JSC::Structure::despecifyFunction):
         (JSC::Structure::despecifyAllFunctions):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::remove):
         (JSC::Structure::createPropertyMap):
         (JSC::Structure::getPropertyNamesFromStructure):
         (JSC::Structure::checkConsistency):

 2013-03-05  Filip Pizlo  <fpizlo@apple.com>

         Get rid of the invert argument to SpeculativeJIT::jumpSlowForUnwantedArrayMode
         https://bugs.webkit.org/show_bug.cgi?id=105624

         Reviewed by Oliver Hunt.

         All callers pass invert = false, which is the default value of the argument. So, get
         rid of the argument and fold away all code that checks it.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):

 2013-03-05  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, fix an incorrect comment. The comment was a holdover from a work-in-progress version of this code.

         * dfg/DFGDCEPhase.cpp:
         (JSC::DFG::DCEPhase::run):

 2013-03-04  Filip Pizlo  <fpizlo@apple.com>

         DFG DCE might eliminate checks unsoundly
         https://bugs.webkit.org/show_bug.cgi?id=109389

         Reviewed by Oliver Hunt.

         This gets rid of all eager reference counting, and does all dead code elimination
         in one phase - the DCEPhase. This phase also sets up the node reference counts,
         which are then used not just for DCE but also register allocation and stack slot
         allocation.

         Doing this required a number of surgical changes in places that previously relied
         on always having liveness information. For example, the structure check hoisting
         phase must now consult whether a VariableAccessData is profitable for unboxing to
         make sure that it doesn't try to do hoisting on set SetLocals. The arguments
         simplification phase employs its own light-weight liveness analysis. Both phases
         previously just used reference counts.

         The largest change is that now, dead nodes get turned into Phantoms. Those
         Phantoms will retain those child edges that are not proven. This ensures that any
         type checks performed by a dead node remain even after the node is killed. On the
         other hand, this Phantom conversion means that we need special handling for
         SetLocal. I decided to make the four forms of SetLocal explicit:

         MovHint(@a, rK): Just indicates that node @a contains the value that would have
              now been placed into virtual register rK. Does not actually cause @a to be
              stored into rK. This would have previously been a dead SetLocal with @a
              being live. MovHints are always dead.

         ZombieHint(rK): Indicates that at this point, register rK will contain a dead
              value and OSR should put Undefined into it. This would have previously been
              a dead SetLocal with @a being dead also. ZombieHints are always dead.

         MovHintAndCheck(@a, rK): Identical to MovHint except @a is also type checked,
              according to whatever UseKind the edge to @a has. The type check is always a
              forward exit. MovHintAndChecks are always live, since they are
              NodeMustGenerate. Previously this would have been a dead SetLocal with a
              live @a, and the check would have disappeared. This is one of the bugs that
              this patch solves.

         SetLocal(@a, rK): This still does exactly what it does now, if the SetLocal is
              live.

         Basically this patch makes it so that dead SetLocals eventually decay to MovHint,
         ZombieHint, or MovHintAndCheck depending on the situation. If the child @a is
         also dead, then you get a ZombieHint. If the child @a is live but the SetLocal
         has a type check and @a's type hasn't been proven to have that type then you get
         a MovHintAndCheck. Otherwise you get a MovHint.

         This is performance neutral.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::executeEffects):
         (JSC::DFG::AbstractState::mergeStateAtTail):
         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         (ArgumentsSimplificationPhase):
         (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
         * dfg/DFGBasicBlock.h:
         (BasicBlock):
         * dfg/DFGBasicBlockInlines.h:
         (DFG):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::addToGraph):
         (JSC::DFG::ByteCodeParser::insertPhiNode):
         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
         * dfg/DFGCFAPhase.cpp:
         (JSC::DFG::CFAPhase::run):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::run):
         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
         * dfg/DFGCPSRethreadingPhase.cpp:
         (JSC::DFG::CPSRethreadingPhase::run):
         (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::CSEPhase::setReplacement):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGCommon.cpp:
         (WTF::printInternal):
         (WTF):
         * dfg/DFGCommon.h:
         (WTF):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
         (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
         * dfg/DFGDCEPhase.cpp: Added.
         (DFG):
         (DCEPhase):
         (JSC::DFG::DCEPhase::DCEPhase):
         (JSC::DFG::DCEPhase::run):
         (JSC::DFG::DCEPhase::findTypeCheckRoot):
         (JSC::DFG::DCEPhase::countEdge):
         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::performDCE):
         * dfg/DFGDCEPhase.h: Added.
         (DFG):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::checkArray):
         (JSC::DFG::FixupPhase::blessArrayOperation):
         (JSC::DFG::FixupPhase::fixIntEdge):
         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
         (JSC::DFG::FixupPhase::truncateConstantToInt32):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::Graph):
         (JSC::DFG::Graph::dump):
         (DFG):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::changeChild):
         (JSC::DFG::Graph::changeEdge):
         (JSC::DFG::Graph::compareAndSwap):
         (JSC::DFG::Graph::clearAndDerefChild):
         (JSC::DFG::Graph::performSubstitution):
         (JSC::DFG::Graph::performSubstitutionForEdge):
         (Graph):
         (JSC::DFG::Graph::substitute):
         * dfg/DFGInsertionSet.h:
         (InsertionSet):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::Node):
         (JSC::DFG::Node::convertToConstant):
         (JSC::DFG::Node::convertToGetLocalUnlinked):
         (JSC::DFG::Node::containsMovHint):
         (Node):
         (JSC::DFG::Node::hasVariableAccessData):
         (JSC::DFG::Node::willHaveCodeGenOrOSR):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
         (JSC::DFG::SpeculativeJIT::compileMovHint):
         (JSC::DFG::SpeculativeJIT::compileMovHintAndCheck):
         (DFG):
         (JSC::DFG::SpeculativeJIT::compileInlineStart):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         (JSC::DFG::StructureCheckHoistingPhase::shouldConsiderForHoisting):
         (StructureCheckHoistingPhase):
         * dfg/DFGValidate.cpp:
         (JSC::DFG::Validate::validate):

 2013-03-05  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: JSValue should implement init and return nil in exceptional cases
         https://bugs.webkit.org/show_bug.cgi?id=111487

         Reviewed by Darin Adler.

         * API/JSValue.mm:
         (-[JSValue init]): We return nil here because there is no way to get the instance into a coherent state
         without a JSContext.
         (-[JSValue initWithValue:inContext:]): Similarly, we should also return nil here if either of the arguments is 0.

 2013-03-05  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r144708.
         http://trac.webkit.org/changeset/144708
         https://bugs.webkit.org/show_bug.cgi?id=111447

         random assertion crashes in inspector tests on qt+mac bots
         (Requested by kling on #webkit).

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::PropertyTable):
         (JSC):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::copy):
         * runtime/PropertyTable.cpp: Removed.
         * runtime/Structure.cpp:
         (JSC::Structure::dumpStatistics):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::despecifyDictionaryFunction):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::sealTransition):
         (JSC::Structure::freezeTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::isSealed):
         (JSC::Structure::isFrozen):
         (JSC::Structure::flattenDictionaryStructure):
         (JSC::Structure::pin):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::get):
         (JSC::Structure::despecifyFunction):
         (JSC::Structure::despecifyAllFunctions):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::remove):
         (JSC::Structure::createPropertyMap):
         (JSC::Structure::getPropertyNamesFromStructure):
         (JSC::Structure::visitChildren):
         (JSC::Structure::checkConsistency):
         * runtime/Structure.h:
         (JSC):
         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
         (JSC::Structure::checkOffsetConsistency):
         (Structure):
         * runtime/StructureInlines.h:
         (JSC::Structure::get):
         * runtime/WriteBarrier.h:
         (JSC::WriteBarrierBase::get):

 2013-03-05  David Kilzer  <ddkilzer@apple.com>

         BUILD FIX (r144698): Only enable SPEECH_SYNTHESIS for Mac
         <http://webkit.org/b/106742>

         Fixes the following build failures:

             Undefined symbols for architecture i386:
               "__ZTVN7WebCore25PlatformSpeechSynthesizerE", referenced from:
                   __ZN7WebCore25PlatformSpeechSynthesizerC2EPNS_31PlatformSpeechSynthesizerClientE in PlatformSpeechSynthesizer.o
               NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
               "__ZN7WebCore25PlatformSpeechSynthesizer19initializeVoiceListEv", referenced from:
                   __ZN7WebCore25PlatformSpeechSynthesizerC2EPNS_31PlatformSpeechSynthesizerClientE in PlatformSpeechSynthesizer.o
             ld: symbol(s) not found for architecture i386

         * Configurations/FeatureDefines.xcconfig:
         - Fix definition of ENABLE_ENCRYPTED_MEDIA_V2_macosx to match
           other FeatureDefines.xcconfig files.
         - Only set ENABLE_SPEECH_SYNTHESIS for the macosx platform.

 2013-03-04  Andreas Kling  <akling@apple.com>

         Unused Structure property tables waste 14MB on Membuster.
         <http://webkit.org/b/110854>
         <rdar://problem/13292104>

         Reviewed by Geoffrey Garen.

         Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking.
         14 MB progression on Membuster3.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:

             Added PropertyTable.cpp.

         * runtime/PropertyTable.cpp: Added.
         (JSC::PropertyTable::create):
         (JSC::PropertyTable::clone):
         (JSC::PropertyTable::PropertyTable):
         (JSC::PropertyTable::destroy):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::visitChildren):

             Moved marking of property table values here from Structure::visitChildren().

         * runtime/WriteBarrier.h:
         (JSC::WriteBarrierBase::get):

             Move m_cell to a local before using it multiple times. This avoids a multiple-access race when
             Structure::checkOffsetConsistency() is used in assertions on the main thread while a marking thread
             zaps the property table.

         * runtime/Structure.h:
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
         * runtime/StructureInlines.h:
         (JSC::Structure::propertyTable):

             Added a getter for the Structure's PropertyTable that ASSERTs GC currently isn't active.
             Because GC can zap an unpinned property table at any time, it's not entirely safe to access it.
             Renamed the variable itself to m_propertyTableUnsafe to force call sites into explaining themselves.

         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::checkOffsetConsistency):

             Moved these out of Structure.h to break header dependency cycle between Structure/PropertyTable.

         * runtime/Structure.cpp:
         (JSC::Structure::visitChildren):

             Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd.

         * runtime/JSGlobalData.h:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):

             Add a global propertyTableStructure.

         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::createStructure):
         (JSC::PropertyTable::copy):

             Make PropertyTable a GC object.

         * runtime/Structure.cpp:
         (JSC::Structure::dumpStatistics):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::despecifyDictionaryFunction):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::sealTransition):
         (JSC::Structure::freezeTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::isSealed):
         (JSC::Structure::isFrozen):
         (JSC::Structure::flattenDictionaryStructure):
         (JSC::Structure::pin):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::get):
         (JSC::Structure::despecifyFunction):
         (JSC::Structure::despecifyAllFunctions):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::remove):
         (JSC::Structure::createPropertyMap):
         (JSC::Structure::getPropertyNamesFromStructure):
         (JSC::Structure::checkConsistency):

 2013-03-04  Chris Fleizach  <cfleizach@apple.com>

         Support WebSpeech - Speech Synthesis
         https://bugs.webkit.org/show_bug.cgi?id=106742

         Reviewed by Simon Fraser.

         Enable speech synthesis for the Mac.

         * Configurations/FeatureDefines.xcconfig:

 2013-03-04  Mark Hahnenberg  <mhahnenberg@apple.com>

         Remove contextInternalContext from JSContextInternal.h
         https://bugs.webkit.org/show_bug.cgi?id=111356

         Reviewed by Geoffrey Garen.

         We don't need it any more since we have globalContextRef in JSContext.

         * API/JSContext.mm:
         * API/JSContextInternal.h:
         * API/JSValue.mm:
         (+[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:]):
         (-[JSValue toBool]):
         (-[JSValue toDouble]):
         (-[JSValue toNumber]):
         (-[JSValue toString]):
         (-[JSValue toDate]):
         (-[JSValue toArray]):
         (-[JSValue toDictionary]):
         (-[JSValue valueForProperty:]):
         (-[JSValue setValue:forProperty:]):
         (-[JSValue deleteProperty:]):
         (-[JSValue hasProperty:]):
         (-[JSValue valueAtIndex:]):
         (-[JSValue setValue:atIndex:]):
         (-[JSValue isUndefined]):
         (-[JSValue isNull]):
         (-[JSValue isBoolean]):
         (-[JSValue isNumber]):
         (-[JSValue isString]):
         (-[JSValue isObject]):
         (-[JSValue isEqualToObject:]):
         (-[JSValue isEqualWithTypeCoercionToObject:]):
         (-[JSValue isInstanceOf:]):
         (-[JSValue callWithArguments:]):
         (-[JSValue constructWithArguments:]):
         (-[JSValue invokeMethod:withArguments:]):
         (valueToObject):
         (objectToValueWithoutCopy):
         (objectToValue):
         (-[JSValue initWithValue:inContext:]):
         (-[JSValue dealloc]):
         (-[JSValue description]):
         * API/JSWrapperMap.mm:
         (createObjectWithCustomBrand):
         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]):
         (-[JSObjCClassInfo wrapperForObject:]):
         (-[JSWrapperMap jsWrapperForObject:]):
         * API/ObjCCallbackFunction.mm:
         (ObjCCallbackFunction::call):
         (objCCallbackFunctionForInvocation):

 2013-03-04  Andreas Kling  <akling@apple.com>

         Add simple vector traits for JSC::Identifier.
         <http://webkit.org/b/111323>

         Reviewed by Geoffrey Garen.

         Identifiers are really just Strings, giving them simple vector traits makes
         Vector move them with memcpy() instead of churning the refcounts.

         * runtime/Identifier.h:
         (WTF):

 2013-03-04  Kunihiko Sakamoto  <ksakamoto@chromium.org>

         Add build flag for FontLoader
         https://bugs.webkit.org/show_bug.cgi?id=111289

         Reviewed by Benjamin Poulain.

         Add ENABLE_FONT_LOAD_EVENTS build flag (disabled by default).

         * Configurations/FeatureDefines.xcconfig:

 2013-03-03  Andreas Kling  <akling@apple.com>

         Shrink JSC::HashTable entries.
         <http://webkit.org/b/111275>
         <rdar://problem/13333511>

         Reviewed by Anders Carlsson.

         Move the Intrinsic value out of the function-specific part of the union,
         and store it next to m_attributes. Reduces the size of HashEntry by 8 bytes.

         990 kB progression on Membuster3. (PTUS: 797 kB)

         * runtime/Lookup.h:
         (JSC::HashEntry::initialize):
         (JSC::HashEntry::intrinsic):
         (HashEntry):

 2013-03-01  David Kilzer  <ddkilzer@apple.com>

         BUILD FIX: testapi should link to Foundation, not CoreFoundation

         * JavaScriptCore.xcodeproj/project.pbxproj: Change testapi to
         link to Foundation.framework instead of CoreFoundation.framework
         since it uses NS types.

 2013-03-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Passing JS functions to Objective-C callbacks causes JSValue to leak
         https://bugs.webkit.org/show_bug.cgi?id=107836

         Reviewed by Oliver Hunt.

         We've decided to remove support for this feature from the API because there's no way to automatically manage
         the memory for clients in a satisfactory manner. Clients can still pass JS functions to Objective-C methods,
         but the methods must accept plain JSValues instead of Objective-C blocks.

         We now ignore functions that are part of a protocol that inherits from JSExport that accept blocks as arguments.

         * API/JSBlockAdaptor.h: Removed.
         * API/JSBlockAdaptor.mm: Removed.
         * API/ObjCCallbackFunction.mm:
         (ArgumentTypeDelegate::typeBlock): Return nil to signal that we want to ignore this function when copying it
         to the object from the protocol.
         * API/tests/testapi.mm: Added a test to make sure that we ignore methods declared as part of a JSExport-ed protocol
         that have block arguments.
         (-[TestObject bogusCallback:]):
         * JavaScriptCore.gypi: Updated build files.
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-03-01  Filip Pizlo  <fpizlo@apple.com>

         DFG Branch(LogicalNot) peephole should not try to optimize and work-around the case where LogicalNot may be otherwise live
         https://bugs.webkit.org/show_bug.cgi?id=111209

         Reviewed by Oliver Hunt.

         Even if it is then everything will work just fine. It's not necessary to check the ref count here.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):

 2013-03-01  Filip Pizlo  <fpizlo@apple.com>

         DFG CSE phase shouldn't rely on ref count of nodes, since it doesn't have to
         https://bugs.webkit.org/show_bug.cgi?id=111205

         Reviewed by Oliver Hunt.

         I don't understand the intuition behind setLocalStoreElimination() validating that the SetLocal's ref count
         is 1. I believe this is a hold-over from when setLocalStoreElimination() would match one SetLocal to another,
         and then try to eliminate the first SetLocal. But that's not how it works now. Now, setLocalStoreElimination()
         is actually Flush elimination: it eliminates any Flush that anchors a SetLocal if it proves that every path
         from the SetLocal to the Flush is devoid of operations that may observe the local. It doesn't actually kill
         the SetLocal itself: if the SetLocal is live because of other things (other Flushes or GetLocals in other
         basic blocks), then the SetLocal will naturally still be alive because th Flush was only keeping the SetLocal
         alive by one count rather than being solely responsible for its liveness.

         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         (JSC::DFG::CSEPhase::eliminate):
         (JSC::DFG::CSEPhase::performNodeCSE):

 2013-03-01  Filip Pizlo  <fpizlo@apple.com>

         Rename MovHint to MovHintEvent so I can create a NodeType called MovHint

         Rubber stamped by Mark Hahnenberg.

         This is similar to the SetLocal/SetLocalEvent naming scheme, where SetLocal is the
         NodeType and SetLocalEvent is the VariableEventKind.

         * dfg/DFGVariableEvent.cpp:
         (JSC::DFG::VariableEvent::dump):
         * dfg/DFGVariableEvent.h:
         (JSC::DFG::VariableEvent::movHint):
         (JSC::DFG::VariableEvent::id):
         (JSC::DFG::VariableEvent::operand):
         (VariableEvent):
         * dfg/DFGVariableEventStream.cpp:
         (JSC::DFG::VariableEventStream::reconstruct):

 2013-03-01  Raphael Kubo da Costa  <raphael.kubo.da.costa@intel.com>

         [JSC] Fix sign comparison warning/error after r144340.
         https://bugs.webkit.org/show_bug.cgi?id=111164

         Reviewed by Mark Hahnenberg.

         gcc (both 4.2.1 and 4.7.2) complain about comparing signed and
         unsigned terms (clang accepts it just fine).

         Work around that by casting the 1 to an uintptr_t as well.

         * dfg/DFGEdge.h:
         (JSC::DFG::Edge::makeWord):

 2013-02-28  Filip Pizlo  <fpizlo@apple.com>

         DFG CFA should not do liveness pruning
         https://bugs.webkit.org/show_bug.cgi?id=111119

         Reviewed by Mark Hahnenberg.

         It adds complexity and probably buys nothing.  Moreover, I'm transitioning to having
         liveness only available at the bitter end of compilation, so this will stop working
         after https://bugs.webkit.org/show_bug.cgi?id=109389 anyway.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::initialize):
         (JSC::DFG::AbstractState::mergeStateAtTail):

 2013-02-28  Filip Pizlo  <fpizlo@apple.com>

         Don't try to emit profiling if you don't have the DFG JIT.

         Rubber stamped by Mark Hahnenberg.

         * jit/JIT.h:
         (JSC::JIT::shouldEmitProfiling):

 2013-02-28  Filip Pizlo  <fpizlo@apple.com>

         DFG Phantom node should be honest about the fact that it can exit
         https://bugs.webkit.org/show_bug.cgi?id=111115

         Reviewed by Mark Hahnenberg.

         The chances of this having cause serious issues are low, since most clients of the
         NodeDoesNotExit flag run after CFA and CFA updates this properly. But one possible
         case of badness is if the ByteCodeParser inserted a Phantom with a type check in
         between a LogicalNot and a Branch; then that peephole optimization in Fixup might
         go slightly wrong.

         * dfg/DFGNodeType.h:
         (DFG):

 2013-02-28  Mark Hahnenberg  <mhahnenberg@apple.com>

         Add casts in DFGGPRInfo.h to suppress warnings
         https://bugs.webkit.org/show_bug.cgi?id=111104

         Reviewed by Filip Pizlo.

         With certain flags on, we get compiler warnings on ARM. We should do the proper casts to make these warnings go away.

         * dfg/DFGGPRInfo.h:
         (JSC::DFG::GPRInfo::toIndex):
         (JSC::DFG::GPRInfo::debugName):

 2013-02-28  Filip Pizlo  <fpizlo@apple.com>

         It should be easy to determine if a DFG node exits forward or backward when doing type checks
         https://bugs.webkit.org/show_bug.cgi?id=111102

         Reviewed by Mark Hahnenberg.

         This adds a NodeExitsForward flag, which tells you the exit directionality of
         type checks performed by the node. Even if you convert the node to a Phantom
         and use the Edge UseKind for type checks, you'll still get the same exit
         directionality that the original node would have wanted.

         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         * dfg/DFGArrayifySlowPathGenerator.h:
         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::run):
         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
         * dfg/DFGCPSRethreadingPhase.cpp:
         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::setReplacement):
         (JSC::DFG::CSEPhase::eliminate):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::checkArray):
         * dfg/DFGNode.h:
         (Node):
         (JSC::DFG::Node::setOpAndDefaultNonExitFlags):
         (JSC::DFG::Node::convertToPhantom):
         * dfg/DFGNodeFlags.cpp:
         (JSC::DFG::nodeFlagsAsString):
         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
         (DFG):
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
         (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
         (JSC::DFG::SpeculativeJIT::backwardTypeCheck):
         (JSC::DFG::SpeculativeJIT::typeCheck):
         (JSC::DFG::SpeculativeJIT::forwardTypeCheck):
         (JSC::DFG::SpeculativeJIT::fillStorage):
         (JSC::DFG::SpeculativeJIT::compile):
         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand):
         (JSC::DFG::SpeculateIntegerOperand::gpr):
         (SpeculateIntegerOperand):
         (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
         (JSC::DFG::SpeculateDoubleOperand::fpr):
         (SpeculateDoubleOperand):
         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
         (JSC::DFG::SpeculateCellOperand::gpr):
         (SpeculateCellOperand):
         (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
         (JSC::DFG::SpeculateBooleanOperand::gpr):
         (SpeculateBooleanOperand):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-28  Filip Pizlo  <fpizlo@apple.com>

         CodeBlock::valueProfile() has a bogus assertion
         https://bugs.webkit.org/show_bug.cgi?id=111106
         <rdar://problem/13131427>

         Reviewed by Mark Hahnenberg.

         This was just a bad assertion: m_bytecodeOffset == -1 means that the value profile is constructed but not initialized.
         ValueProfile constructs itself in a safe way; you can call any method you want on a constructed but not initialized
         ValueProfile. CodeBlock first constructs all ValueProfiles (by growing the ValueProfile vector) and then initializes
         their m_bytecodeOffset later. This is necessary because the initialization is linking bytecode instructions to their
         ValueProfiles, so at that point we don't want the ValueProfile vector to resize, which implies that we want all of
         them to already be constructed. A GC can happen during this phase, and the GC may want to walk all ValueProfiles.
         This is safe, but one of the ValueProfile getters (CodeBlock::valueProfile()) was asserting that any value profile
         you get has had its m_bytecodeOffset initialized. This need not be the case and nothing will go wrong if it isn't.

         The solution is to remove the assertion, which I believe was put there to ensure that my m_valueProfiles refactoring
         a long time ago was sound: it used to be that a ValueProfile with m_bytecodeOffset == -1 was an argument profile; now
         all argument profiles are in m_argumentValueProfiles instead. I think it's safe to say that this refactoring was done
         soundly since it was a long time ago. So we should kill the assertion - I don't see an easy way to make the assertion
         sound with respect to the GC-during-CodeBlock-construction issue, and I don't believe that the assertion is buying us
         anything at this point.

         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::valueProfile):

 2013-02-27  Filip Pizlo  <fpizlo@apple.com>

         DFG CFA should leave behind information in Edge that says if the Edge's type check is proven to succeed
         https://bugs.webkit.org/show_bug.cgi?id=110840

         Reviewed by Mark Hahnenberg.

         This doesn't add any observable functionality to the compiler, yet. But it does give
         every phase that runs after CFA the ability to know, in O(1) time, whether an edge
         will need to execute a type check.

         * dfg/DFGAbstractState.h:
         (JSC::DFG::AbstractState::filterEdgeByUse):
         (JSC::DFG::AbstractState::filterByType):
         * dfg/DFGCommon.cpp:
         (WTF):
         (WTF::printInternal):
         * dfg/DFGCommon.h:
         (JSC::DFG::isProved):
         (DFG):
         (JSC::DFG::proofStatusForIsProved):
         (WTF):
         * dfg/DFGEdge.cpp:
         (JSC::DFG::Edge::dump):
         * dfg/DFGEdge.h:
         (JSC::DFG::Edge::Edge):
         (JSC::DFG::Edge::setNode):
         (JSC::DFG::Edge::useKindUnchecked):
         (JSC::DFG::Edge::setUseKind):
         (Edge):
         (JSC::DFG::Edge::proofStatusUnchecked):
         (JSC::DFG::Edge::proofStatus):
         (JSC::DFG::Edge::setProofStatus):
         (JSC::DFG::Edge::isProved):
         (JSC::DFG::Edge::needsCheck):
         (JSC::DFG::Edge::shift):
         (JSC::DFG::Edge::makeWord):

 2013-02-28  Simon Hausmann  <simon.hausmann@digia.com>

         [Qt][Mac] Fix massive parallel builds

         Reviewed by Tor Arne Vestbø.

         There exists a race condition that LLIntDesiredOffsets.h is written to
         by two parllel instances of the ruby script. This patch ensures that similar to the output file,
         the generated file is also prefixed according to the build configuration.

         * LLIntOffsetsExtractor.pro:

 2013-02-27  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r144168.
         http://trac.webkit.org/changeset/144168
         https://bugs.webkit.org/show_bug.cgi?id=111019

         It broke the build and tronical is unavailable (Requested by
         Ossy_night on #webkit).

         * LLIntOffsetsExtractor.pro:

 2013-02-26  Filip Pizlo  <fpizlo@apple.com>

         Disable some unsound DFG DCE
         https://bugs.webkit.org/show_bug.cgi?id=110948

         Reviewed by Michael Saboff.

         DCE of bitops is not sound since the bitops might call some variant of valueOf.

         This used to work right because ValueToInt32 was MustGenerate. From the DFG IR
         standpoint it feels weird to make ValueToInt32 be MustGenerate since that node is
         implemented entirely as a pure conversion. If we ever gave the DFG the ability to
         do effectful bitops, we would most likely implement them as special nodes not
         related to the ValueToInt32 and bitop nodes we have now.

         This change is performance neutral.

         * dfg/DFGNodeType.h:
         (DFG):

 2013-02-27  Glenn Adams  <glenn@skynav.com>

         Add ENABLE_CSS3_TEXT_LINE_BREAK flag.
         https://bugs.webkit.org/show_bug.cgi?id=110944

         Reviewed by Dean Jackson.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-27  Julien Brianceau   <jbrianceau@nds.com>

         Fix build when DFG_JIT is not enabled
         https://bugs.webkit.org/show_bug.cgi?id=110991

         Reviewed by Csaba Osztrogonác.

         * jit/JIT.h:
         (JSC::JIT::canBeOptimizedOrInlined):

 2013-02-27  Simon Hausmann  <simon.hausmann@digia.com>

         [Qt][Mac] Fix massive parallel builds

         Reviewed by Tor Arne Vestbø.

         There exists a race condition that LLIntDesiredOffsets.h is written to
         by two parllel instances of the ruby script. This patch ensures that similar to the output file,
         the generated file is also prefixed according to the build configuration.

         * LLIntOffsetsExtractor.pro:

 2013-02-26  Filip Pizlo  <fpizlo@apple.com>

         DFG OSR exit doesn't know which virtual register to use for the last result register for post_inc and post_dec
         https://bugs.webkit.org/show_bug.cgi?id=109036
         <rdar://problem/13292139>

         Reviewed by Gavin Barraclough.

         This was a two-fold problem:

         1) post_inc/dec has two results - the new value of the variable, and the old value of the variable. DFG OSR exit
            assumed that the "last result" used for the Baseline JIT's register allocation would be the new value. It was
            wrong in this assumption.

         2) The Baseline JIT knew to disable its last result optimization in cases where it might confuse the DFG. But it
            was doing this only for code blocks that could be totally optimized, but not code blocks that could only be
            optimized when inlined.

         This patch introduces a more rigorous notion of when the Baseline JIT emits profiling, when it does extra work
         to account for the possibility of OSR exit, and when it does extra work to account for the possibility of OSR
         entry. These notions are called shouldEmitProfiling(), canBeOptimizedOrInlined(), and canBeOptimized(),
         respectively.

         This is performance-neutral and fixes the reported bug. It probably fixes other bugs as well, since previously
         we for example weren't doing the more conservative implementation of op_mov in the Baseline JIT for code blocks
         that could be inlined but not optimized. So, if such a code block OSR exited at just the right point, you'd get
         symptoms similar to this bug.

         * dfg/DFGCapabilities.h:
         (JSC::DFG::canCompileOpcode):
         * dfg/DFGCommon.h:
         * jit/JIT.cpp:
         (JSC::JIT::privateCompile):
         * jit/JIT.h:
         (JSC::JIT::compilePatchGetArrayLength):
         (JSC::JIT::canBeOptimizedOrInlined):
         (JIT):
         * jit/JITArithmetic.cpp:
         (JSC::JIT::emit_op_post_inc):
         (JSC::JIT::emit_op_post_dec):
         * jit/JITArithmetic32_64.cpp:
         (JSC::JIT::emit_op_post_inc):
         (JSC::JIT::emit_op_post_dec):
         * jit/JITCall.cpp:
         (JSC::JIT::emit_op_call_put_result):
         (JSC::JIT::compileOpCall):
         * jit/JITCall32_64.cpp:
         (JSC::JIT::compileOpCall):
         * jit/JITInlines.h:
         (JSC::JIT::emitArrayProfilingSite):
         (JSC::JIT::map):
         * jit/JITOpcodes.cpp:
         (JSC::JIT::emit_op_mov):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::compileGetByIdHotPath):
         (JSC::JIT::privateCompilePutByIdTransition):
         * jit/JITPropertyAccess32_64.cpp:
         (JSC::JIT::compileGetByIdHotPath):
         (JSC::JIT::privateCompilePutByIdTransition):

 2013-02-26  Roger Fong  <roger_fong@apple.com>

         Unreviewed. AppleWin VS2010 build fix.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-02-25  Filip Pizlo  <fpizlo@apple.com>

         The DFG backend's and OSR's decision to unbox a variable should be based on whether it's used in a typed context
         https://bugs.webkit.org/show_bug.cgi?id=110433

         Reviewed by Oliver Hunt and Mark Hahnenberg.

         This introduces the equivalent of a liveness analysis, except for type checking.
         A variable is said to be "profitable for unboxing" (i.e. live at a type check)
         if there exists a type check on a GetLocal of that variable, and the type check
         is consistent with the variable's prediction. Variables that are not profitable
         for unboxing aren't unboxed. Previously they would have been.

         This is a slight speed-up on some things but mostly neutral.

         * dfg/DFGArgumentPosition.h:
         (JSC::DFG::ArgumentPosition::ArgumentPosition):
         (JSC::DFG::ArgumentPosition::mergeShouldNeverUnbox):
         (JSC::DFG::ArgumentPosition::mergeArgumentPredictionAwareness):
         (JSC::DFG::ArgumentPosition::mergeArgumentUnboxingAwareness):
         (ArgumentPosition):
         (JSC::DFG::ArgumentPosition::isProfitableToUnbox):
         (JSC::DFG::ArgumentPosition::shouldUseDoubleFormat):
         * dfg/DFGCommon.h:
         (JSC::DFG::checkAndSet):
         (DFG):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::run):
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
         (FixupPhase):
         (JSC::DFG::FixupPhase::alwaysUnboxSimplePrimitives):
         (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
         * dfg/DFGVariableAccessData.h:
         (JSC::DFG::VariableAccessData::VariableAccessData):
         (JSC::DFG::VariableAccessData::mergeIsCaptured):
         (JSC::DFG::VariableAccessData::mergeIsProfitableToUnbox):
         (VariableAccessData):
         (JSC::DFG::VariableAccessData::isProfitableToUnbox):
         (JSC::DFG::VariableAccessData::shouldUnboxIfPossible):
         (JSC::DFG::VariableAccessData::mergeStructureCheckHoistingFailed):
         (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias):
         (JSC::DFG::VariableAccessData::shouldUseDoubleFormat):
         (JSC::DFG::VariableAccessData::mergeFlags):

 2013-02-26  Oliver Hunt  <oliver@apple.com>

         Fix windows build.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-02-26  Oliver Hunt  <oliver@apple.com>

         Web Inspector: REGRESSION: [JSC] SourceProvider reuses IDs
         https://bugs.webkit.org/show_bug.cgi?id=99674

         Reviewed by Gavin Barraclough.

         Simple incrementing counter for SourceProvider IDs.  Uses a
         lock to incrementing the counter so we don't increment reuse
         counter values or reassign the ID for a given SourceProvider.

         * parser/SourceProvider.cpp:
         (JSC::SourceProvider::SourceProvider):
         (JSC):
         (JSC::SourceProvider::getID):
         * parser/SourceProvider.h:
         (JSC::SourceProvider::asID):
         (SourceProvider):

 2013-02-26  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r144074.
         http://trac.webkit.org/changeset/144074
         https://bugs.webkit.org/show_bug.cgi?id=110897

         Causing 20+ crashes on Mac (Requested by bradee-oh on
         #webkit).

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::PropertyTable):
         (JSC):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::copy):
         * runtime/PropertyTable.cpp: Removed.
         * runtime/Structure.cpp:
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::createPropertyMap):
         (JSC::Structure::visitChildren):
         * runtime/Structure.h:
         (JSC):
         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::checkOffsetConsistency):
         (Structure):
         * runtime/StructureInlines.h:

 2013-02-26  Roger Fong  <roger_fong@apple.com>

         Unreviewed. AppleWin VS2010 build fix.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:

 2013-02-26  Jer Noble  <jer.noble@apple.com>

         Unreviewed build fix; use correct macro for platform name in FeatureDefines.xcconfig.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-26  Michael Saboff  <msaboff@apple.com>

         Potential crash in YARR JIT generated code when building 64 bit
         https://bugs.webkit.org/show_bug.cgi?id=110893

         Reviewed by Gavin Barraclough.

         The ABI doesn't define the behavior for the upper bits of a value that takes less than 64 bits.
         Therefore, we zero extend both the count and length registers to assure that these unsigned values
         don't have garbage upper bits.

         * yarr/YarrJIT.cpp:
         (JSC::Yarr::YarrGenerator::generateEnter):

 2013-02-26  Andreas Kling  <akling@apple.com>

         Unused Structure property tables waste 14MB on Membuster.
         <http://webkit.org/b/110854>
         <rdar://problem/13292104>

         Reviewed by Filip Pizlo.

         Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking.
         14 MB progression on Membuster3.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:

             Added PropertyTable.cpp.

         * runtime/PropertyTable.cpp: Added.
         (JSC::PropertyTable::create):
         (JSC::PropertyTable::clone):
         (JSC::PropertyTable::PropertyTable):
         (JSC::PropertyTable::destroy):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::visitChildren):

             Moved marking of property table values here from Structure::visitChildren().

         * runtime/StructureInlines.h:
         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::checkOffsetConsistency):

             Moved these to StructureInlines.h to break header dependency cycle between Structure/PropertyTable.

         * runtime/Structure.cpp:
         (JSC::Structure::visitChildren):

             Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd.

         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::createPropertyMap):
         * runtime/Structure.h:
         (Structure):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::createStructure):
         (JSC::PropertyTable::copy):

 2013-02-26  Andreas Kling  <akling@apple.com>

         Unreviewed, rolling out r144054.
         http://trac.webkit.org/changeset/144054
         https://bugs.webkit.org/show_bug.cgi?id=110854

         broke builds

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::PropertyTable):
         (JSC):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::copy):
         * runtime/PropertyTable.cpp: Removed.
         * runtime/Structure.cpp:
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::createPropertyMap):
         (JSC::Structure::visitChildren):
         * runtime/Structure.h:
         (JSC):
         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::checkOffsetConsistency):
         (Structure):
         * runtime/StructureInlines.h:

 2013-02-26  Andreas Kling  <akling@apple.com>

         Unused Structure property tables waste 14MB on Membuster.
         <http://webkit.org/b/110854>
         <rdar://problem/13292104>

         Reviewed by Filip Pizlo.

         Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking.
         14 MB progression on Membuster3.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.gypi:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:

             Added PropertyTable.cpp.

         * runtime/PropertyTable.cpp: Added.
         (JSC::PropertyTable::create):
         (JSC::PropertyTable::clone):
         (JSC::PropertyTable::PropertyTable):
         (JSC::PropertyTable::destroy):
         (JSC::PropertyTable::~PropertyTable):
         (JSC::PropertyTable::visitChildren):

             Moved marking of property table values here from Structure::visitChildren().

         * runtime/StructureInlines.h:
         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::checkOffsetConsistency):

             Moved these to StructureInlines.h to break header dependency cycle between Structure/PropertyTable.

         * runtime/Structure.cpp:
         (JSC::Structure::visitChildren):

             Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd.

         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::copyPropertyTable):
         (JSC::Structure::copyPropertyTableForPinning):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::createPropertyMap):
         * runtime/Structure.h:
         (Structure):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::createStructure):
         (JSC::PropertyTable::copy):

 2013-02-26  Jocelyn Turcotte  <jocelyn.turcotte@digia.com>

         Implement JIT on Windows 64 bits
         https://bugs.webkit.org/show_bug.cgi?id=107965

         Reviewed by Simon Hausmann.

         1. MSVC doesn't support inline assembly for 64 bits, implements the trampoline in a separate ASM file.

         2. Windows 64 bits has a different calling convention than other OSes following the AMD64 ABI.
         Differences that we have to handle here:
         - Registers passed parameters are RCX, RDX, R8 and R9 instead of RDI, RSI, RDX, RCX, R8 and R9
         - RDI and RSI must be preserved by callee
         - Only return values <= 8 bytes can be returned by register (RDX can't be used to return a second word)
         - There is no red-zone after RIP on the stack, but instead 4 reserved words before it

         * Target.pri:
         * jit/JITStubs.cpp:
         * jit/JITStubs.h:
         (JSC):
         (JITStackFrame):
         (JSC::JITStackFrame::returnAddressSlot):
         * jit/JITStubsMSVC64.asm: Added.
         * jit/JSInterfaceJIT.h:
         (JSInterfaceJIT):
         * jit/ThunkGenerators.cpp:
         (JSC::nativeForGenerator):
         * yarr/YarrJIT.cpp:
         (YarrGenerator):
         (JSC::Yarr::YarrGenerator::generateEnter):
         (JSC::Yarr::YarrGenerator::generateReturn):

 2013-02-26  Oliver Hunt  <oliver@apple.com>

         Kill another analyzer warning in javascriptcore
         https://bugs.webkit.org/show_bug.cgi?id=110802

         Reviewed by Benjamin Poulain.

         Add null checks.

         * profiler/LegacyProfiler.cpp:
         (JSC::LegacyProfiler::startProfiling):
         (JSC::LegacyProfiler::stopProfiling):

 2013-02-26  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r144004.
         http://trac.webkit.org/changeset/144004
         https://bugs.webkit.org/show_bug.cgi?id=110858

         This iOS change is outdated (Requested by notbenjamin on
         #webkit).

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::BytecodeGenerator):
         * bytecompiler/BytecodeGenerator.h:
         (JSC::BytecodeGenerator::emitNode):
         (JSC::BytecodeGenerator::emitNodeInConditionContext):
         (BytecodeGenerator):
         * parser/Parser.cpp:
         (JSC::::Parser):
         * parser/Parser.h:
         (JSC::Parser::canRecurse):
         (Parser):

 2013-02-25  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION(r143654): some jquery test asserts on 32 bit debug build
         https://bugs.webkit.org/show_bug.cgi?id=110756

         Reviewed by Geoffrey Garen.

         TypeOf does speculations manually, so it should mark its JSValueOperand as doing ManualOperandSpeculation.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-25  Benjamin Poulain  <bpoulain@apple.com>

         [JSC] Upstream iOS Stack bound checking
         https://bugs.webkit.org/show_bug.cgi?id=110813

         Reviewed by Filip Pizlo.

         On iOS, the StackBounds cannot be cached because the stack
         can be in one of two threads (the web thread or the UI thread).

         We simply always consider the current stack bound when testing
         stack boundaries.

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::BytecodeGenerator):
         * bytecompiler/BytecodeGenerator.h:
         (JSC::BytecodeGenerator::emitNode):
         (JSC::BytecodeGenerator::emitNodeInConditionContext):
         (BytecodeGenerator):
         * parser/Parser.cpp:
         (JSC::::Parser):
         * parser/Parser.h:
         (JSC::Parser::canRecurse):
         (Parser):

 2013-02-25  Michael Saboff  <msaboff@apple.com>

         For JSVALUE32_64, maxOffsetRelativeToPatchedStorage() doesn't compute the maximum negative offset
         https://bugs.webkit.org/show_bug.cgi?id=110828

         Reviewed by Oliver Hunt.

         * runtime/JSObject.h:
         (JSC::maxOffsetRelativeToPatchedStorage): Only add the OBJECT_OFFSETOF(tag) for positive offsets.
         That way this function will return the offset farthest from 0 needed to access either the payload
         or tag.

 2013-02-25  Jeffrey Pfau  <jpfau@apple.com>

         Optionally partition cache to prevent using cache for tracking
         https://bugs.webkit.org/show_bug.cgi?id=110269

         Reviewed by Maciej Stachowiak.

         * Configurations/FeatureDefines.xcconfig: Add defines for cache partitioning and public suffix list usage

 2013-02-25  Roger Fong  <roger_fong@apple.com>

         Unreviewed. VS2010 solution build fix.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:

 2013-02-24  Filip Pizlo  <fpizlo@apple.com>

         DFG::Edge should have more bits for UseKind, and DFG::Allocator should be simpler
         https://bugs.webkit.org/show_bug.cgi?id=110722

         Reviewed by Oliver Hunt.

         This rolls out the DFG::Allocator part of http://trac.webkit.org/changeset/143654,
         and changes Edge to have more room for UseKinds and possibly other things.

         This is performance-neutral on both 32-bit and 64-bit. It reduces the size of
         DFG::Node on 64-bit (by virtue of getting rid of the 16-byte alignment of Node)
         and increases it slightly on 32-bit (by 4 bytes total - 16-byte alignment led to
         80 bytes, but the base size of Node plus the 12 bytes of new m_encodedWords in
         Edge gets 84 bytes). But, it will mean that we don't have to increase Node by
         another 16 bytes if we ever want to add more UseKinds or other things to Edge.

         * dfg/DFGAllocator.h:
         (DFG):
         (Allocator):
         (JSC::DFG::Allocator::Region::headerSize):
         (JSC::DFG::Allocator::Region::numberOfThingsPerRegion):
         (JSC::DFG::Allocator::Region::data):
         (JSC::DFG::Allocator::Region::isInThisRegion):
         (JSC::DFG::::Allocator):
         (JSC::DFG::::~Allocator):
         (JSC::DFG::::allocate):
         (JSC::DFG::::free):
         (JSC::DFG::::freeAll):
         (JSC::DFG::::reset):
         (JSC::DFG::::indexOf):
         (JSC::DFG::::allocatorOf):
         (JSC::DFG::::bumpAllocate):
         (JSC::DFG::::freeListAllocate):
         (JSC::DFG::::allocateSlow):
         (JSC::DFG::::freeRegionsStartingAt):
         (JSC::DFG::::startBumpingIn):
         * dfg/DFGEdge.h:
         (JSC::DFG::Edge::Edge):
         (Edge):
         (JSC::DFG::Edge::node):
         (JSC::DFG::Edge::setNode):
         (JSC::DFG::Edge::useKindUnchecked):
         (JSC::DFG::Edge::setUseKind):
         (JSC::DFG::Edge::operator==):
         (JSC::DFG::Edge::operator!=):
         (JSC::DFG::Edge::makeWord):
         * dfg/DFGNodeAllocator.h:
         (DFG):

 2013-02-22  Filip Pizlo  <fpizlo@apple.com>

         The DFG special case checks for isCreatedThisArgument are fragile
         https://bugs.webkit.org/show_bug.cgi?id=110535

         Reviewed by Oliver Hunt.

         There may be many situations in which we want to force a variable to never be
         unboxed. Capturing is one such case, and the created this argument is another.
         Previously all code that dealt with this issue had to query both scenarios.

         Now DFG::VariableAccessData knows these things. You just have to ask
         VariableAccessData for whether a variable should be unboxed. Anyone wishing to
         force a variable to never be unboxed just tells VariableAccessData.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::initialize):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         (DFG):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (CFGSimplificationPhase):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         * dfg/DFGGraph.h:
         (Graph):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGUnificationPhase.cpp:
         (JSC::DFG::UnificationPhase::run):
         * dfg/DFGVariableAccessData.h:
         (JSC::DFG::VariableAccessData::VariableAccessData):
         (JSC::DFG::VariableAccessData::mergeIsCaptured):
         (JSC::DFG::VariableAccessData::mergeShouldNeverUnbox):
         (VariableAccessData):
         (JSC::DFG::VariableAccessData::shouldNeverUnbox):
         (JSC::DFG::VariableAccessData::shouldUnboxIfPossible):
         (JSC::DFG::VariableAccessData::shouldUseDoubleFormat):
         (JSC::DFG::VariableAccessData::tallyVotesForShouldUseDoubleFormat):

 2013-02-25  Geoffrey Garen  <ggaren@apple.com>

         Do one lookup per code cache insertion instead of two
         https://bugs.webkit.org/show_bug.cgi?id=110674

         Reviewed by Sam Weinig.

         Deployed the idiomatic "add null value" trick to avoid a second hash
         lookup when inserting an item.

         * runtime/CodeCache.cpp:
         (JSC::CodeCacheMap::pruneSlowCase): Factored this into a helper function
         to improve clarity and get some code off the hot path.

         (JSC::CodeCache::getCodeBlock):
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Use the add() API
         to avoid two hash lookups. Be sure to remove items if parsing fails,
         otherwise we'll leave nulls in the table. (I'm guessing that caching parse
         errors is not a win.)

         * runtime/CodeCache.h:
         (JSC::SourceCodeValue::SourceCodeValue):
         (CodeCacheMap):
         (JSC::CodeCacheMap::add): Combined find() and set() into add().

         (JSC::CodeCacheMap::remove):
         (JSC::CodeCacheMap::age):
         (JSC::CodeCacheMap::prune): Refactored to support above changes.

 2013-02-25  Carlos Garcia Campos  <cgarcia@igalia.com>

         [BlackBerry][ARM] Fix cast-align warnings in JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=110738

         Reviewed by Rob Buis.

         Use reinterpret_cast_ptr instead of reinterpret_cast for
         pointers.

         * dfg/DFGOperations.cpp:
         * heap/CopiedBlock.h:
         (JSC::CopiedBlock::zeroFillWilderness):
         * heap/WeakBlock.h:
         (JSC::WeakBlock::asWeakImpl):
         (JSC::WeakBlock::asFreeCell):
         (JSC::WeakBlock::weakImpls):
         * heap/WeakImpl.h:
         (JSC::WeakImpl::asWeakImpl):
         * interpreter/JSStack.cpp:
         (JSC::JSStack::disableErrorStackReserve):
         * interpreter/JSStack.h:
         (JSC::JSStack::reservationEnd):
         * runtime/ArrayStorage.h:
         (JSC::ArrayStorage::from):
         * runtime/Butterfly.h:
         (JSC::Butterfly::indexingPayload):
         * runtime/IndexingHeader.h:
         (JSC::IndexingHeader::propertyStorage):
         * runtime/JSActivation.h:
         (JSC::JSActivation::tearOff):
         (JSC::JSActivation::isTornOff):
         (JSC::JSActivation::storage):

 2013-02-22  Filip Pizlo  <fpizlo@apple.com>

         DFG::SpeculativeJIT::speculateNumber() should just use SpeculateDoubleOperand instead of doing its own thing
         https://bugs.webkit.org/show_bug.cgi?id=110659

         Reviewed by Oliver Hunt and Mark Hahnenberg.

         This simplifies the code, and also has the effect that if speculateNumber() is called
         prior to someone actually using the number in a double context, then the number will
         already be up-converted to double and ready to go.

         Previously if this ever came up, the subsequent use would have to again branch to see
         if the value is tagged as int or tagged as double.

         On the other hand, if you ever did speculateNumber() and then used the value as a
         JSValue, this will be a slow down now.

         I suspect that the former (speculateNumber() and then use as number) is more likely
         than the latter (speculateNumber() and then use as JSValue).

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::speculateNumber):

 2013-02-22  Filip Pizlo  <fpizlo@apple.com>

         DFG FixupPhase should have one common hook for knowing if a node is ever being speculated a certain way
         https://bugs.webkit.org/show_bug.cgi?id=110650

         Reviewed by Mark Hahnenberg.

         Changes almost all calls to edge.setUseKind(kind) to be
         setUseKindAndUnboxIfProfitable<kind>(edge). This will allow us to use the latter
         as a hook for deciding which locals to unbox (webkit.org/b/110433).

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (FixupPhase):
         (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable):
         (JSC::DFG::FixupPhase::fixIntEdge):
         (JSC::DFG::FixupPhase::fixDoubleEdge):
         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):

 2013-02-22  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION(r143654): some fast/js test crashes on 32 bit build
         https://bugs.webkit.org/show_bug.cgi?id=110590

         Reviewed by Mark Hahnenberg.

         In compileValueToInt32, the refactoring in r143654 undid one of the fixes from
         r143314 due to a merge goof.

         In speculateNumber, we were simply forgetting to indicate that we need a
         ManualOperandSpeculation on a JSValueOperand. ManualOperandSpeculation should
         be passed whenever you will be performing the type checks yourself rather than
         using the operand class to do it for you.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         (JSC::DFG::SpeculativeJIT::speculateNumber):

 2013-02-22  Geoffrey Garen  <ggaren@apple.com>

         Not reviewed.

         Fix the 32-bit build by using the right data type in more places.

         * runtime/CodeCache.h:
         (CodeCacheMap):

 2013-02-22  Geoffrey Garen  <ggaren@apple.com>

         Not reviewed.

         Fix the 32-bit build by using the right data type.

         * runtime/CodeCache.h:
         (JSC::CodeCacheMap::find):

 2013-02-21  Geoffrey Garen  <ggaren@apple.com>

         Code cache size should adapt to workload
         https://bugs.webkit.org/show_bug.cgi?id=110560

         Reviewed by Antti Koivisto.

         (*) 5% PLT arithmetic mean speedup
         (*) 10% PLT geometric mean speedup
         (*) 3.4X microbenchmark speedup
         (*) Reduces initial cache capacity by 16X

         * runtime/CodeCache.cpp:
         (JSC::CodeCache::CodeCache): Updated for interface change.

         * runtime/CodeCache.h:
         (JSC::SourceCodeValue::SourceCodeValue):
         (SourceCodeValue): Turned the cache value into a struct so it can track its age.

         (CodeCacheMap):
         (JSC::CodeCacheMap::CodeCacheMap):
         (JSC::CodeCacheMap::find):
         (JSC::CodeCacheMap::set):
         (JSC::CodeCacheMap::clear):
         (JSC::CodeCacheMap::pruneIfNeeded):
         (CodeCache): Grow and shrink in response to usage.

 2013-02-21  Jessie Berlin  <jberlin@apple.com>

         Fix a typo that broke the 32 bit build.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-21  Michael Saboff  <msaboff@apple.com>

         25-30% regression in V8 RayTrace test in 32 bit builds with JIT disabled
         https://bugs.webkit.org/show_bug.cgi?id=110539

         Reviewed by Filip Pizlo.

         Change the scale used to lookup pointers in JSGlobalObject::m_specialPointers to be 4 bytes for
         the 32 bit version of the interpreter.

         * llint/LowLevelInterpreter32_64.asm:

 2013-02-21  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Add executable property to cmd file.
         Required for executable files to maintain their executable permissions over svn.

         * JavaScriptCore.vcxproj/copy-files.cmd: Added property svn:executable.

 2013-02-21  Filip Pizlo  <fpizlo@apple.com>

         Object allocation profiling will refuse to create objects with more than JSFinalObject::maxInlineCapacity() inline slots, but JSFunction::allocationProfile() asserts that the number of inline slots is always what it asked for
         https://bugs.webkit.org/show_bug.cgi?id=110519
         <rdar://problem/13218566>

         Reviewed by Geoffrey Garen.

         * runtime/JSFunction.h:
         (JSC::JSFunction::allocationProfile):

 2013-02-21  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Build fix for VS2010 WebKit solution.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-02-20  Filip Pizlo  <fpizlo@apple.com>

         DFG should not change its mind about what type speculations a node does, by encoding the checks in the NodeType, UseKind, and ArrayMode
         https://bugs.webkit.org/show_bug.cgi?id=109371

         Reviewed by Oliver Hunt.

         FixupPhase now locks in the speculations that each node will do. The DFG then
         remembers those speculations, and doesn't change its mind about them even if the
         graph is transformed - for example if a node's child is repointed to a different
         node as part of CSE, CFG simplification, or folding. Each node ensures that it
         executes the speculations promised by its edges. This is true even for Phantom
         nodes.

         This still leaves some craziness on the table for future work, like the
         elimination of speculating SetLocal's due to CFG simplification
         (webkit.org/b/109388) and elimination of nodes via DCE (webkit.org/b/109389).

         In all, this allows for a huge simplification of the DFG. Instead of having to
         execute the right speculation heuristic each time you want to decide what a node
         does (for example Node::shouldSpeculateInteger(child1, child2) &&
         node->canSpeculateInteger()), you just ask for the use kinds of its children
         (typically node->binaryUseKind() == Int32Use). Because the use kinds are
         discrete, you can often just switch over them. This makes many parts of the code
         more clear than they were before.

         Having UseKinds describe the speculations being performed also makes it far
         easier to perform analyses that need to know what speculations are done. This is
         so far only used to simplify large parts of the CFA.

         To have a larger vocabulary of UseKinds, this also changes the node allocator to
         be able to round up Node sizes to the nearest multiple of 16.

         This appears to be neutral on benchmarks, except for some goofy speed-ups, like
         8% on Octane/box2d.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::startExecuting):
         (DFG):
         (JSC::DFG::AbstractState::executeEdges):
         (JSC::DFG::AbstractState::verifyEdge):
         (JSC::DFG::AbstractState::verifyEdges):
         (JSC::DFG::AbstractState::executeEffects):
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGAbstractState.h:
         (AbstractState):
         (JSC::DFG::AbstractState::filterEdgeByUse):
         (JSC::DFG::AbstractState::filterByType):
         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::filter):
         * dfg/DFGAdjacencyList.h:
         (JSC::DFG::AdjacencyList::AdjacencyList):
         (JSC::DFG::AdjacencyList::child):
         (JSC::DFG::AdjacencyList::setChild):
         (JSC::DFG::AdjacencyList::reset):
         (JSC::DFG::AdjacencyList::firstChild):
         (JSC::DFG::AdjacencyList::setFirstChild):
         (JSC::DFG::AdjacencyList::numChildren):
         (JSC::DFG::AdjacencyList::setNumChildren):
         (AdjacencyList):
         * dfg/DFGAllocator.h:
         (DFG):
         (Allocator):
         (JSC::DFG::Allocator::cellSize):
         (JSC::DFG::Allocator::Region::headerSize):
         (JSC::DFG::Allocator::Region::numberOfThingsPerRegion):
         (JSC::DFG::Allocator::Region::payloadSize):
         (JSC::DFG::Allocator::Region::payloadBegin):
         (JSC::DFG::Allocator::Region::payloadEnd):
         (JSC::DFG::Allocator::Region::isInThisRegion):
         (JSC::DFG::::Allocator):
         (JSC::DFG::::~Allocator):
         (JSC::DFG::::allocate):
         (JSC::DFG::::free):
         (JSC::DFG::::freeAll):
         (JSC::DFG::::reset):
         (JSC::DFG::::indexOf):
         (JSC::DFG::::allocatorOf):
         (JSC::DFG::::bumpAllocate):
         (JSC::DFG::::freeListAllocate):
         (JSC::DFG::::allocateSlow):
         (JSC::DFG::::freeRegionsStartingAt):
         (JSC::DFG::::startBumpingIn):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::addToGraph):
         (JSC::DFG::ByteCodeParser::handleMinMax):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::CSEPhase::setReplacement):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGCommon.h:
         (DFG):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGEdge.cpp:
         (JSC::DFG::Edge::dump):
         * dfg/DFGEdge.h:
         (JSC::DFG::Edge::useKindUnchecked):
         (JSC::DFG::Edge::useKind):
         (JSC::DFG::Edge::shift):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::run):
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::checkArray):
         (JSC::DFG::FixupPhase::blessArrayOperation):
         (JSC::DFG::FixupPhase::fixIntEdge):
         (JSC::DFG::FixupPhase::fixDoubleEdge):
         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
         (FixupPhase):
         (JSC::DFG::FixupPhase::truncateConstantToInt32):
         (JSC::DFG::FixupPhase::truncateConstantsIfNecessary):
         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
         * dfg/DFGGraph.cpp:
         (DFG):
         (JSC::DFG::Graph::refChildren):
         (JSC::DFG::Graph::derefChildren):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::ref):
         (JSC::DFG::Graph::deref):
         (JSC::DFG::Graph::performSubstitution):
         (JSC::DFG::Graph::isPredictedNumerical):
         (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
         (DFG):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::Node):
         (JSC::DFG::Node::convertToGetByOffset):
         (JSC::DFG::Node::convertToPutByOffset):
         (JSC::DFG::Node::willHaveCodeGenOrOSR):
         (JSC::DFG::Node::child1):
         (JSC::DFG::Node::child2):
         (JSC::DFG::Node::child3):
         (JSC::DFG::Node::binaryUseKind):
         (Node):
         (JSC::DFG::Node::isBinaryUseKind):
         * dfg/DFGNodeAllocator.h:
         (DFG):
         * dfg/DFGNodeFlags.cpp:
         (JSC::DFG::nodeFlagsAsString):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (DFG):
         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
         (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
         (JSC::DFG::SpeculativeJIT::typeCheck):
         (JSC::DFG::SpeculativeJIT::forwardTypeCheck):
         (JSC::DFG::SpeculativeJIT::fillStorage):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
         (JSC::DFG::SpeculativeJIT::compile):
         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
         (JSC::DFG::SpeculativeJIT::compileAdd):
         (JSC::DFG::SpeculativeJIT::compileArithSub):
         (JSC::DFG::SpeculativeJIT::compileArithNegate):
         (JSC::DFG::SpeculativeJIT::compileArithMul):
         (JSC::DFG::SpeculativeJIT::compileArithMod):
         (JSC::DFG::SpeculativeJIT::compare):
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         (JSC::DFG::SpeculativeJIT::speculateInt32):
         (JSC::DFG::SpeculativeJIT::speculateNumber):
         (JSC::DFG::SpeculativeJIT::speculateRealNumber):
         (JSC::DFG::SpeculativeJIT::speculateBoolean):
         (JSC::DFG::SpeculativeJIT::speculateCell):
         (JSC::DFG::SpeculativeJIT::speculateObject):
         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
         (JSC::DFG::SpeculativeJIT::speculateString):
         (JSC::DFG::SpeculativeJIT::speculateNotCell):
         (JSC::DFG::SpeculativeJIT::speculateOther):
         (JSC::DFG::SpeculativeJIT::speculate):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::valueOfNumberConstant):
         (JSC::DFG::SpeculativeJIT::needsTypeCheck):
         (JSC::DFG::IntegerOperand::IntegerOperand):
         (JSC::DFG::IntegerOperand::edge):
         (IntegerOperand):
         (JSC::DFG::IntegerOperand::node):
         (JSC::DFG::IntegerOperand::gpr):
         (JSC::DFG::IntegerOperand::use):
         (JSC::DFG::JSValueOperand::JSValueOperand):
         (JSValueOperand):
         (JSC::DFG::JSValueOperand::edge):
         (JSC::DFG::JSValueOperand::node):
         (JSC::DFG::JSValueOperand::gpr):
         (JSC::DFG::JSValueOperand::fill):
         (JSC::DFG::JSValueOperand::use):
         (JSC::DFG::StorageOperand::StorageOperand):
         (JSC::DFG::StorageOperand::edge):
         (StorageOperand):
         (JSC::DFG::StorageOperand::node):
         (JSC::DFG::StorageOperand::gpr):
         (JSC::DFG::StorageOperand::use):
         (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand):
         (SpeculateIntegerOperand):
         (JSC::DFG::SpeculateIntegerOperand::edge):
         (JSC::DFG::SpeculateIntegerOperand::node):
         (JSC::DFG::SpeculateIntegerOperand::gpr):
         (JSC::DFG::SpeculateIntegerOperand::use):
         (JSC::DFG::SpeculateStrictInt32Operand::SpeculateStrictInt32Operand):
         (SpeculateStrictInt32Operand):
         (JSC::DFG::SpeculateStrictInt32Operand::edge):
         (JSC::DFG::SpeculateStrictInt32Operand::node):
         (JSC::DFG::SpeculateStrictInt32Operand::gpr):
         (JSC::DFG::SpeculateStrictInt32Operand::use):
         (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
         (SpeculateDoubleOperand):
         (JSC::DFG::SpeculateDoubleOperand::edge):
         (JSC::DFG::SpeculateDoubleOperand::node):
         (JSC::DFG::SpeculateDoubleOperand::fpr):
         (JSC::DFG::SpeculateDoubleOperand::use):
         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
         (SpeculateCellOperand):
         (JSC::DFG::SpeculateCellOperand::edge):
         (JSC::DFG::SpeculateCellOperand::node):
         (JSC::DFG::SpeculateCellOperand::gpr):
         (JSC::DFG::SpeculateCellOperand::use):
         (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
         (JSC::DFG::SpeculateBooleanOperand::edge):
         (SpeculateBooleanOperand):
         (JSC::DFG::SpeculateBooleanOperand::node):
         (JSC::DFG::SpeculateBooleanOperand::gpr):
         (JSC::DFG::SpeculateBooleanOperand::use):
         (DFG):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         * dfg/DFGUseKind.cpp: Added.
         (WTF):
         (WTF::printInternal):
         * dfg/DFGUseKind.h: Added.
         (DFG):
         (JSC::DFG::typeFilterFor):
         (JSC::DFG::isNumerical):
         (WTF):
         * dfg/DFGValidate.cpp:
         (JSC::DFG::Validate::reportValidationContext):

 2013-02-20  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Need a way to use the Objective-C JavaScript API with WebKit
         https://bugs.webkit.org/show_bug.cgi?id=106059

         Reviewed by Geoffrey Garen.

         * API/JSBase.h: Renamed enable flag for API.
         * API/JSBlockAdaptor.h: Using new flag.
         * API/JSBlockAdaptor.mm: Ditto.
         * API/JSContext.h: Add convenience C API conversion function for JSGlobalContextRef.
         * API/JSContext.mm:
         (-[JSContext JSGlobalContextRef]): Implementation of C API convenience function.
         (-[JSContext initWithVirtualMachine:]): We don't use the m_apiData field any more.
         (-[JSContext initWithGlobalContextRef:]): init method for allocating new JSContexts given a JSGlobalContextRef.
         (-[JSContext dealloc]): No more m_apiData.
         (-[JSContext wrapperForObjCObject:]): Renamed wrapperForObject.
         (-[JSContext wrapperForJSObject:]): Fetches or allocates the JSValue for the specified JSValueRef in this JSContext.
         (+[JSContext contextWithGlobalContextRef:]): Helper function to grab the lightweight JSContext wrapper for a given
         JSGlobalContextRef from the global wrapper cache or allocate a new one if there isn't already one.
         * API/JSContextInternal.h: New flag, new method declaration for initWithGlobalContextRef.
         * API/JSExport.h: New flag.
         * API/JSValue.h: New flag and new C API convenience method.
         * API/JSValue.mm:
         (-[JSValue JSValueRef]): Implementation of the C API convenience method.
         (objectToValueWithoutCopy):
         (+[JSValue valueWithValue:inContext:]): We now ask the JSContext for an Objective-C JSValue wrapper, which it can cache
         in its internal JSWrapperMap.
         * API/JSValueInternal.h:
         * API/JSVirtualMachine.h:
         * API/JSVirtualMachine.mm: Added global cache that maps JSContextGroupRef -> JSVirtualMachine lightweight wrappers.
         (wrapperCacheLock):
         (initWrapperCache):
         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
         (-[JSVirtualMachine init]):
         (-[JSVirtualMachine initWithContextGroupRef:]):
         (-[JSVirtualMachine dealloc]):
         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
         (-[JSVirtualMachine contextForGlobalContextRef:]):
         (-[JSVirtualMachine addContext:forGlobalContextRef:]):
         * API/JSVirtualMachineInternal.h:
         * API/JSWrapperMap.h:
         * API/JSWrapperMap.mm:
         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We use the JSObjectSetPrototype C API call because
         setting the __proto__ property causes all sorts of bad things to happen behind the scenes, which can cause crashes based on
         when it gets called.
         (-[JSWrapperMap initWithContext:]):
         (-[JSWrapperMap jsWrapperForObject:]):
         (-[JSWrapperMap objcWrapperForJSValueRef:]):
         * API/JavaScriptCore.h:
         * API/ObjCCallbackFunction.h:
         * API/ObjCCallbackFunction.mm:
         (ObjCCallbackFunction::ObjCCallbackFunction): We never actually should have retained the target in the case that we had a
         block as a callback. Blocks are initially allocated on the stack and are only moved to the heap if we call their copy method.
         Retaining the block on the stack was a bad idea because if that stack frame ever went away and we called the block later,
         we'd crash and burn.
         (ObjCCallbackFunction::setContext): We need a new setter for when the weak reference to a JSContext inside an ObjCCallbackFunction
         disappears, we can allocate a new one in its place.
         (ObjCCallbackFunction):
         (objCCallbackFunctionCallAsFunction): Reset the callback's context if it's ever destroyed.
         (objCCallbackFunctionForInvocation): Again, don't set the __proto__ property because it uses black magic that can cause us to crash
         depending on when this is called.
         (objCCallbackFunctionForBlock): Here is where we copy the block to the heap when we're first creating the callback object for it.
         * API/tests/testapi.c:
         (main):
         * API/tests/testapi.mm: We're going to get rid of the automatic block conversion, since that is causing leaks. I changed it
         here in this test just so that it wouldn't mask any other potential leaks. Also modified some of the tests since JSContexts are
         just lightweight wrappers now, we're not guaranteed to get the same pointer back from the call to [JSValue context] as the one
         that the value was created in.
         (-[TestObject callback:]):
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData): No more m_apiData.
         * runtime/JSGlobalData.h: Ditto.
         * runtime/JSGlobalObject.cpp:
         (JSC::JSGlobalObject::JSGlobalObject): Ditto.
         * runtime/JSGlobalObject.h:

 2013-02-19  Filip Pizlo  <fpizlo@apple.com>

         DFG::SpeculativeJIT::compileInt32ToDouble() has an unnecessary case for constant operands
         https://bugs.webkit.org/show_bug.cgi?id=110309

         Reviewed by Sam Weinig.

         It used to be necessary, back when we didn't have constant folding. Now we have
         constant folding. So we don't need it.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):

 2013-02-20  Filip Pizlo  <fpizlo@apple.com>

         DFG inlines Resolves that it doesn't know how to handle correctly
         https://bugs.webkit.org/show_bug.cgi?id=110405

         Reviewed by Geoffrey Garen.

         Don't try to be clever: if there's a failing resolve, we can't inline it, period.

         * dfg/DFGCapabilities.h:
         (JSC::DFG::canInlineResolveOperations):
         (JSC::DFG::canInlineOpcode):

 2013-02-20  Roger Fong  <roger_fong@apple.com>

         Get VS2010 Solution B&I ready.
         <rdar://problem/1322988>

         Rubberstamped by Timothy Horton.

         Add Production configuration.
         Add a JavaScriptCore submit solution with a DebugSuffix configuration.
         Modify JavaScriptCore.make as necessary.

         * JavaScriptCore.vcxproj/JavaScriptCore.make: Added.
         * JavaScriptCore.vcxproj/JavaScriptCore.sln: Removed.
         * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCore.sln.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props:
         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props:
         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Added.
         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props:
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
         * JavaScriptCore.vcxproj/jsc/jscCommon.props:
         * JavaScriptCore.vcxproj/jsc/jscProduction.props: Added.
         * JavaScriptCore.vcxproj/jsc/jscRelease.props:
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
         * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
         * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props:
         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
         * JavaScriptCore.vcxproj/testapi/testapiCommon.props:
         * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Added.
         * JavaScriptCore.vcxproj/testapi/testapiRelease.props:

 2013-02-19  Jer Noble  <jer.noble@apple.com>

         EME: Enable both ENCRYPTED_MEDIA and ENCRYPTED_MEDIA_V2 until clients transition to the new API.
         https://bugs.webkit.org/show_bug.cgi?id=110284

         Reviewed by Eric Carlson.

         Re-enable the ENCRYPTED_MEDIA flag.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-20  Dirk Schulze  <krit@webkit.org>

         Enable CANVAS_PATH flag
         https://bugs.webkit.org/show_bug.cgi?id=108508

         Reviewed by Simon Fraser.

         Enable CANVAS_PATH flag on trunk.

         Existing tests cover the feature.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-19  Mark Rowe  <mrowe@apple.com>

         Unreviewed, uninteresting change to test a theory about bad dependency handling.

         * API/JSStringRefCF.cpp:
         (JSStringCreateWithCFString): Remove an unnecessary else clause.

 2013-02-19  Oliver Hunt  <oliver@apple.com>

         Silence some analyzer warnings
         https://bugs.webkit.org/show_bug.cgi?id=110281

         Reviewed by Mark Hahnenberg.

         The static analyzer believes that callerCodeBlock can be null,
         based on other code performing null tests.  This should not
         ever be the case, but we'll add RELEASE_ASSERTs to make it
         obvious if we're ever wrong.

         * interpreter/Interpreter.cpp:
         (JSC::getCallerInfo):

 2013-02-19  Oliver Hunt  <oliver@apple.com>

         Don't force everything to be blinded in debug builds
         https://bugs.webkit.org/show_bug.cgi?id=110279

         Reviewed by Mark Hahnenberg.

         Switch to an explicit flag for indicating that we want
         every constant to be blinded.

         * assembler/MacroAssembler.h:
         (JSC::MacroAssembler::shouldBlind):

 2013-02-19  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation of Opcode.h

         Rubber stamped by Mark Hahnenberg.

         * bytecode/Opcode.h:

 2013-02-19  Filip Pizlo  <fpizlo@apple.com>

         Moved PolymorphicAccessStructureList into its own file.

         Rubber stamped by Mark Hahnenberg.

         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * bytecode/Instruction.h:
         (JSC):
         * bytecode/PolymorphicAccessStructureList.h: Added.
         (JSC):
         (PolymorphicAccessStructureList):
         (PolymorphicStubInfo):
         (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::PolymorphicStubInfo):
         (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set):
         (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList):
         (JSC::PolymorphicAccessStructureList::visitWeak):
         * bytecode/StructureStubInfo.h:

 2013-02-19  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation of Instruction.h

         Rubber stamped by Mark Hahnenberg.

         * bytecode/Instruction.h:

 2013-02-18  Geoffrey Garen  <ggaren@apple.com>

         Unreviewed, rolling in r143348.
         http://trac.webkit.org/changeset/143348
         https://bugs.webkit.org/show_bug.cgi?id=110242

         The bug was that isEmptyValue() was returning true for the deleted value.
         Fixed this and simplified things further by delegating to m_sourceCode
         for both isNull() and isHashTableDeletedValue(), so they can't be out of
         sync.

         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         * runtime/CodeCache.h:
         (JSC::SourceCodeKey::SourceCodeKey):
         (JSC::SourceCodeKey::isHashTableDeletedValue):
         (JSC::SourceCodeKey::hash):
         (JSC::SourceCodeKey::length):
         (JSC::SourceCodeKey::isNull):
         (JSC::SourceCodeKey::operator==):
         (SourceCodeKey):

 2013-02-15  Martin Robinson  <mrobinson@igalia.com>

         [GTK] Improve gyp build JavaScriptCore code generation
         https://bugs.webkit.org/show_bug.cgi?id=109969

         Reviewed by Dirk Pranke.

         Switch away from using DerivedSources.make when building JavaScriptCore generated
         sources. This bring a couple advantages, such as building the sources in parallel,
         but requires us to list the generated sources more than once.

         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Add rules for generating JavaScriptCore sources.
         * JavaScriptCore.gyp/generate-derived-sources.sh: Added.
         * JavaScriptCore.gyp/redirect-stdout.sh: Added.

 2013-02-19  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r143348.
         http://trac.webkit.org/changeset/143348
         https://bugs.webkit.org/show_bug.cgi?id=110242

         "Caused a deleted value sentinel crash on the layout tests"
         (Requested by ggaren on #webkit).

         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         * runtime/CodeCache.h:
         (JSC::SourceCodeKey::SourceCodeKey):
         (JSC::SourceCodeKey::isHashTableDeletedValue):
         (JSC::SourceCodeKey::hash):
         (JSC::SourceCodeKey::length):
         (JSC::SourceCodeKey::isNull):
         (JSC::SourceCodeKey::operator==):
         (SourceCodeKey):

 2013-02-19  Mark Hahnenberg  <mhahnenberg@apple.com>

         HeapBlock::destroy should issue warning if result is unused
         https://bugs.webkit.org/show_bug.cgi?id=110233

         Reviewed by Oliver Hunt.

         To enforce the fact that we need to return blocks to the BlockAllocator after calling destroy,
         we should add WARN_UNUSED_RETURN to HeapBlock::destroy and any other destroy functions in its subclasses.

         * heap/HeapBlock.h:

 2013-02-19  Mark Hahnenberg  <mhahnenberg@apple.com>

         WeakSet::removeAllocator leaks WeakBlocks
         https://bugs.webkit.org/show_bug.cgi?id=110228

         Reviewed by Geoffrey Garen.

         We need to return the WeakBlock to the BlockAllocator after the call to WeakBlock::destroy.

         * heap/WeakSet.cpp:
         (JSC::WeakSet::removeAllocator):

 2013-02-18  Geoffrey Garen  <ggaren@apple.com>

         Save space on keys in the CodeCache
         https://bugs.webkit.org/show_bug.cgi?id=110179

         Reviewed by Oliver Hunt.

         Share the SourceProvider's string instead of making our own copy. This
         chops off 16MB - 32MB from the CodeCache's memory footprint when full.
         (It's 16MB when the strings are LChar, and 32MB when they're UChar.)

         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         * runtime/CodeCache.h: Removed a defunct enum value.

         (JSC::SourceCodeKey::SourceCodeKey):
         (JSC::SourceCodeKey::isHashTableDeletedValue):
         (SourceCodeKey):
         (JSC::SourceCodeKey::hash):
         (JSC::SourceCodeKey::length):
         (JSC::SourceCodeKey::isNull):
         (JSC::SourceCodeKey::string):
         (JSC::SourceCodeKey::operator==): Store a SourceCode instead of a String
         so we can share our string with our SourceProvider. Cache our hash so
         we don't have to re-decode our string just to re-hash the table.

 2013-02-19  Zoltan Herczeg  <zherczeg@webkit.org>

         revertBranchPtrWithPatch is incorrect on ARM traditional
         https://bugs.webkit.org/show_bug.cgi?id=110201

         Reviewed by Oliver Hunt.

         Revert two instructions back to their original value.

         * assembler/ARMAssembler.h:
         (JSC::ARMAssembler::revertBranchPtrWithPatch):
         (ARMAssembler):
         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::branchPtrWithPatch):
         (JSC::MacroAssemblerARM::revertJumpReplacementToBranchPtrWithPatch):

 2013-02-19  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION(r143241): It made 27 layout tests crash on 32 bit platforms
         https://bugs.webkit.org/show_bug.cgi?id=110184

         Reviewed by Zoltan Herczeg.

         32-bit backend was making all sorts of crazy assumptions, which happened to mostly
         not break things prior to http://trac.webkit.org/changeset/143241. This brings the
         32-bit backend's type speculation fully into compliance with what the 64-bit
         backend does.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):

 2013-02-18  Ilya Tikhonovsky  <loislo@chromium.org>

         Unreviewed build fix for Apple Windows. Second stage.
         Add missed export statement.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-02-18  Roger Fong  <roger_fong@apple.com>

         Unreviewed Windows build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-02-18  Darin Adler  <darin@apple.com>

         Remove unneeded explicit function template arguments.
         https://bugs.webkit.org/show_bug.cgi?id=110043

         Reviewed by Ryosuke Niwa.

         * runtime/Identifier.cpp:
         (JSC::IdentifierASCIIStringTranslator::hash): Let the compiler deduce the type
         when calling computeHashAndMaskTop8Bits.
         (JSC::IdentifierLCharFromUCharTranslator::hash): Ditto.
         * runtime/Identifier.h:
         (JSC::IdentifierCharBufferTranslator::hash): Ditto.
 2013-02-18  Geoffrey Garen  <ggaren@apple.com>

         Shrank the SourceProvider cache
         https://bugs.webkit.org/show_bug.cgi?id=110158

         Reviewed by Oliver Hunt.

         CodeCache is now our primary source cache, so a long-lived SourceProvider
         cache is a waste. I measured this as a 10MB Membuster win; with more
         precise instrumentation, Andreas estimated it as up to 30MB.

         I didn't eliminate the SourceProvider cache because it's still useful
         in speeding up uncached parsing of scripts with large nested functions
         (i.e., all scripts).

         * heap/Heap.cpp:
         (JSC::Heap::collect): Discard all source provider caches after GC. This
         is a convenient place to do so because it's reasonably soon after initial
         parsing without being immediate.

         * parser/Parser.cpp:
         (JSC::::Parser): Updated for interface change: The heap now owns the
         source provider cache, since most SourceProviders are not expected to
         have one by default, and the heap is responsible for throwing them away.

         (JSC::::parseInner): No need to update statistics on cache size, since
         we're going to throw it away no matter what.

         (JSC::::parseFunctionInfo): Reduced the minimum function size to 16. This
         is a 27% win on a new parsing micro-benchmark I've added. Now that the
         cache is temporary, we don't have to worry so much about its memory
         footprint.

         * parser/Parser.h:
         (Parser): Updated for interface changes.

         * parser/SourceProvider.cpp:
         (JSC::SourceProvider::SourceProvider):
         (JSC::SourceProvider::~SourceProvider):
         * parser/SourceProvider.h:
         (JSC):
         (SourceProvider): SourceProvider doesn't own its cache anymore because
         the cache is temporary.

         * parser/SourceProviderCache.cpp:
         (JSC::SourceProviderCache::clear):
         (JSC::SourceProviderCache::add):
         * parser/SourceProviderCache.h:
         (JSC::SourceProviderCache::SourceProviderCache):
         (SourceProviderCache):
         * parser/SourceProviderCacheItem.h:
         (SourceProviderCacheItem): No need to update statistics on cache size,
         since we're going to throw it away no matter what.

         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::addSourceProviderCache):
         (JSC):
         (JSC::JSGlobalData::clearSourceProviderCaches):
         * runtime/JSGlobalData.h:
         (JSC):
         (JSGlobalData): Moved the cache here so it's easier to throw away.

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         DFG backend Branch handling has duplicate code and dead code
         https://bugs.webkit.org/show_bug.cgi?id=110162

         Reviewed by Mark Hahnenberg.

         Streamline the code, and make the 64 backend's optimizations make more sense
         (i.e. not be dead code).

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-18  Brent Fulgham  <bfulgham@webkit.org>

         [Windows] Unreviewed VS2010 build correction after r143273.

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing source
         file SourceProvider.cpp.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Add missing exports.

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Structure::flattenDictionaryStructure should compute max offset in a manner that soundly handles the case where the property list becomes empty
         https://bugs.webkit.org/show_bug.cgi?id=110155
         <rdar://problem/13233773>

         Reviewed by Mark Rowe.

         This was a rookie mistake.  It was doing:

         for (blah) {
             m_offset = foo // foo's monotonically increase in the loop
         }

         as a way of computing max offset for all of the properties.  Except what if the loop doesn't
         execute because there are no properties?  Well, then, you're going to have a bogus m_offset.

         The solution is to initialize m_offset at the top of the loop.

         * runtime/Structure.cpp:
         (JSC::Structure::flattenDictionaryStructure):

 2013-02-18  Balazs Kilvady  <kilvadyb@homejinni.com>

         MIPS DFG implementation.
         https://bugs.webkit.org/show_bug.cgi?id=101328

         Reviewed by Oliver Hunt.

         DFG implementation for MIPS.

         * assembler/MIPSAssembler.h:
         (JSC::MIPSAssembler::MIPSAssembler):
         (JSC::MIPSAssembler::sllv):
         (JSC::MIPSAssembler::movd):
         (MIPSAssembler):
         (JSC::MIPSAssembler::negd):
         (JSC::MIPSAssembler::labelForWatchpoint):
         (JSC::MIPSAssembler::label):
         (JSC::MIPSAssembler::vmov):
         (JSC::MIPSAssembler::linkDirectJump):
         (JSC::MIPSAssembler::maxJumpReplacementSize):
         (JSC::MIPSAssembler::revertJumpToMove):
         (JSC::MIPSAssembler::replaceWithJump):
         * assembler/MacroAssembler.h:
         (MacroAssembler):
         (JSC::MacroAssembler::poke):
         * assembler/MacroAssemblerMIPS.h:
         (JSC::MacroAssemblerMIPS::add32):
         (MacroAssemblerMIPS):
         (JSC::MacroAssemblerMIPS::and32):
         (JSC::MacroAssemblerMIPS::lshift32):
         (JSC::MacroAssemblerMIPS::mul32):
         (JSC::MacroAssemblerMIPS::or32):
         (JSC::MacroAssemblerMIPS::rshift32):
         (JSC::MacroAssemblerMIPS::urshift32):
         (JSC::MacroAssemblerMIPS::sub32):
         (JSC::MacroAssemblerMIPS::xor32):
         (JSC::MacroAssemblerMIPS::store32):
         (JSC::MacroAssemblerMIPS::jump):
         (JSC::MacroAssemblerMIPS::branchAdd32):
         (JSC::MacroAssemblerMIPS::branchMul32):
         (JSC::MacroAssemblerMIPS::branchSub32):
         (JSC::MacroAssemblerMIPS::branchNeg32):
         (JSC::MacroAssemblerMIPS::call):
         (JSC::MacroAssemblerMIPS::loadDouble):
         (JSC::MacroAssemblerMIPS::moveDouble):
         (JSC::MacroAssemblerMIPS::swapDouble):
         (JSC::MacroAssemblerMIPS::subDouble):
         (JSC::MacroAssemblerMIPS::mulDouble):
         (JSC::MacroAssemblerMIPS::divDouble):
         (JSC::MacroAssemblerMIPS::negateDouble):
         (JSC::MacroAssemblerMIPS::branchEqual):
         (JSC::MacroAssemblerMIPS::branchNotEqual):
         (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32):
         (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32):
         (JSC::MacroAssemblerMIPS::truncateDoubleToInt32):
         (JSC::MacroAssemblerMIPS::truncateDoubleToUint32):
         (JSC::MacroAssemblerMIPS::branchDoubleNonZero):
         (JSC::MacroAssemblerMIPS::branchDoubleZeroOrNaN):
         (JSC::MacroAssemblerMIPS::invert):
         (JSC::MacroAssemblerMIPS::replaceWithJump):
         (JSC::MacroAssemblerMIPS::maxJumpReplacementSize):
         * dfg/DFGAssemblyHelpers.h:
         (AssemblyHelpers):
         (JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall):
         (JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn):
         (JSC::DFG::AssemblyHelpers::debugCall):
         * dfg/DFGCCallHelpers.h:
         (CCallHelpers):
         (JSC::DFG::CCallHelpers::setupArguments):
         (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
         * dfg/DFGFPRInfo.h:
         (DFG):
         (FPRInfo):
         (JSC::DFG::FPRInfo::toRegister):
         (JSC::DFG::FPRInfo::toIndex):
         (JSC::DFG::FPRInfo::debugName):
         * dfg/DFGGPRInfo.h:
         (DFG):
         (GPRInfo):
         (JSC::DFG::GPRInfo::toRegister):
         (JSC::DFG::GPRInfo::toIndex):
         (JSC::DFG::GPRInfo::debugName):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * jit/JSInterfaceJIT.h:
         (JSInterfaceJIT):
         * runtime/JSGlobalData.h:
         (JSC::ScratchBuffer::allocationSize):
         (ScratchBuffer):

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         DFG::SpeculativeJIT::isKnownXYZ methods should use CFA rather than other things
         https://bugs.webkit.org/show_bug.cgi?id=110092

         Reviewed by Geoffrey Garen.

         These methods were previously using GenerationInfo and other things to try to
         gain information that the CFA could give away for free, if you asked kindly
         enough.

         Also fixed CallLinkStatus's dump() method since it was making an invalid
         assertion: we most certainly can have a status where the structure is non-null
         and the executable is null, like if we're dealing with an InternalFunction.

         Also removed calls to isKnownNotXYZ from fillSpeculateABC methods in 32_64. I
         don't know why that was there. But it was causing asserts if the value was
         empty - i.e. we had already exited unconditionally but we didn't know it. I
         could have fixed this by introducing another form of isKnownNotXYZ which was
         tolerant of empty values, but I didn't feel like fixing code that I knew to be
         unnecessary. (More deeply, isKnownNotCell, for example, really asks: "do you
         know that this value can never be a cell?" while some of the previous uses
         wanted to ask: "do you know that this is a value that is not a cell?". The
         former is "true" if the value is a contradiction [i.e. BOTTOM], while the
         latter is "false" for contradictions, since contradictions are not values.)

         * bytecode/CallLinkStatus.cpp:
         (JSC::CallLinkStatus::dump):
         * bytecode/CallLinkStatus.h:
         (JSC::CallLinkStatus::CallLinkStatus):
         * dfg/DFGSpeculativeJIT.cpp:
         (DFG):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::isKnownInteger):
         (JSC::DFG::SpeculativeJIT::isKnownCell):
         (JSC::DFG::SpeculativeJIT::isKnownNotInteger):
         (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
         (JSC::DFG::SpeculativeJIT::isKnownNotCell):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         * dfg/DFGStructureAbstractValue.h:
         (JSC::DFG::StructureAbstractValue::dump):

 2013-02-17  Filip Pizlo  <fpizlo@apple.com>

         Get rid of DFG::DoubleOperand and simplify ValueToInt32
         https://bugs.webkit.org/show_bug.cgi?id=110072

         Reviewed by Geoffrey Garen.

         ValueToInt32 had a side-effecting path, which was not OSR-friendly: an OSR after
         the side-effect would lead to the side-effect re-executing. I got rid of that path
         and replaced it with an optimization for the case where the input is speculated
         number-or-other. This makes idioms like null|0 and true|0 work as expected, and
         get optimized appropriately.

         Also got rid of DoubleOperand. Replaced all remaining uses of it with
         SpeculateDoubleOperand. Because the latter asserts that the Edge is a DoubleUse
         edge and the remaining uses of DoubleOperand are all for untyped uses, I worked
         around the assertion by setting the UseKind to DoubleUse by force. This is sound,
         since all existing assertions for DoubleUse are actually asserting that we're not
         converting a value to double unexpectedly. But all of these calls to
         SpeculateDoubleOperand are when the operand is already known to be represented as
         double, so there is no conversion.

         This is neutral on benchmarks, except stanford-crypto-ccm, which speeds up a
         little. Mostly, this is intended to delete a bunch of code. DoubleOperand was
         equivalent to the replace-edge-with-DoubleUse trick that I'm using now, except it
         involved a _lot_ more code.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGSpeculativeJIT.cpp:
         (DFG):
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (DFG):
         (FPRTemporary):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (DFG):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (DFG):

 2013-02-18  Ádám Kallai  <kadam@inf.u-szeged.hu>

         [Qt] Mountain Lion buildfix after r143147.

         Reviewed by Csaba Osztrogonác.

         * runtime/DateConstructor.cpp:

 2013-02-18  Zan Dobersek  <zdobersek@igalia.com>

         Stop placing std::isfinite and std::signbit inside the global scope
         https://bugs.webkit.org/show_bug.cgi?id=109817

         Reviewed by Darin Adler.

         Prefix calls to the isfinite and signbit methods with std:: as the two
         methods are no longer being imported into the global scope.

         * assembler/MacroAssembler.h:
         (JSC::MacroAssembler::shouldBlindDouble):
         * offlineasm/cloop.rb:
         * runtime/BigInteger.h:
         (JSC::BigInteger::BigInteger):
         * runtime/DateConstructor.cpp:
         (JSC::constructDate):
         * runtime/DatePrototype.cpp:
         (JSC::fillStructuresUsingTimeArgs):
         (JSC::fillStructuresUsingDateArgs):
         (JSC::dateProtoFuncToISOString):
         (JSC::dateProtoFuncSetYear):
         * runtime/JSCJSValueInlines.h:
         (JSC::JSValue::JSValue):
         * runtime/JSGlobalObjectFunctions.cpp:
         (JSC::globalFuncIsFinite):
         * runtime/JSONObject.cpp:
         (JSC::Stringifier::appendStringifiedValue):
         * runtime/MathObject.cpp:
         (JSC::mathProtoFuncMax): Also include an opportunistic style fix.
         (JSC::mathProtoFuncMin): Ditto.
         * runtime/NumberPrototype.cpp:
         (JSC::toStringWithRadix):
         (JSC::numberProtoFuncToExponential):
         (JSC::numberProtoFuncToFixed):
         (JSC::numberProtoFuncToPrecision):
         (JSC::numberProtoFuncToString):
         * runtime/Uint16WithFraction.h:
         (JSC::Uint16WithFraction::Uint16WithFraction):

 2013-02-18  Ádám Kallai  <kadam@inf.u-szeged.hu>

         [Qt] Mountain Lion buildfix after r143147.

         Reviewed by Csaba Osztrogonác.

         * runtime/DateInstance.cpp:

 2013-02-18  Ilya Tikhonovsky  <loislo@chromium.org>

         Unreviewed speculative build fix for Apple Win bots.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation of StructureStubInfo.h

         Rubber stamped by Mark Hahnenberg.

         * bytecode/StructureStubInfo.h:

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation of JSGlobalObject.h and JSGlobalObjectFunctions.h

         Rubber stamped by Mark Hahnenberg.

         * runtime/JSGlobalObject.h:
         * runtime/JSGlobalObjectFunctions.h:

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Fix indention of Operations.h

         Rubber stamped by Mark Hahnenberg.

         * runtime/Operations.h:

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Remove DFG::SpeculativeJIT::isKnownNumeric(), since it's not called from anywhere.

         Rubber stamped by Andy Estes.

         * dfg/DFGSpeculativeJIT.cpp:
         (DFG):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Remove DFG::SpeculativeJIT::isStrictInt32(), since it's not called from anywhere.

         Rubber stampted by Andy Estes.

         * dfg/DFGSpeculativeJIT.cpp:
         (DFG):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):

 2013-02-18  Filip Pizlo  <fpizlo@apple.com>

         Remove dead code for ValueToNumber from the DFG.

         Rubber stamped by Andy Estes.

         We killed ValueToNumber at some point, but forgot to kill all of the backend support
         for it.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleMinMax):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         * dfg/DFGSpeculativeJIT64.cpp:

 2013-02-17  Csaba Osztrogonác  <ossy@webkit.org>

         Unreviewed buildfix for JSVALUE32_64 builds after r143147.

         * jit/JIT.h:

 2013-02-17  Filip Pizlo  <fpizlo@apple.com>

         Move all Structure out-of-line inline methods to StructureInlines.h
         https://bugs.webkit.org/show_bug.cgi?id=110024

         Rubber stamped by Mark Hahnenberg and Sam Weinig.

         This was supposed to be easy.

         But, initially, there was a Structure inline method in CodeBlock.h, and moving that
         into StructureInlines.h meant that Operations.h included CodeBlock.h. This would
         cause WebCore build failures, because CodeBlock.h transitively included the JSC
         parser (via many, many paths), and the JSC parser defines tokens using enumeration
         elements that CSSGrammar.cpp (generated by bison) would #define. For example,
         bison would give CSSGrammar.cpp a #define FUNCTION 123, and would do so before
         including anything interesting. The JSC parser would have an enum that included
         FUNCTION as an element. Hence the JSC parser included into CSSGrammar.cpp would have
         a token element called FUNCTION declared in an enumeration, but FUNCTION was
         #define'd to 123, leading to a parser error.

         Wow.

         So I removed all transitive include paths from CodeBlock.h to the JSC Parser. I
         believe I was able to do so without out-of-lining anything interesting or performance
         critical. This is probably a purely good thing to have done: it will be nice to be
         able to make changes to the parser without having to compile the universe.

         Of course, doing this caused a bunch of other things to not compile, since a bunch of
         headers relied on things being implicitly included for them when they transitively
         included the parser. I fixed a lot of that.

         Finally, I ended up removing the method that depended on CodeBlock.h from
         StructureInlines.h, and putting it in Structure.cpp. That might seem like all of this
         was a waste of time, except that I suspect it was a worthwhile forcing function for
         cleaning up a bunch of cruft.

         * API/JSCallbackFunction.cpp:
         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/CodeBlock.h:
         (JSC):
         * bytecode/EvalCodeCache.h:
         * bytecode/SamplingTool.h:
         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::UnlinkedFunctionExecutable::parameterCount):
         (JSC):
         * bytecode/UnlinkedCodeBlock.h:
         (UnlinkedFunctionExecutable):
         * bytecompiler/BytecodeGenerator.h:
         * bytecompiler/Label.h:
         (JSC):
         * dfg/DFGByteCodeParser.cpp:
         * dfg/DFGByteCodeParser.h:
         * dfg/DFGFPRInfo.h:
         * dfg/DFGRegisterBank.h:
         * heap/HandleStack.cpp:
         * jit/JITWriteBarrier.h:
         * parser/Nodes.h:
         (JSC):
         * parser/Parser.h:
         * parser/ParserError.h: Added.
         (JSC):
         (JSC::ParserError::ParserError):
         (ParserError):
         (JSC::ParserError::toErrorObject):
         * parser/ParserModes.h:
         * parser/SourceProvider.cpp: Added.
         (JSC):
         (JSC::SourceProvider::SourceProvider):
         (JSC::SourceProvider::~SourceProvider):
         * parser/SourceProvider.h:
         (JSC):
         (SourceProvider):
         * runtime/ArrayPrototype.cpp:
         * runtime/DatePrototype.cpp:
         * runtime/Executable.h:
         * runtime/JSGlobalObject.cpp:
         * runtime/JSGlobalObject.h:
         (JSC):
         * runtime/Operations.h:
         * runtime/Structure.cpp:
         (JSC::Structure::prototypeForLookup):
         (JSC):
         * runtime/Structure.h:
         (JSC):
         * runtime/StructureInlines.h: Added.
         (JSC):
         (JSC::Structure::create):
         (JSC::Structure::createStructure):
         (JSC::Structure::get):
         (JSC::Structure::masqueradesAsUndefined):
         (JSC::SlotVisitor::internalAppend):
         (JSC::Structure::transitivelyTransitionedFrom):
         (JSC::Structure::setEnumerationCache):
         (JSC::Structure::enumerationCache):
         (JSC::Structure::prototypeForLookup):
         (JSC::Structure::prototypeChain):
         (JSC::Structure::isValid):
         * runtime/StructureRareData.cpp:

 2013-02-17  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Windows build fix.

         * runtime/CodeCache.h:
         (CodeCacheMap):

 2013-02-16  Geoffrey Garen  <ggaren@apple.com>

         Code cache should be explicit about what it caches
         https://bugs.webkit.org/show_bug.cgi?id=110039

         Reviewed by Oliver Hunt.

         This patch makes the code cache more explicit in two ways:

         (1) The cache caches top-level scripts. Any sub-functions executed as a
         part of a script are cached with it and evicted with it.

         This simplifies things by eliminating out-of-band sub-function tracking,
         and fixes pathological cases where functions for live scripts would be
         evicted in favor of functions for dead scripts, and/or high probability
         functions executed early in script lifetime would be evicted in favor of
         low probability functions executed late in script lifetime, due to LRU.

         Statistical data from general browsing and PLT confirms that caching
         functions independently of scripts is not profitable.

         (2) The cache tracks script size, not script count.

         This reduces the worst-case cache size by a factor of infinity.

         Script size is a reasonable first-order estimate of in-memory footprint
         for a cached script because there are no syntactic constructs that have
         super-linear memory footprint.

         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::generateFunctionCodeBlock): Moved this function out of the cache
         because it does not consult the cache, and is not managed by it.

         (JSC::UnlinkedFunctionExecutable::visitChildren): Visit our code blocks
         because they are strong references now, rather than weak, a la (1).

         (JSC::UnlinkedFunctionExecutable::codeBlockFor): Updated for interface changes.

         * bytecode/UnlinkedCodeBlock.h:
         (UnlinkedFunctionExecutable):
         (UnlinkedFunctionCodeBlock): Strong now, not weak, a la (1).

         * runtime/CodeCache.cpp:
         (JSC::CodeCache::CodeCache):
         * runtime/CodeCache.h:
         (JSC::SourceCodeKey::length):
         (SourceCodeKey):
         (CodeCacheMap):
         (JSC::CodeCacheMap::CodeCacheMap):
         (JSC::CodeCacheMap::find):
         (JSC::CodeCacheMap::set):
         (JSC::CodeCacheMap::clear):
         (CodeCache):
         (JSC::CodeCache::clear): Removed individual function tracking, due to (1).
         Added explicit character counting, for (2).

         You might think 16000000 characters is a lot. It is. But this patch
         didn't establish that limit -- it just took the existing limit and
         made it more visible. I intend to reduce the size of the cache in a
         future patch.

 2013-02-16  Filip Pizlo  <fpizlo@apple.com>

         Remove support for bytecode comments, since it doesn't build, and hasn't been used in a while.
         https://bugs.webkit.org/show_bug.cgi?id=110035

         Rubber stamped by Andreas Kling.

         There are other ways of achieving the same effect, like adding print statements to the bytecode generator.
         The fact that this feature doesn't build and nobody noticed implies that it's probably not a popular
         feature. As well, the amount of wiring that was required for it was quite big considering its relatively
         modest utility.

         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * bytecode/CodeBlock.cpp:
         (JSC):
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::CodeBlock):
         * bytecode/CodeBlock.h:
         (CodeBlock):
         * bytecode/Comment.h: Removed.
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::BytecodeGenerator):
         (JSC::BytecodeGenerator::emitOpcode):
         (JSC):
         * bytecompiler/BytecodeGenerator.h:
         (BytecodeGenerator):
         (JSC::BytecodeGenerator::symbolTable):

 2013-02-16  Brent Fulgham  <bfulgham@webkit.org>

         [Windows] Unreviewed Visual Studio 2010 build fix after r143117

         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Reference new path to property sheets.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
         Build correction after new operator == added.

 2013-02-16  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation of Structure.h

         Rubber stamped by Mark Hahnenberg.

         * runtime/Structure.h:

 2013-02-16  Christophe Dumez  <ch.dumez@sisa.samsung.com>

         Unreviewed build fix.

         Export symbol for new CString operator== operator to fix Windows build.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-02-15  Filip Pizlo  <fpizlo@apple.com>

         Structure should be more methodical about the relationship between m_offset and m_propertyTable
         https://bugs.webkit.org/show_bug.cgi?id=109978

         Reviewed by Mark Hahnenberg.

         Allegedly, the previous relationship was that either m_propertyTable or m_offset
         would be set, and if m_propertyTable was not set you could rebuild it.  In reality,
         we would sometimes "reset" both: some transitions wouldn't set m_offset, and other
         transitions would clear the previous structure's m_propertyTable.  So, in a
         structure transition chain of A->B->C you could have:

         A transitions to B: B doesn't copy m_offset but does copy m_propertyTable, because
             that seemed like a good idea at the time (this was a common idiom in the code).
         B transitions to C: C steals B's m_propertyTable, leaving B with neither a
             m_propertyTable nor a m_offset.

         Then we would ask for the size of the property storage of B and get the answer
         "none".  That's not good.

         Now, there is a new relationship, which, hopefully, should fix things: m_offset is
         always set and always refers to the maximum offset ever used by the property table.
         From this, you can infer both the inline and out-of-line property size, and
         capacity.  This is accomplished by having PropertyTable::add() take a
         PropertyOffset reference, which must be Structure::m_offset.  It will update this
         offset.  As well, all transitions now copy m_offset.  And we frequently assert
         (using RELEASE_ASSERT) that the m_offset matches what m_propertyTable would tell
         you.  Hence if you ever modify the m_propertyTable, you'll also update the offset.
         If you ever copy the property table, you'll also copy the offset.  Life should be
         good, I think.

         * runtime/PropertyMapHashTable.h:
         (JSC::PropertyTable::add):
         * runtime/Structure.cpp:
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::removePropertyTransition):
         (JSC::Structure::changePrototypeTransition):
         (JSC::Structure::despecifyFunctionTransition):
         (JSC::Structure::attributeChangeTransition):
         (JSC::Structure::toDictionaryTransition):
         (JSC::Structure::sealTransition):
         (JSC::Structure::freezeTransition):
         (JSC::Structure::preventExtensionsTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::flattenDictionaryStructure):
         (JSC::Structure::checkConsistency):
         (JSC::Structure::putSpecificValue):
         (JSC::Structure::createPropertyMap):
         (JSC::PropertyTable::checkConsistency):
         * runtime/Structure.h:
         (JSC):
         (JSC::Structure::putWillGrowOutOfLineStorage):
         (JSC::Structure::outOfLineCapacity):
         (JSC::Structure::outOfLineSize):
         (JSC::Structure::isEmpty):
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
         (Structure):
         (JSC::Structure::checkOffsetConsistency):

 2013-02-15  Martin Robinson  <mrobinson@igalia.com>

         [GTK] Spread the gyp build files throughout the tree
         https://bugs.webkit.org/show_bug.cgi?id=109960

         Reviewed by Dirk Pranke.

         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Renamed from Source/WebKit/gtk/gyp/JavaScriptCore.gyp.
         * JavaScriptCore.gyp/generate-derived-sources.sh: Renamed from Source/WebKit/gtk/gyp/generate-derived-sources.sh.

 2013-02-15  Filip Pizlo  <fpizlo@apple.com>

         DFG SpeculativeJIT64 should be more precise about when it's dealing with a cell (even though it probably doesn't matter)
         https://bugs.webkit.org/show_bug.cgi?id=109625

         Reviewed by Mark Hahnenberg.

         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-15  Geoffrey Garen  <ggaren@apple.com>

         Merged the global function cache into the source code cache
         https://bugs.webkit.org/show_bug.cgi?id=108660

         Reviewed by Sam Weinig.

         Responding to review comments by Darin Adler.

         * runtime/CodeCache.h:
         (JSC::SourceCodeKey::SourceCodeKey): Don't initialize m_name and m_flags
         in the hash table deleted value because they're meaningless.

 2013-02-14  Filip Pizlo  <fpizlo@apple.com>

         DFG AbstractState should filter operands to NewArray more precisely
         https://bugs.webkit.org/show_bug.cgi?id=109900

         Reviewed by Mark Hahnenberg.

         NewArray for primitive indexing types speculates that the inputs are the appropriate
         primitives. Now, the CFA filters the abstract state accordingly, as well.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):

 2013-02-15  Andreas Kling  <akling@apple.com>

         Yarr: Use OwnPtr to make pattern/disjunction/character-class ownership clearer.
         <http://webkit.org/b/109218>

         Reviewed by Benjamin Poulain.

         - Let classes that manage lifetime of other objects hold on to them with OwnPtr instead of raw pointers.
         - Placed some strategic Vector::shrinkToFit(), ::reserveInitialCapacity() and ::swap().

         668 kB progression on Membuster3.

         * yarr/YarrInterpreter.cpp:
         (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
         (JSC::Yarr::ByteCompiler::emitDisjunction):
         (ByteCompiler):
         * yarr/YarrInterpreter.h:
         (JSC::Yarr::BytecodePattern::BytecodePattern):
         (BytecodePattern):
         * yarr/YarrJIT.cpp:
         (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
         (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
         (JSC::Yarr::YarrGenerator::opCompileBody):
         * yarr/YarrPattern.cpp:
         (JSC::Yarr::CharacterClassConstructor::charClass):
         (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
         (JSC::Yarr::YarrPatternConstructor::reset):
         (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
         (JSC::Yarr::YarrPatternConstructor::copyDisjunction):
         (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
         (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
         (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
         (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
         (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
         * yarr/YarrPattern.h:
         (JSC::Yarr::PatternDisjunction::addNewAlternative):
         (PatternDisjunction):
         (YarrPattern):
         (JSC::Yarr::YarrPattern::reset):
         (JSC::Yarr::YarrPattern::newlineCharacterClass):
         (JSC::Yarr::YarrPattern::digitsCharacterClass):
         (JSC::Yarr::YarrPattern::spacesCharacterClass):
         (JSC::Yarr::YarrPattern::wordcharCharacterClass):
         (JSC::Yarr::YarrPattern::nondigitsCharacterClass):
         (JSC::Yarr::YarrPattern::nonspacesCharacterClass):
         (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):

 2013-02-14  Geoffrey Garen  <ggaren@apple.com>

         Merged the global function cache into the source code cache
         https://bugs.webkit.org/show_bug.cgi?id=108660

         Reviewed by Sam Weinig.

         This has a few benefits:

             (*) Saves a few kB by removing a second cache data structure.

             (*) Reduces the worst case memory usage of the cache by 1.75X. (Heavy
             use of 'new Function' and other techniques could cause us to fill
             both root caches, and they didn't trade off against each other.)

             (*) Paves the way for future improvements based on a non-trivial
             cache key (for example, shrinkable pointer to the key string, and
             more precise cache size accounting).

         Also cleaned up the cache implementation and simplified it a bit.

         * heap/Handle.h:
         (HandleBase):
         * heap/Strong.h:
         (Strong): Build!

         * runtime/CodeCache.cpp:
         (JSC):
         (JSC::CodeCache::getCodeBlock):
         (JSC::CodeCache::generateFunctionCodeBlock):
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         (JSC::CodeCache::usedFunctionCode): Updated for three interface changes:

             (*) SourceCodeKey is a class, not a pair.

             (*) Table values are abstract pointers, since they can be executables
             or code blocks. (In a future patch, I'd like to change this so we
             always store only code blocks. But that's too much for one patch.)

             (*) The cache function is named "set" because it always overwrites
             unconditionally.

         * runtime/CodeCache.h:
         (CacheMap):
         (JSC::CacheMap::find):
         (JSC::CacheMap::set):
         (JSC::CacheMap::clear): Added support for specifying hash traits, so we
         can use a SourceCodeKey.

         Removed side table and random number generator to save space and reduce
         complexity. Hash tables are already random, so we don't need another source
         of randomness.

         (SourceCodeKey):
         (JSC::SourceCodeKey::SourceCodeKey):
         (JSC::SourceCodeKey::isHashTableDeletedValue):
         (JSC::SourceCodeKey::hash):
         (JSC::SourceCodeKey::isNull):
         (JSC::SourceCodeKey::operator==):
         (JSC::SourceCodeKeyHash::hash):
         (JSC::SourceCodeKeyHash::equal):
         (SourceCodeKeyHash):
         (SourceCodeKeyHashTraits):
         (JSC::SourceCodeKeyHashTraits::isEmptyValue): A SourceCodeKey is just a
         fancy triplet: source code string; function name (or null, for non-functions);
         and flags. Flags and function name distinguish between functions and programs
         with identical code, so they can live in the same cache.

         I chose to use the source code string as the primary hashing reference
         because it's likely to be unique. We can use profiling to choose another
         technique in future, if collisions between functions and programs prove
         to be hot. I suspect they won't.

         (JSC::CodeCache::clear):
         (CodeCache): Removed the second cache.

         * heap/Handle.h:
         (HandleBase):
         * heap/Strong.h:
         (Strong):
         * runtime/CodeCache.cpp:
         (JSC):
         (JSC::CodeCache::getCodeBlock):
         (JSC::CodeCache::generateFunctionCodeBlock):
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         (JSC::CodeCache::usedFunctionCode):
         * runtime/CodeCache.h:
         (JSC):
         (CacheMap):
         (JSC::CacheMap::find):
         (JSC::CacheMap::set):
         (JSC::CacheMap::clear):
         (SourceCodeKey):
         (JSC::SourceCodeKey::SourceCodeKey):
         (JSC::SourceCodeKey::isHashTableDeletedValue):
         (JSC::SourceCodeKey::hash):
         (JSC::SourceCodeKey::isNull):
         (JSC::SourceCodeKey::operator==):
         (JSC::SourceCodeKeyHash::hash):
         (JSC::SourceCodeKeyHash::equal):
         (SourceCodeKeyHash):
         (SourceCodeKeyHashTraits):
         (JSC::SourceCodeKeyHashTraits::isEmptyValue):
         (JSC::CodeCache::clear):
         (CodeCache):

 2013-02-14  Tony Chang  <tony@chromium.org>

         Unreviewed, set svn:eol-style native for .sln, .vcproj, and .vsprops files.
         https://bugs.webkit.org/show_bug.cgi?id=96934

         * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style.
         * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpDebug.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpDebugAll.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpDebugCairoCFLite.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpProduction.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpRelease.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpReleaseCairoCFLite.vsprops: Added property svn:eol-style.
         * JavaScriptCore.vcproj/testRegExp/testRegExpReleasePGO.vsprops: Added property svn:eol-style.

 2013-02-14  Tony Chang  <tony@chromium.org>

         Unreviewed, set svn:eol-style CRLF for .sln files.

         * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style.
         * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style.

 2013-02-14  David Kilzer  <ddkilzer@apple.com>

         [Mac] Clean up WARNING_CFLAGS
         <http://webkit.org/b/109747>
         <rdar://problem/13208373>

         Reviewed by Mark Rowe.

         * Configurations/Base.xcconfig: Use
         GCC_WARN_64_TO_32_BIT_CONVERSION to enable and disable
         -Wshorten-64-to-32 rather than WARNING_CFLAGS.

         * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style.
         * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style.

 2013-02-13  Anders Carlsson  <andersca@apple.com>

         Better build fix.

         * API/tests/testapi.c:
         (assertEqualsAsNumber):
         (main):

 2013-02-13  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Build fix.

         * API/tests/testapi.c:
         (assertEqualsAsNumber):
         (main):

 2013-02-13  Oliver Hunt  <oliver@apple.com>

         Yet another build fix

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):

 2013-02-13  Zan Dobersek  <zdobersek@igalia.com>

         The 'global isinf/isnan' compiler quirk required when using clang with libstdc++
         https://bugs.webkit.org/show_bug.cgi?id=109325

         Reviewed by Anders Carlsson.

         Prefix calls to the isinf and isnan methods with std::, declaring we want to use the
         two methods as they're provided by the C++ standard library being used.

         * API/JSValueRef.cpp:
         (JSValueMakeNumber):
         * JSCTypedArrayStubs.h:
         (JSC):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::emitLoad):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::constantNaN):
         * offlineasm/cloop.rb:
         * runtime/DateConstructor.cpp:
         (JSC::dateUTC): Also include an opportunistic style fix.
         * runtime/DateInstance.cpp:
         (JSC::DateInstance::calculateGregorianDateTime):
         (JSC::DateInstance::calculateGregorianDateTimeUTC):
         * runtime/DatePrototype.cpp:
         (JSC::dateProtoFuncGetMilliSeconds):
         (JSC::dateProtoFuncGetUTCMilliseconds):
         (JSC::setNewValueFromTimeArgs):
         (JSC::setNewValueFromDateArgs):
         (JSC::dateProtoFuncSetYear):
         * runtime/JSCJSValue.cpp:
         (JSC::JSValue::toInteger):
         * runtime/JSDateMath.cpp:
         (JSC::getUTCOffset):
         (JSC::parseDateFromNullTerminatedCharacters):
         (JSC::parseDate):
         * runtime/JSGlobalObjectFunctions.cpp:
         (JSC::globalFuncIsNaN):
         * runtime/MathObject.cpp:
         (JSC::mathProtoFuncMax):
         (JSC::mathProtoFuncMin):
         (JSC::mathProtoFuncPow):
         * runtime/PropertyDescriptor.cpp:
         (JSC::sameValue):

 2013-02-13  Filip Pizlo  <fpizlo@apple.com>

         Change another use of (SpecCell & ~SpecString) to SpecObject.

         Reviewed by Mark Hahnenberg.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):

 2013-02-13  Filip Pizlo  <fpizlo@apple.com>

         ForwardInt32ToDouble is not in DFG::MinifiedNode's list of relevant node types
         https://bugs.webkit.org/show_bug.cgi?id=109726

         Reviewed by Mark Hahnenberg.

         If you add it to the list of relevant node types, you also need to make sure
         it's listed as either hasChild or one of the other kinds. Otherwise you get
         an assertion. This is causing test failures in run-javascriptcore-tests.

         * dfg/DFGMinifiedNode.h:
         (JSC::DFG::MinifiedNode::hasChild):

 2013-02-13  Oliver Hunt  <oliver@apple.com>

         Build fix.

         Rearranged the code somewhat to reduce the number of
         DFG related ifdefs.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):

 2013-02-13  Filip Pizlo  <fpizlo@apple.com>

         ForwardInt32ToDouble is not in DFG::MinifiedNode's list of relevant node types
         https://bugs.webkit.org/show_bug.cgi?id=109726

         Reviewed by Gavin Barraclough.

         This is asymptomatic because ForwardInt32ToDouble is only used in SetLocals, in
         which case the value is already stored to the stack.  Still, we should fix this.

         * dfg/DFGMinifiedNode.h:
         (JSC::DFG::belongsInMinifiedGraph):

 2013-02-12  Filip Pizlo  <fpizlo@apple.com>

         DFG LogicalNot/Branch peephole removal and inversion ignores the possibility of things exiting
         https://bugs.webkit.org/show_bug.cgi?id=109489

         Reviewed by Mark Hahnenberg.

         If things can exit between the LogicalNot and the Branch then don't peephole.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):

 2013-02-13  Oliver Hunt  <oliver@apple.com>

         Remove unnecessary indirection to non-local variable access operations
         https://bugs.webkit.org/show_bug.cgi?id=109724

         Reviewed by Filip Pizlo.

         Linked bytecode now stores a direct pointer to the resolve operation
         vectors, so the interpreter no longer needs a bunch of indirection to
         to perform non-local lookup.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):
         * bytecode/CodeBlock.h:
         (CodeBlock):
         * bytecode/Instruction.h:
         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (InlineStackEntry):
         (JSC::DFG::ByteCodeParser::parseResolveOperations):
         (JSC::DFG::ByteCodeParser::parseBlock):
         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
         * dfg/DFGCapabilities.h:
         (JSC::DFG::canInlineOpcode):
         * dfg/DFGGraph.h:
         (ResolveGlobalData):
         (ResolveOperationData):
         (PutToBaseOperationData):
         * dfg/DFGSpeculativeJIT.h:
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * jit/JITOpcodes.cpp:
         (JSC::JIT::emit_op_put_to_base):
         (JSC::JIT::emit_op_resolve):
         (JSC::JIT::emitSlow_op_resolve):
         (JSC::JIT::emit_op_resolve_base):
         (JSC::JIT::emitSlow_op_resolve_base):
         (JSC::JIT::emit_op_resolve_with_base):
         (JSC::JIT::emitSlow_op_resolve_with_base):
         (JSC::JIT::emit_op_resolve_with_this):
         (JSC::JIT::emitSlow_op_resolve_with_this):
         (JSC::JIT::emitSlow_op_put_to_base):
         * jit/JITOpcodes32_64.cpp:
         (JSC::JIT::emit_op_put_to_base):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         * llint/LowLevelInterpreter.asm:

 2013-02-13  Zoltan Herczeg  <zherczeg@webkit.org>

         replaceWithJump should not decrease the offset by 1 on ARM traditional.
         https://bugs.webkit.org/show_bug.cgi?id=109689

         Reviewed by Oliver Hunt.

         * assembler/ARMAssembler.h:
         (JSC::ARMAssembler::replaceWithJump):

 2013-02-12  Joseph Pecoraro  <pecoraro@apple.com>

         [iOS] Enable PAGE_VISIBILITY_API
         https://bugs.webkit.org/show_bug.cgi?id=109399

         Reviewed by David Kilzer.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-12  Filip Pizlo  <fpizlo@apple.com>

         Renamed SpecObjectMask to SpecObject.

         Rubber stamped by Mark Hahnenberg.

         "SpecObjectMask" is a weird name considering that a bunch of the other speculated
         types are also masks, but don't have "Mask" in the name.

         * bytecode/SpeculatedType.h:
         (JSC):
         (JSC::isObjectSpeculation):
         (JSC::isObjectOrOtherSpeculation):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):

 2013-02-12  Filip Pizlo  <fpizlo@apple.com>

         DFG CFA doesn't filter precisely enough for CompareStrictEq
         https://bugs.webkit.org/show_bug.cgi?id=109618

         Reviewed by Mark Hahnenberg.

         The backend speculates object for this case, but the CFA was filtering on
         (SpecCell & ~SpecString) | SpecOther.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):

 2013-02-12  Martin Robinson  <mrobinson@igalia.com>

         Fix the gyp build of JavaScriptCore.

         * JavaScriptCore.gypi: Added some missing DFG files to the source list.

 2013-02-12  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r142387.
         http://trac.webkit.org/changeset/142387
         https://bugs.webkit.org/show_bug.cgi?id=109601

         caused all layout and jscore tests on windows to fail
         (Requested by kling on #webkit).

         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
         * bytecode/UnlinkedCodeBlock.h:
         (UnlinkedCodeBlock):

 2013-02-11  Filip Pizlo  <fpizlo@apple.com>

         DFG CompareEq optimization should be retuned
         https://bugs.webkit.org/show_bug.cgi?id=109545

         Reviewed by Mark Hahnenberg.

         - Made the object-to-object equality case work again by hoisting the if statement
           for it. Previously, object-to-object equality would be compiled as
           object-to-object-or-other.

         - Added AbstractState guards for most of the type checks that the object equality
           code uses.

         Looks like a hint of a speed-up on all of the things.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
         (JSC::DFG::SpeculativeJIT::compare):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):

 2013-02-12  Gabor Rapcsanyi  <rgabor@webkit.org>

         JSC asserting with long parameter list functions in debug mode on ARM traditional
         https://bugs.webkit.org/show_bug.cgi?id=109565

         Reviewed by Zoltan Herczeg.

         Increase the value of sequenceGetByIdSlowCaseInstructionSpace to 80.

         * jit/JIT.h:

 2013-02-11  Oliver Hunt  <oliver@apple.com>

         Make JSC API more NULL tolerant
         https://bugs.webkit.org/show_bug.cgi?id=109515

         Reviewed by Mark Hahnenberg.

         We do so much marshalling for the C API these days anyway that a single null
         check isn't a performance issue.  Yet the existing "null is unsafe" behaviour
         leads to crashes in embedding applications whenever there's an untested code
         path, so it seems having defined behaviour is superior.

         * API/APICast.h:
         (toJS):
         (toJSForGC):
         * API/JSObjectRef.cpp:
         (JSObjectIsFunction):
         (JSObjectCallAsFunction):
         (JSObjectIsConstructor):
         (JSObjectCallAsConstructor):
         * API/tests/testapi.c:
         (main):

 2013-02-11  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, adding a FIXME to remind ourselves of a bug.
         https://bugs.webkit.org/show_bug.cgi?id=109487

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):

 2013-02-11  Filip Pizlo  <fpizlo@apple.com>

         Strange bug in DFG OSR in JSC
         https://bugs.webkit.org/show_bug.cgi?id=109491

         Reviewed by Mark Hahnenberg.

         Int32ToDouble was being injected after a side-effecting operation and before a SetLocal. Anytime we
         inject something just before a SetLocal we should be aware that the previous operation may have been
         a side-effect associated with the current code origin. Hence, we should use a forward exit.
         Int32ToDouble does not do forward exits by default.

         This patch adds a forward-exiting form of Int32ToDouble, for use in SetLocal Int32ToDouble injections.
         Changed the CSE and other things to treat these nodes identically, but for the exit strategy to be
         distinct (Int32ToDouble -> backward, ForwardInt32ToDouble -> forward). The use of the NodeType for
         signaling exit direction is not "great" but it's what we use in other places already (like
         ForwardCheckStructure).

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::int32ToDoubleCSE):
         (CSEPhase):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGCommon.h:
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::fixDoubleEdge):
         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::willHaveCodeGenOrOSR):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
         * dfg/DFGSpeculativeJIT.h:
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGVariableEventStream.cpp:
         (JSC::DFG::VariableEventStream::reconstruct):

 2013-02-11  Filip Pizlo  <fpizlo@apple.com>

         NonStringCell and Object are practically the same thing for the purpose of speculation
         https://bugs.webkit.org/show_bug.cgi?id=109492

         Reviewed by Mark Hahnenberg.

         Removed isNonStringCellSpeculation, and made all callers use isObjectSpeculation.

         Changed isNonStringCellOrOtherSpeculation to be isObjectOrOtherSpeculation.

         I believe this is correct because even weird object types like JSNotAnObject end up
         being "objects" from the standpoint of our typesystem. Anyway, the assumption that
         "is cell but not a string" equates to "object" is an assumption that is already made
         in other places in the system so there's little value in being paranoid about it.

         * bytecode/SpeculatedType.h:
         (JSC::isObjectSpeculation):
         (JSC::isObjectOrOtherSpeculation):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGNode.h:
         (Node):
         (JSC::DFG::Node::shouldSpeculateObjectOrOther):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
         (JSC::DFG::SpeculativeJIT::compare):
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-10  Filip Pizlo  <fpizlo@apple.com>

         DFG CompareEq(a, null) and CompareStrictEq(a, const) are unsound with respect to constant folding
         https://bugs.webkit.org/show_bug.cgi?id=109387

         Reviewed by Oliver Hunt and Mark Hahnenberg.

         Lock in the decision to use a non-speculative constant comparison as early as possible
         and don't let the CFA change it by folding constants. This might be a performance
         penalty on some really weird code (FWIW, I haven't seen this on benchmarks), but on
         the other hand it completely side-steps the unsoundness that the bug speaks of.

         Rolling back in after adding 32-bit path.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::isConstantForCompareStrictEq):
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-10  Filip Pizlo  <fpizlo@apple.com>

         DFG TypeOf implementation should have its backend code aligned to what the CFA does
         https://bugs.webkit.org/show_bug.cgi?id=109385

         Reviewed by Sam Weinig.

         The problem was that if we ended up trying to constant fold, but didn't succeed
         because of prediction mismatches, then we would also fail to do filtration.

         Rearranged the control flow in the CFA to fix that.

         As far as I know, this is asymptomatic - it's sort of OK for the CFA to prove less
         things, which is what the bug was.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):

 2013-02-11  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r142491.
         http://trac.webkit.org/changeset/142491
         https://bugs.webkit.org/show_bug.cgi?id=109470

         broke the 32 bit build (Requested by jessieberlin on #webkit).

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-10  Filip Pizlo  <fpizlo@apple.com>

         DFG CompareEq(a, null) and CompareStrictEq(a, const) are unsound with respect to constant folding
         https://bugs.webkit.org/show_bug.cgi?id=109387

         Reviewed by Oliver Hunt.

         Lock in the decision to use a non-speculative constant comparison as early as possible
         and don't let the CFA change it by folding constants. This might be a performance
         penalty on some really weird code (FWIW, I haven't seen this on benchmarks), but on
         the other hand it completely side-steps the unsoundness that the bug speaks of.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::isConstantForCompareStrictEq):
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-11  Csaba Osztrogonác  <ossy@webkit.org>

         Unreviewed fix after r13954 for !ENABLE(JIT) builds.

         * llint/LowLevelInterpreter.cpp:

 2013-02-11  Gabor Rapcsanyi  <rgabor@webkit.org>

         JSC build failing with verbose debug mode
         https://bugs.webkit.org/show_bug.cgi?id=109441

         Reviewed by Darin Adler.

         Fixing some verbose messages which caused build errors.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::mergeToSuccessors):
         * dfg/DFGCFAPhase.cpp:
         (JSC::DFG::CFAPhase::performBlockCFA):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::setReplacement):
         (JSC::DFG::CSEPhase::eliminate):
         * dfg/DFGPredictionInjectionPhase.cpp:
         (JSC::DFG::PredictionInjectionPhase::run):

 2013-02-10  Martin Robinson  <mrobinson@igalia.com>

         Fix the GTK+ gyp build

         * JavaScriptCore.gypi: Update the source list to accurately
         reflect what's in the repository and remove the offsets extractor
         from the list of JavaScriptCore files. It's only used to build
         the extractor binary.

 2013-02-09  Andreas Kling  <akling@apple.com>

         Shrink-wrap UnlinkedCodeBlock members.
         <http://webkit.org/b/109368>

         Reviewed by Oliver Hunt.

         Rearrange the members of UnlinkedCodeBlock to avoid unnecessary padding on 64-bit.
         Knocks ~600 KB off of the Membuster3 peak.

         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
         * bytecode/UnlinkedCodeBlock.h:
         (UnlinkedCodeBlock):

 2013-02-08  Filip Pizlo  <fpizlo@apple.com>

         DFG should allow phases to break Phi's and then have one phase to rebuild them
         https://bugs.webkit.org/show_bug.cgi?id=108414

         Reviewed by Mark Hahnenberg.

         Introduces two new DFG forms: LoadStore and ThreadedCPS. These are described in
         detail in DFGCommon.h.

         Consequently, DFG phases no longer have to worry about preserving data flow
         links between basic blocks. It is generally always safe to request that the
         graph be dethreaded (Graph::dethread), which brings it into LoadStore form, where
         the data flow is implicit. In this form, only liveness-at-head needs to be
         preserved.

         All of the machinery for "threading" the graph to introduce data flow between
         blocks is now moved out of the bytecode parser and into the CPSRethreadingPhase.
         All phases that previously did this maintenance themselves now just rely on
         being able to dethread the graph. The one exception is the structure check
         hoising phase, which operates over a threaded graph and preserves it, for the
         sake of performance.

         Also moved two other things into their own phases: unification (previously found
         in the parser) and prediction injection (previously found in various places).

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/Operands.h:
         (Operands):
         (JSC::Operands::sizeFor):
         (JSC::Operands::atFor):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         (JSC::DFG::AbstractState::mergeStateAtTail):
         * dfg/DFGAllocator.h:
         (JSC::DFG::::allocateSlow):
         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         * dfg/DFGBasicBlockInlines.h:
         (DFG):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::getLocal):
         (JSC::DFG::ByteCodeParser::getArgument):
         (JSC::DFG::ByteCodeParser::flushDirect):
         (JSC::DFG::ByteCodeParser::parseBlock):
         (DFG):
         (JSC::DFG::ByteCodeParser::parse):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::run):
         (JSC::DFG::CFGSimplificationPhase::killUnreachable):
         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
         (CFGSimplificationPhase):
         (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors):
         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
         * dfg/DFGCPSRethreadingPhase.cpp: Added.
         (DFG):
         (CPSRethreadingPhase):
         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
         (JSC::DFG::CPSRethreadingPhase::run):
         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
         (JSC::DFG::CPSRethreadingPhase::clearVariablesAtHeadAndTail):
         (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
         (JSC::DFG::CPSRethreadingPhase::addPhi):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeSetLocal):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocal):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
         (JSC::DFG::CPSRethreadingPhase::PhiStackEntry::PhiStackEntry):
         (PhiStackEntry):
         (JSC::DFG::CPSRethreadingPhase::phiStackFor):
         (JSC::DFG::performCPSRethreading):
         * dfg/DFGCPSRethreadingPhase.h: Added.
         (DFG):
         * dfg/DFGCSEPhase.cpp:
         (CSEPhase):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGCommon.cpp:
         (WTF):
         (WTF::printInternal):
         * dfg/DFGCommon.h:
         (JSC::DFG::logCompilationChanges):
         (DFG):
         (WTF):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::Graph):
         (JSC::DFG::Graph::dump):
         (JSC::DFG::Graph::dethread):
         (JSC::DFG::Graph::collectGarbage):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::performSubstitution):
         (Graph):
         (JSC::DFG::Graph::performSubstitutionForEdge):
         (JSC::DFG::Graph::convertToConstant):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::convertToPhantomLocal):
         (Node):
         (JSC::DFG::Node::convertToGetLocal):
         (JSC::DFG::Node::hasVariableAccessData):
         * dfg/DFGNodeType.h:
         (DFG):
         * dfg/DFGPhase.cpp:
         (JSC::DFG::Phase::beginPhase):
         * dfg/DFGPhase.h:
         (JSC::DFG::runAndLog):
         * dfg/DFGPredictionInjectionPhase.cpp: Added.
         (DFG):
         (PredictionInjectionPhase):
         (JSC::DFG::PredictionInjectionPhase::PredictionInjectionPhase):
         (JSC::DFG::PredictionInjectionPhase::run):
         (JSC::DFG::performPredictionInjection):
         * dfg/DFGPredictionInjectionPhase.h: Added.
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::run):
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         * dfg/DFGUnificationPhase.cpp: Added.
         (DFG):
         (UnificationPhase):
         (JSC::DFG::UnificationPhase::UnificationPhase):
         (JSC::DFG::UnificationPhase::run):
         (JSC::DFG::performUnification):
         * dfg/DFGUnificationPhase.h: Added.
         (DFG):
         * dfg/DFGValidate.cpp:
         (JSC::DFG::Validate::validate):
         (JSC::DFG::Validate::dumpGraphIfAppropriate):
         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
         (JSC::DFG::VirtualRegisterAllocationPhase::run):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::setUpCall):
         * runtime/JSCJSValue.cpp:
         (JSC::JSValue::dump):
         * runtime/JSString.h:
         (JSString):
         * runtime/Options.h:
         (JSC):

 2013-02-08  Jer Noble  <jer.noble@apple.com>

         Bring WebKit up to speed with latest Encrypted Media spec.
         https://bugs.webkit.org/show_bug.cgi?id=97037

         Reviewed by Eric Carlson.

         Define the ENABLE_ENCRYPTED_MEDIA_V2 setting.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-08  Gavin Barraclough  <barraclough@apple.com>

         Objective-C API for JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=105889

         Reviewed by Joseph Pecoraro

         Following up on review comments, mostly typos.

         * API/JSBlockAdaptor.h:
         * API/JSBlockAdaptor.mm:
         (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
         * API/JSContext.h:
         * API/JSExport.h:
         * API/JSValue.h:
         * API/JSValue.mm:
         * API/JSWrapperMap.mm:
         (selectorToPropertyName):
         (-[JSWrapperMap classInfoForClass:]):
         (-[JSWrapperMap wrapperForObject:]):

 2013-02-08  Martin Robinson  <mrobinson@igalia.com>

         [GTK] Add an experimental gyp build
         https://bugs.webkit.org/show_bug.cgi?id=109003

         Reviewed by Gustavo Noronha Silva.

         * JavaScriptCore.gypi: Update the list of source files to include those
         necessary for the GTK+ build.

 2013-02-08  Andreas Kling  <akling@apple.com>

         JSC: Lower minimum PropertyTable size.
         <http://webkit.org/b/109247>

         Reviewed by Darin Adler.

         Lower the minimum table size for PropertyTable from 16 to 8.
         3.32 MB progression on Membuster3 (a ~13% reduction in memory used by PropertyTables.)

         * runtime/PropertyMapHashTable.h:
         (PropertyTable):
         (JSC::PropertyTable::sizeForCapacity):

 2013-02-07  Roger Fong  <roger_fong@apple.com>

         Unreviewed. More VS2010 WebKit solution touchups.
         Make JavaScriptCoreExports.def.in be treated as a custom build file so that changes to it cause the exports to be rebuilt.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

 2013-02-07  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: testapi.mm should use ARC
         https://bugs.webkit.org/show_bug.cgi?id=107838

         Reviewed by Mark Rowe.

         Removing the changes to the Xcode project file and moving the equivalent flags into
         the ToolExecutable xcconfig file.

         * Configurations/ToolExecutable.xcconfig:
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-02-07  Brent Fulgham  <bfulgham@webkit.org>

         [Windows] Unreviewed Visual Studio 2010 build fixes after r142179.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Correct changed symbols
         * JavaScriptCore.vcxproj/JavaScriptCoreExports.def: Removed autogenerated file.

 2013-02-05  Filip Pizlo  <fpizlo@apple.com>

         DFG::ByteCodeParser should do surgical constant folding to reduce load on the optimization fixpoint
         https://bugs.webkit.org/show_bug.cgi?id=109000

         Reviewed by Oliver Hunt.

         Previously our source parser's ASTBuilder did some surgical constant folding, but it
         didn't cover some cases.  It was particularly incapable of doing constant folding for
         cases where we do some minimal loop peeling in the bytecode generator - since it
         didn't "see" those constants prior to the peeling.  Example:

         for (var i = 0; i < 4; ++i)
             things;

         This will get peeled just a bit by the bytecode generator, so that the "i < 4" is
         duplicated both at the top of the loop and the bottom.  This means that we have a
         constant comparison: "0 < 4", which the bytecode generator emits without any further
         thought.

         The DFG optimization fixpoint of course folds this and simplifies the CFG
         accordingly, but this incurs a compile-time cost.  The purpose of this change is to
         do some surgical constant folding in the DFG's bytecode parser, so that such
         constructs reduce load on the CFG simplifier and the optimization fixpoint.  The goal
         is not to cover all cases, since the DFG CFA and CFG simplifier have a powerful
         sparse conditional constant propagation that we can always fall back on. Instead the
         goal is to cover enough cases that for common small functions we don't have to
         perform such transformations, thereby reducing compile times.

         This also refactors m_inlineStackEntry->m_inlineCallFrame to be a handy method call
         and also adds the notion of a TriState-based JSValue::pureToBoolean(). Both of these
         things are used by the folder.

         As well, care has been taken to make sure that the bytecode parser only does folding
         that is statically provable, and that doesn't arise out of speculation. This means
         we cannot fold on data flow that crosses inlining boundaries. On the other hand, the
         folding that the bytecode parser uses doesn't require phantoming anything. Such is
         the trade-off: for anything that we do need phantoming, we defer it to the
         optimization fixpoint.

         Slight SunSpider speed-up.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::get):
         (JSC::DFG::ByteCodeParser::getLocal):
         (JSC::DFG::ByteCodeParser::setLocal):
         (JSC::DFG::ByteCodeParser::flushDirect):
         (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables):
         (JSC::DFG::ByteCodeParser::toInt32):
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::inlineCallFrame):
         (JSC::DFG::ByteCodeParser::currentCodeOrigin):
         (JSC::DFG::ByteCodeParser::canFold):
         (JSC::DFG::ByteCodeParser::handleInlining):
         (JSC::DFG::ByteCodeParser::getScope):
         (JSC::DFG::ByteCodeParser::parseResolveOperations):
         (JSC::DFG::ByteCodeParser::parseBlock):
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::isStronglyProvedConstantIn):
         (Node):
         * runtime/JSCJSValue.h:
         * runtime/JSCJSValueInlines.h:
         (JSC::JSValue::pureToBoolean):
         (JSC):

 2013-02-07  Zoltan Herczeg  <zherczeg@webkit.org>

         Invalid code is generated for storing constants with baseindex addressing modes on ARM traditional.
         https://bugs.webkit.org/show_bug.cgi?id=109050

         Reviewed by Oliver Hunt.

         The S! scratch register is reused, but it should contain the constant value.

         * assembler/ARMAssembler.cpp:
         (JSC::ARMAssembler::baseIndexTransfer32):
         (JSC::ARMAssembler::baseIndexTransfer16):

 2013-02-07  Andras Becsi  <andras.becsi@digia.com>

         [Qt] Use GNU ar's thin archive format for intermediate static libs
         https://bugs.webkit.org/show_bug.cgi?id=109052

         Reviewed by Jocelyn Turcotte.

         Adjust project files that used activeBuildConfig()
         to use targetSubDir().

         * JavaScriptCore.pri:
         * LLIntOffsetsExtractor.pro:
         * Target.pri:

 2013-02-06  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Touchups to VS2010 WebKit solution.
         Fix an export generator script, modify some property sheets, add resouce file.

         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props:
         * JavaScriptCore.vcxproj/resource.h: Added.

 2013-02-06  Ilya Tikhonovsky  <loislo@chromium.org>

         Web Inspector: Native Memory Instrumentation: assign class name to the heap graph node automatically
         https://bugs.webkit.org/show_bug.cgi?id=107262

         Reviewed by Yury Semikhatsky.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-02-06  Mike West  <mkwst@chromium.org>

         Add an ENABLE_NOSNIFF feature flag.
         https://bugs.webkit.org/show_bug.cgi?id=109029

         Reviewed by Jochen Eisinger.

         This new flag will control the behavior of 'X-Content-Type-Options: nosniff'
         when processing script and other resource types.

         * Configurations/FeatureDefines.xcconfig:

 2013-02-05  Mark Hahnenberg  <mhahnenberg@apple.com>

         put_to_base should emit a Phantom for "value" across the ForceOSRExit
         https://bugs.webkit.org/show_bug.cgi?id=108998

         Reviewed by Oliver Hunt.

         Otherwise, the OSR exit compiler could clobber it, which would lead to badness.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::tallyFrequentExitSites): Build fixes for when DFG debug logging is enabled.
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock): Added extra Phantoms for the "value" field where needed.
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compile): Ditto.

 2013-02-05  Michael Saboff  <msaboff@apple.com>

         Crash at JSC::call when loading www.gap.com with JSVALUE32_64 Enabled
         https://bugs.webkit.org/show_bug.cgi?id=108991

         Reviewed by Oliver Hunt.

         Changed the restoration from calleeGPR to nonArgGPR0 because the restoration of the return location
         may step on calleeGPR is it happen to be nonArgGPR2.

         * dfg/DFGRepatch.cpp:
         (JSC::DFG::dfgLinkClosureCall):

 2013-02-05  Roger Fong  <roger_fong@apple.com>

         Add a JavaScriptCore Export Generator project.
         https://bugs.webkit.org/show_bug.cgi?id=108971.

         Reviewed by Brent Fulgham.

         * JavaScriptCore.vcxproj/JavaScriptCore.sln:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Added.

 2013-02-04  Filip Pizlo  <fpizlo@apple.com>

         DFG should have a precise view of jump targets
         https://bugs.webkit.org/show_bug.cgi?id=108868

         Reviewed by Oliver Hunt.

         Previously, the DFG relied entirely on the CodeBlock's jump targets list for
         determining when to break basic blocks. This worked great, except sometimes it
         would be too conservative since the CodeBlock just says where the bytecode
         generator inserted labels.

         This change keeps the old jump target list in CodeBlock since it is still
         valuable to the baseline JIT, but switches the DFG to use its own jump target
         calculator. This ought to reduce pressure on the DFG simplifier, which would
         previously do a lot of work to try to merge redundantly created basic blocks.
         It appears to be a 1% progression on SunSpider.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/PreciseJumpTargets.cpp: Added.
         (JSC):
         (JSC::addSimpleSwitchTargets):
         (JSC::computePreciseJumpTargets):
         * bytecode/PreciseJumpTargets.h: Added.
         (JSC):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseCodeBlock):

 2013-02-01  Roger Fong  <roger_fong@apple.com>

         Make ConfigurationBuildDir include directories precede WebKitLibraries in JSC.
         https://bugs.webkit.org/show_bug.cgi?id=108693.

         Rubberstamped by Timothy Horton.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:

 2013-02-04  Mark Hahnenberg  <mhahnenberg@apple.com>

         Structure::m_outOfLineCapacity is unnecessary
         https://bugs.webkit.org/show_bug.cgi?id=108206

         Reviewed by Darin Adler.

         Simplifying the utility functions that we use since we don't need a
         bunch of fancy templates for this one specific call site.

         * runtime/Structure.h:
         (JSC::Structure::outOfLineCapacity):

 2013-02-05  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: testapi.mm should use ARC
         https://bugs.webkit.org/show_bug.cgi?id=107838

         Reviewed by Oliver Hunt.

         In ToT testapi.mm uses the Obj-C garbage collector, which hides a lot of our object lifetime bugs.
         We should enable ARC, since that is what most of our clients will be using. We use Xcode project
         settings to make sure we don't try to compile ARC on 32-bit.

         * API/tests/testapi.mm:
         (+[TestObject testObject]):
         (testObjectiveCAPI):
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-02-05  Brent Fulgham  <bfulgham@webkit.org>

         [Windows] Unreviewed VS2010 Build Correction after r141651

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing
         StructureRareData.h and StructureRareData.cpp files.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.

 2013-02-05  Michael Saboff  <msaboff@apple.com>

         r141788 won't build due to not having all changes needed by Node* change
         https://bugs.webkit.org/show_bug.cgi?id=108944

         Reviewed by David Kilzer.

         Fixed three instances of integerResult(..., m_compileIndex) to be integerResult(..., node).

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileSoftModulo):
         (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s):

 2013-02-04  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r141809.
         http://trac.webkit.org/changeset/141809
         https://bugs.webkit.org/show_bug.cgi?id=108860

         ARC isn't supported on 32-bit. (Requested by mhahnenberg on
         #webkit).

         * API/tests/testapi.mm:
         (+[TestObject testObject]):
         (testObjectiveCAPI):
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-02-04  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: testapi.mm should use ARC
         https://bugs.webkit.org/show_bug.cgi?id=107838

         Reviewed by Oliver Hunt.

         In ToT testapi.mm uses the Obj-C garbage collector, which hides a lot of our object lifetime bugs.
         We should enable ARC, since that is what most of our clients will be using.

         * API/tests/testapi.mm:
         (-[TestObject init]):
         (-[TestObject dealloc]):
         (+[TestObject testObject]):
         (testObjectiveCAPI):
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-02-04  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: ObjCCallbackFunction should retain the target of its NSInvocation
         https://bugs.webkit.org/show_bug.cgi?id=108843

         Reviewed by Darin Adler.

         Currently, ObjCCallbackFunction doesn't retain the target of its NSInvocation. It needs to do
         this to prevent crashes when trying to invoke a callback later on.

         * API/ObjCCallbackFunction.mm:
         (ObjCCallbackFunction::ObjCCallbackFunction):
         (ObjCCallbackFunction::~ObjCCallbackFunction):

 2013-02-04  Martin Robinson  <mrobinson@igalia.com>

         Fix GTK+ 'make dist' in preparation for the 1.11.5 release.

         * GNUmakefile.list.am: Update the source lists.

 2013-02-04  Michael Saboff  <msaboff@apple.com>

         For ARMv7s use integer divide instruction for divide and modulo when possible
         https://bugs.webkit.org/show_bug.cgi?id=108840

         Reviewed in person by Filip Pizlo.

         Added ARMv7s integer divide path for ArithDiv and ArithMod where operands and results are integer.
         This is patterned after the similar code for X86.  Also added modulo power of 2 optimization
         that uses logical and.  Added sdiv and udiv to the ARMv7 disassembler.  Put all the changes
         behind #if CPU(APPLE_ARMV7S).

         * assembler/ARMv7Assembler.h:
         (ARMv7Assembler):
         (JSC::ARMv7Assembler::sdiv):
         (JSC::ARMv7Assembler::udiv):
         * dfg/DFGCommon.h:
         (JSC::DFG::isARMv7s):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileSoftModulo):
         (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-02-04  David Kilzer  <ddkilzer@apple.com>

         Check PrivateHeaders/JSBasePrivate.h for inappropriate macros
         <http://webkit.org/b/108749>

         Reviewed by Joseph Pecoraro.

         * JavaScriptCore.xcodeproj/project.pbxproj: Add
         PrivateHeaders/JSBasePrivate.h to list of headers to check in
         "Check for Inappropriate Macros in External Headers" build phase
         script.

 2013-02-04  David Kilzer  <ddkilzer@apple.com>

         Remove duplicate entries from JavaScriptCore Xcode project

             $ uniq Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj | diff -u - Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj | patch -p0 -R
             patching file Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj

         * JavaScriptCore.xcodeproj/project.pbxproj: Remove duplicates.

 2013-02-04  David Kilzer  <ddkilzer@apple.com>

         Sort JavaScriptCore Xcode project file

         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-02-03  David Kilzer  <ddkilzer@apple.com>

         Upstream ENABLE_PDFKIT_PLUGIN settting
         <http://webkit.org/b/108792>

         Reviewed by Tim Horton.

         * Configurations/FeatureDefines.xcconfig: Disable PDFKIT_PLUGIN
         on iOS since PDFKit is a Mac-only framework.

 2013-02-02  Andreas Kling  <akling@apple.com>

         Vector should consult allocator about ideal size when choosing capacity.
         <http://webkit.org/b/108410>
         <rdar://problem/13124002>

         Reviewed by Benjamin Poulain.

         Remove assertion about Vector capacity that won't hold anymore since capacity()
         may not be what you passed to reserveCapacity().
         Also export WTF::fastMallocGoodSize() for Windows builds.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):

 2013-02-02  Patrick Gansterer  <paroga@webkit.org>

         [CMake] Adopt the WinCE port to new CMake
         https://bugs.webkit.org/show_bug.cgi?id=108754

         Reviewed by Laszlo Gombos.

         * os-win32/WinMain.cpp: Removed.
         * shell/PlatformWinCE.cmake: Removed.

 2013-02-02  Mark Rowe  <mrowe@apple.com>

         <http://webkit.org/b/108745> WTF shouldn't use a script build phase to detect the presence of headers when the compiler can do it for us

         Reviewed by Sam Weinig.

         * DerivedSources.make: Remove an obsolete Makefile rule. This should have been removed when the use
         of the generated file moved to WTF.

 2013-02-02  David Kilzer  <ddkilzer@apple.com>

         Upstream iOS FeatureDefines
         <http://webkit.org/b/108753>

         Reviewed by Anders Carlsson.

         * Configurations/FeatureDefines.xcconfig:
         - ENABLE_DEVICE_ORIENTATION: Add iOS configurations.
         - ENABLE_PLUGIN_PROXY_FOR_VIDEO: Ditto.
         - FEATURE_DEFINES: Add ENABLE_PLUGIN_PROXY_FOR_VIDEO.  Add
           PLATFORM_NAME variant to reduce future merge conflicts.

 2013-02-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         Structure::m_enumerationCache should be moved to StructureRareData
         https://bugs.webkit.org/show_bug.cgi?id=108723

         Reviewed by Oliver Hunt.

         m_enumerationCache is only used by objects whose properties are iterated over, so not every Structure needs this
         field and it can therefore be moved safely to StructureRareData to help with memory savings.

         * runtime/JSPropertyNameIterator.h:
         (JSPropertyNameIterator):
         (JSC::Register::propertyNameIterator):
         (JSC::StructureRareData::enumerationCache): Add to JSPropertyNameIterator.h so that it can see the correct type.
         (JSC::StructureRareData::setEnumerationCache): Ditto.
         * runtime/Structure.cpp:
         (JSC::Structure::addPropertyWithoutTransition): Use the enumerationCache() getter rather than accessing the field.
         (JSC::Structure::removePropertyWithoutTransition): Ditto.
         (JSC::Structure::visitChildren): We no longer have to worry about marking the m_enumerationCache field.
         * runtime/Structure.h:
         (JSC::Structure::setEnumerationCache): Move the old accessors back since we don't have to have any knowledge of
         the JSPropertyNameIterator type.
         (JSC::Structure::enumerationCache): Ditto.
         * runtime/StructureRareData.cpp:
         (JSC::StructureRareData::visitChildren): Mark the new m_enumerationCache field.
         * runtime/StructureRareData.h: Add new functions/fields.
         (StructureRareData):

 2013-02-01  Roger Fong  <roger_fong@apple.com>

         Unreviewed. JavaScriptCore VS2010 project cleanup.

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:

 2013-02-01  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r141662.
         http://trac.webkit.org/changeset/141662
         https://bugs.webkit.org/show_bug.cgi?id=108738

         it's an incorrect change since processPhiStack will
         dereference dangling BasicBlock pointers (Requested by pizlo
         on #webkit).

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parse):

 2013-02-01  Filip Pizlo  <fpizlo@apple.com>

         Eliminate dead blocks sooner in the DFG::ByteCodeParser to make clear that you don't need to hold onto them during Phi construction
         https://bugs.webkit.org/show_bug.cgi?id=108717

         Reviewed by Mark Hahnenberg.

         I think this makes the code clearer. It doesn't change behavior.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parse):

 2013-02-01  Mark Hahnenberg  <mhahnenberg@apple.com>

         Structure should have a StructureRareData field to save space
         https://bugs.webkit.org/show_bug.cgi?id=108659

         Reviewed by Oliver Hunt.

         Many of the fields in Structure are used in a subset of all total Structures; however, all Structures must
         pay the memory cost of those fields, regardless of whether they use them or not. Since we can have potentially
         many Structures on a single page (e.g. bing.com creates ~1500 Structures), it would be profitable to
         refactor Structure so that not every Structure has to pay the memory costs for these infrequently used fields.

         To accomplish this, we can create a new StructureRareData class to house these seldom used fields which we
         can allocate on demand whenever a Structure requires it. This StructureRareData can itself be a JSCell, and
         can do all the marking of the fields for the Structure. The StructureRareData field will be part of a union
         with m_previous to minimize overhead. We'll add a new field to JSTypeInfo to indicate that the Structure has
         a StructureRareData field. During transitions, a Structure will clone its previous Structure's StructureRareData
         if it has one. There could be some potential for optimizing this process, but the initial implementation will
         be dumb since we'd be paying these overhead costs for each Structure anyways.

         Initially we'll only put two fields in the StructureRareData to avoid a memory regression. Over time we'll
         continue to move fields from Structure to StructureRareData. Optimistically, this could potentially reduce our
         Structure memory footprint by up to around 75%. It could also clear the way for removing destructors from
         Structures (and into StructureRareData).

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGRepatch.cpp: Includes for linking purposes.
         * jit/JITStubs.cpp:
         * jsc.cpp:
         * llint/LLIntSlowPaths.cpp:
         * runtime/JSCellInlines.h: Added ifdef guards.
         * runtime/JSGlobalData.cpp: New Structure for StructureRareData class.
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSGlobalObject.h:
         * runtime/JSTypeInfo.h: New flag to indicate whether or not a Structure has a StructureRareData field.
         (JSC::TypeInfo::flags):
         (JSC::TypeInfo::structureHasRareData):
         * runtime/ObjectPrototype.cpp:
         * runtime/Structure.cpp: We use a combined WriteBarrier<JSCell> field m_previousOrRareData to avoid compiler issues.
         (JSC::Structure::dumpStatistics):
         (JSC::Structure::Structure):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::pin):
         (JSC::Structure::allocateRareData): Handles allocating a brand new StructureRareData field.
         (JSC::Structure::cloneRareDataFrom): Handles cloning a StructureRareData field from another. Used during Structure
         transitions.
         (JSC::Structure::visitChildren): We no longer have to worry about marking m_objectToStringValue.
         * runtime/Structure.h:
         (JSC::Structure::previousID): Checks the structureHasRareData flag to see where it should get the previous Structure.
         (JSC::Structure::objectToStringValue): Reads the value from the StructureRareData. If it doesn't exist, returns 0.
         (JSC::Structure::setObjectToStringValue): Ensures that we have a StructureRareData field, then forwards the function
         call to it.
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::setPreviousID): Checks for StructureRareData and forwards if necessary.
         (Structure):
         (JSC::Structure::clearPreviousID): Ditto.
         (JSC::Structure::create):
         * runtime/StructureRareData.cpp: Added. All of the basic functionality of a JSCell with the fields that we've moved
         from Structure and the functions required to access/modify those fields as Structure would have done.
         (JSC):
         (JSC::StructureRareData::createStructure):
         (JSC::StructureRareData::create):
         (JSC::StructureRareData::clone):
         (JSC::StructureRareData::StructureRareData):
         (JSC::StructureRareData::visitChildren):
         * runtime/StructureRareData.h: Added.
         (JSC):
         (StructureRareData):
         * runtime/StructureRareDataInlines.h: Added.
         (JSC):
         (JSC::StructureRareData::previousID):
         (JSC::StructureRareData::setPreviousID):
         (JSC::StructureRareData::clearPreviousID):
         (JSC::Structure::previous): Handles the ugly casting to get the value of the right type of m_previousOrRareData.
         (JSC::Structure::rareData): Ditto.
         (JSC::StructureRareData::objectToStringValue):
         (JSC::StructureRareData::setObjectToStringValue):

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGRepatch.cpp:
         * jit/JITStubs.cpp:
         * jsc.cpp:
         * llint/LLIntSlowPaths.cpp:
         * runtime/JSCellInlines.h:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/JSGlobalObject.h:
         * runtime/JSTypeInfo.h:
         (JSC):
         (JSC::TypeInfo::flags):
         (JSC::TypeInfo::structureHasRareData):
         * runtime/ObjectPrototype.cpp:
         * runtime/Structure.cpp:
         (JSC::Structure::dumpStatistics):
         (JSC::Structure::Structure):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::pin):
         (JSC::Structure::allocateRareData):
         (JSC):
         (JSC::Structure::cloneRareDataFrom):
         (JSC::Structure::visitChildren):
         * runtime/Structure.h:
         (JSC::Structure::previousID):
         (JSC::Structure::objectToStringValue):
         (JSC::Structure::setObjectToStringValue):
         (JSC::Structure::materializePropertyMapIfNecessary):
         (JSC::Structure::setPreviousID):
         (Structure):
         (JSC::Structure::clearPreviousID):
         (JSC::Structure::previous):
         (JSC::Structure::rareData):
         (JSC::Structure::create):
         * runtime/StructureRareData.cpp: Added.
         (JSC):
         (JSC::StructureRareData::createStructure):
         (JSC::StructureRareData::create):
         (JSC::StructureRareData::clone):
         (JSC::StructureRareData::StructureRareData):
         (JSC::StructureRareData::visitChildren):
         * runtime/StructureRareData.h: Added.
         (JSC):
         (StructureRareData):
         * runtime/StructureRareDataInlines.h: Added.
         (JSC):
         (JSC::StructureRareData::previousID):
         (JSC::StructureRareData::setPreviousID):
         (JSC::StructureRareData::clearPreviousID):
         (JSC::StructureRareData::objectToStringValue):
         (JSC::StructureRareData::setObjectToStringValue):

 2013-02-01  Balazs Kilvady  <kilvadyb@homejinni.com>

         offlineasm BaseIndex handling is broken on ARM due to MIPS changes
         https://bugs.webkit.org/show_bug.cgi?id=108261

         Reviewed by Filip Pizlo.

         offlineasm BaseIndex handling fix on MIPS.

         * offlineasm/mips.rb:
         * offlineasm/risc.rb:

 2013-02-01  Geoffrey Garen  <ggaren@apple.com>

         Removed an unused function: JSGlobalObject::createFunctionExecutableFromGlobalCode
         https://bugs.webkit.org/show_bug.cgi?id=108657

         Reviewed by Anders Carlsson.

         * runtime/JSGlobalObject.cpp:
         (JSC):
         * runtime/JSGlobalObject.h:
         (JSGlobalObject):

 2013-02-01  Geoffrey Garen  <ggaren@apple.com>

         Added TriState to WTF and started using it in one place
         https://bugs.webkit.org/show_bug.cgi?id=108628

         Reviewed by Beth Dakin.

         * runtime/PrototypeMap.h:
         (JSC::PrototypeMap::isPrototype): Use TriState instead of boolean. In
         response to review feedback, this is an attempt to clarify that our
         'true' condition is actually just a 'maybe'.

         * runtime/PrototypeMap.h:
         (PrototypeMap):
         (JSC::PrototypeMap::isPrototype):

 2013-02-01  Alexis Menard  <alexis@webkit.org>

         Enable unprefixed CSS transitions by default.
         https://bugs.webkit.org/show_bug.cgi?id=108216

         Reviewed by Dean Jackson.

         Rename the flag CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED
         to CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED which will be used later to
         guard the unprefixing work for CSS Transforms and animations.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-31  Filip Pizlo  <fpizlo@apple.com>

         DFG::CFGSimplificationPhase::keepOperandAlive() conflates liveness and availability
         https://bugs.webkit.org/show_bug.cgi?id=108580

         Reviewed by Oliver Hunt.

         This is a harmless bug in that it only results in us keeping a bit too many things
         for OSR.  But it's worth fixing so that the code is consistent.

         keepOperandAlive() is called when block A has a branch to blocks B and C, but the
         A->B edge is proven to never be taken and we want to optimize the code to have A
         unconditionally jump to C.  In that case, for the purposes of OSR, we need to
         preserve the knowledge that the state that B expected to be live incoming from A
         ought still to be live up to the point of where the A->B,C branch used to be.  The
         way we keep things alive is by using the variablesAtTail of A (i.e., we use the
         knowledge of in what manner A made state available to B and C).  The way we choose
         which state should be kept alive ought to be chosen by the variablesAtHead of B
         (i.e. the things B says it needs from its predecessors, including A), except that
         keepOperandAlive() was previously just using variablesAtTail of A for this
         purpose.

         The fix is to have keepOperandAlive() use both liveness and availability in its
         logic. It should use liveness (i.e. B->variablesAtHead) to decide what to keep
         alive, and it should use availability (i.e. A->variablesAtTail) to decide how to
         keep it alive.

         This might be a microscopic win on some programs, but it's mainly intended to be
         a code clean-up so that I don't end up scratching my head in confusion the next
         time I look at this code.

         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
         (JSC::DFG::CFGSimplificationPhase::jettisonBlock):
         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):

 2013-01-31  Geoffrey Garen  <ggaren@apple.com>

         REGRESSION (r141192): Crash beneath cti_op_get_by_id_generic @ discussions.apple.com
         https://bugs.webkit.org/show_bug.cgi?id=108576

         Reviewed by Filip Pizlo.

         This was a long-standing bug. The DFG would destructively reuse a register
         in op_convert_this, but:

             * The bug only presented during speculation failure for type Other

             * The bug presented by removing the low bits of a pointer, which
             used to be harmless, since all objects were so aligned anyway.

         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile): Don't reuse our this register as
         our scratch register. The whole point of our scratch register is to
         avoid destructively modifying our this register. I'm pretty sure this
         was a copy-paste error.

 2013-01-31  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Windows build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-01-31  Jessie Berlin  <jberlin@apple.com>

         Rolling out r141407 because it is causing crashes under
         WTF::TCMalloc_Central_FreeList::FetchFromSpans() in Release builds.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):

 2013-01-31  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: JSContext exception property causes reference cycle
         https://bugs.webkit.org/show_bug.cgi?id=107778

         Reviewed by Darin Adler.

         JSContext has a (retain) JSValue * exception property which, when non-null, creates a
         reference cycle (since the JSValue * holds a strong reference back to the JSContext *).

         * API/JSContext.mm: Instead of JSValue *, we now use a plain JSValueRef, which eliminates the reference cycle.
         (-[JSContext initWithVirtualMachine:]):
         (-[JSContext setException:]):
         (-[JSContext exception]):

 2013-01-31  Roger Fong  <roger_fong@apple.com>

         Unreviewed build fix. Win7 port.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-01-31  Joseph Pecoraro  <pecoraro@apple.com>

         Disable ENABLE_FULLSCREEN_API on iOS
         https://bugs.webkit.org/show_bug.cgi?id=108250

         Reviewed by Benjamin Poulain.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-31  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Fix insertion of values greater than the max index allowed by the spec
         https://bugs.webkit.org/show_bug.cgi?id=108264

         Reviewed by Oliver Hunt.

         Fixed a bug, added a test to the API tests, cleaned up some code.

         * API/JSValue.h: Changed some of the documentation on setValue:atIndex: to indicate that
         setting values at indices greater than UINT_MAX - 1 wont' affect the length of JS arrays.
         * API/JSValue.mm:
         (-[JSValue valueAtIndex:]): We weren't returning when we should have been.
         (-[JSValue setValue:atIndex:]): Added a comment about why we do the early check for being larger than UINT_MAX.
         (objectToValueWithoutCopy): Removed two redundant cases that were already checked previously.
         * API/tests/testapi.mm:

 2013-01-30  Andreas Kling  <akling@apple.com>

         Vector should consult allocator about ideal size when choosing capacity.
         <http://webkit.org/b/108410>
         <rdar://problem/13124002>

         Reviewed by Benjamin Poulain.

         Remove assertion about Vector capacity that won't hold anymore since capacity()
         may not be what you passed to reserveCapacity().

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):

 2013-01-30  Filip Pizlo  <fpizlo@apple.com>

         DFG bytecode parser should have more assertions about the status of local accesses
         https://bugs.webkit.org/show_bug.cgi?id=108417

         Reviewed by Mark Hahnenberg.

         Assert some things that we already know to be true, just to reassure ourselves that they are true.
         This is meant as a prerequisite for https://bugs.webkit.org/show_bug.cgi?id=108414, which will
         make these rules even stricter.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::getLocal):
         (JSC::DFG::ByteCodeParser::getArgument):

 2013-01-30  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: JSContext's dealloc causes ASSERT due to ordering of releases
         https://bugs.webkit.org/show_bug.cgi?id=107978

         Reviewed by Filip Pizlo.

         We need to add the Identifier table save/restore in JSContextGroupRelease so that we
         have the correct table if we end up destroying the JSGlobalData/Heap.

         * API/JSContextRef.cpp:
         (JSContextGroupRelease):

 2013-01-30  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: exceptionHandler needs to be released in JSContext dealloc
         https://bugs.webkit.org/show_bug.cgi?id=108378

         Reviewed by Filip Pizlo.

         JSContext has a (copy) exceptionHandler property that it doesn't release in dealloc.
         That sounds like the potential for a leak. It should be released.

         * API/JSContext.mm:
         (-[JSContext dealloc]):

 2013-01-30  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION(140504): pure CSE no longer matches things, 10% regression on Kraken
         https://bugs.webkit.org/show_bug.cgi?id=108366

         Reviewed by Geoffrey Garen and Mark Hahnenberg.

         This was a longstanding bug that was revealed by http://trac.webkit.org/changeset/140504.
         Pure CSE requires that the Node::flags() that may affect the behavior of a node match,
         when comparing a possibly redundant node to its possible replacement. It was doing this
         by comparing Node::arithNodeFlags(), which as the name might appear to suggest, returns
         just those flag bits that correspond to actual node behavior and not auxiliary things.
         Unfortunately, Node::arithNodeFlags() wasn't actually masking off the irrelevant bits.
         This worked prior to r140504 because CSE itself didn't mutate the flags, so there was a
         very high probability that matching nodes would also have completely identical flag bits
         (even the ones that aren't relevant to arithmetic behavior, like NodeDoesNotExit). But
         r140504 moved one of CSE's side-tables (m_relevantToOSR) into a flag bit for quicker
         access. These bits would be mutated as the CSE ran over a basic block, in such a way that
         there was a very high probability that the possible replacement would already have the
         bit set, while the redundant node did not have the bit set. Since Node::arithNodeFlags()
         returned all of the bits, this would cause CSEPhase::pureCSE() to reject the match
         almost every time.

         The solution is to make Node::arithNodeFlags() do as its name suggests: only return those
         flags that are relevant to arithmetic behavior. This patch introduces a new mask that
         represents those bits, and includes NodeBehaviorMask and NodeBackPropMask, which are both
         used for queries on Node::arithNodeFlags(), and both affect arithmetic code gen. None of
         the other flags are relevant to Node::arithNodeFlags() since they either correspond to
         information already conveyed by the opcode (like NodeResultMask, NodeMustGenerate,
         NodeHasVarArgs, NodeClobbersWorld, NodeMightClobber) or information that doesn't affect
         the result that the node will produce or any of the queries performed on the result of
         Node::arithNodeFlags (NodeDoesNotExit and of course NodeRelevantToOSR).

         This is a 10% speed-up on Kraken, undoing the regression from r140504.

         * dfg/DFGNode.h:
         (JSC::DFG::Node::arithNodeFlags):
         * dfg/DFGNodeFlags.h:
         (DFG):

 2013-01-29  Mark Hahnenberg  <mhahnenberg@apple.com>

         Structure::m_outOfLineCapacity is unnecessary
         https://bugs.webkit.org/show_bug.cgi?id=108206

         Reviewed by Geoffrey Garen.

         We can calculate our out of line capacity by using the outOfLineSize and our knowledge about our resize policy.
         According to GDB, this knocks Structures down from 136 bytes to 128 bytes (I'm guessing the extra bytes are from
         better alignment of object fields), which puts Structures in a smaller size class. Woohoo! Looks neutral on our
         benchmarks.

         * runtime/Structure.cpp:
         (JSC::Structure::Structure):
         (JSC):
         (JSC::Structure::suggestedNewOutOfLineStorageCapacity):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::addPropertyWithoutTransition):
         * runtime/Structure.h:
         (Structure):
         (JSC::Structure::outOfLineCapacity):
         (JSC::Structure::totalStorageCapacity):

 2013-01-29  Geoffrey Garen  <ggaren@apple.com>

         Be a little more conservative about emitting table-based switches
         https://bugs.webkit.org/show_bug.cgi?id=108292

         Reviewed by Filip Pizlo.

         Profiling shows we're using op_switch in cases where it's a regression.

         * bytecompiler/NodesCodegen.cpp:
         (JSC):
         (JSC::length):
         (JSC::CaseBlockNode::tryTableSwitch):
         (JSC::CaseBlockNode::emitBytecodeForBlock):
         * parser/Nodes.h:
         (CaseBlockNode):

 2013-01-29  Sheriff Bot  <webkit.review.bot@gmail.com>

         Unreviewed, rolling out r140983.
         http://trac.webkit.org/changeset/140983
         https://bugs.webkit.org/show_bug.cgi?id=108277

         Unfortunately, this API has one last client (Requested by
         abarth on #webkit).

         * Configurations/FeatureDefines.xcconfig:

 2013-01-29  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: JSObjCClassInfo creates reference cycle with JSContext
         https://bugs.webkit.org/show_bug.cgi?id=107839

         Reviewed by Geoffrey Garen.

         Fixing several ASSERTs that were incorrect along with some of the reallocation of m_prototype and
         m_constructor that they were based on.

         * API/JSWrapperMap.mm:
         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We now only allocate those
         fields that are null (i.e. have been collected or have never been allocated to begin with).
         (-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Renamed to better indicate that we're
         reallocating one or both of the prototype/constructor combo.
         (-[JSObjCClassInfo wrapperForObject:]): Call new reallocate function.
         (-[JSObjCClassInfo constructor]): Ditto.

 2013-01-29  Geoffrey Garen  <ggaren@apple.com>

         Make precise size classes more precise
         https://bugs.webkit.org/show_bug.cgi?id=108270

         Reviewed by Mark Hahnenberg.

         Size inference makes this profitable.

         I chose 8 byte increments because JSString is 24 bytes. Otherwise, 16
         byte increments might be better.

         * heap/Heap.h:
         (Heap): Removed firstAllocatorWithoutDestructors because it's unused now.

         * heap/MarkedBlock.h:
         (MarkedBlock): Updated constants.

         * heap/MarkedSpace.h:
         (MarkedSpace):
         (JSC): Also reduced the maximum precise size class because my testing
         has shown that the smaller size classes are much more common. This
         offsets some of the size class explosion caused by reducing the precise
         increment.

         * llint/LLIntData.cpp:
         (JSC::LLInt::Data::performAssertions): No need for this ASSERT anymore
         because we don't rely on firstAllocatorWithoutDestructors anymore, since
         we pick size classes dynamically now.

 2013-01-29  Oliver Hunt  <oliver@apple.com>

         Add some hardening to methodTable()
         https://bugs.webkit.org/show_bug.cgi?id=108253

         Reviewed by Mark Hahnenberg.

         When accessing methodTable() we now always make sure that our
         structure _could_ be valid.  Added a separate method to get a
         classes methodTable during destruction as it's not possible to
         validate the structure at that point.  This separation might
         also make it possible to improve the performance of methodTable
         access more generally in future.

         * heap/MarkedBlock.cpp:
         (JSC::MarkedBlock::callDestructor):
         * runtime/JSCell.h:
         (JSCell):
         * runtime/JSCellInlines.h:
         (JSC::JSCell::methodTableForDestruction):
         (JSC):
         (JSC::JSCell::methodTable):

 2013-01-29  Filip Pizlo  <fpizlo@apple.com>

         offlineasm BaseIndex handling is broken on ARM due to MIPS changes
         https://bugs.webkit.org/show_bug.cgi?id=108261

         Reviewed by Oliver Hunt.

         Backends shouldn't override each other's methods. That's not cool.

         * offlineasm/mips.rb:

 2013-01-29  Filip Pizlo  <fpizlo@apple.com>

         cloop.rb shouldn't use a method called 'dump' for code generation
         https://bugs.webkit.org/show_bug.cgi?id=108251

         Reviewed by Mark Hahnenberg.

         Revert http://trac.webkit.org/changeset/141178 and rename 'dump' to 'clDump'.

         Also made trivial build fixes for !ENABLE(JIT).

         * offlineasm/cloop.rb:
         * runtime/Executable.h:
         (ExecutableBase):
         (JSC::ExecutableBase::intrinsicFor):
         * runtime/JSGlobalData.h:

 2013-01-29  Geoffrey Garen  <ggaren@apple.com>

         Removed GGC because it has been disabled for a long time
         https://bugs.webkit.org/show_bug.cgi?id=108245

         Reviewed by Filip Pizlo.

         * GNUmakefile.list.am:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * dfg/DFGRepatch.cpp:
         (JSC::DFG::emitPutReplaceStub):
         (JSC::DFG::emitPutTransitionStub):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::writeBarrier):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * heap/CardSet.h: Removed.
         * heap/Heap.cpp:
         (JSC::Heap::markRoots):
         (JSC::Heap::collect):
         * heap/Heap.h:
         (Heap):
         (JSC::Heap::shouldCollect):
         (JSC::Heap::isWriteBarrierEnabled):
         (JSC):
         (JSC::Heap::writeBarrier):
         * heap/MarkedBlock.h:
         (MarkedBlock):
         (JSC):
         * heap/MarkedSpace.cpp:
         (JSC):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::emitWriteBarrier):

 2013-01-29  Filip Pizlo  <fpizlo@apple.com>

         Remove redundant AST dump method from cloop.rb, since they are already defined in ast.rb
         https://bugs.webkit.org/show_bug.cgi?id=108247

         Reviewed by Oliver Hunt.

         Makes offlineasm dumping easier to read and less likely to cause assertion failures.
         Also fixes the strange situation where cloop.rb and ast.rb both defined dump methods,
         but cloop.rb was winning.

         * offlineasm/cloop.rb:

 2013-01-29  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: JSObjCClassInfo creates reference cycle with JSContext
         https://bugs.webkit.org/show_bug.cgi?id=107839

         Reviewed by Oliver Hunt.

         JSContext has a JSWrapperMap, which has an NSMutableDictionary m_classMap, which has values that
         are JSObjCClassInfo objects, which have strong references to two JSValue *'s, m_prototype and
         m_constructor, which in turn have strong references to the JSContext, creating a reference cycle.
         We should make m_prototype and m_constructor Weak<JSObject>. This gets rid of the strong reference
         to the JSContext and also prevents clients from accidentally creating reference cycles by assigning
         to the prototype of the constructor. If Weak<JSObject> fields are ever garbage collected, we will
         reallocate them.

         * API/JSContext.mm:
         (-[JSContext wrapperMap]):
         * API/JSContextInternal.h:
         * API/JSWrapperMap.mm:
         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
         (-[JSObjCClassInfo dealloc]):
         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]):
         (-[JSObjCClassInfo allocateConstructorAndPrototype]):
         (-[JSObjCClassInfo wrapperForObject:]):
         (-[JSObjCClassInfo constructor]):

 2013-01-29  Oliver Hunt  <oliver@apple.com>

         REGRESSION (r140594): RELEASE_ASSERT_NOT_REACHED in JSC::Interpreter::execute
         https://bugs.webkit.org/show_bug.cgi?id=108097

         Reviewed by Geoffrey Garen.

         LiteralParser was accepting a bogus 'var a.b = c' statement

         * runtime/LiteralParser.cpp:
         (JSC::::tryJSONPParse):

 2013-01-29  Oliver Hunt  <oliver@apple.com>

         Force debug builds to do bounds checks on contiguous property storage
         https://bugs.webkit.org/show_bug.cgi?id=108212

         Reviewed by Mark Hahnenberg.

         Add a ContiguousData type that we use to represent contiguous property
         storage.  In release builds it is simply a pointer to the correct type,
         but in debug builds it also carries the data length and performs bounds
         checks.  This means we don't have to add as many manual bounds assertions
         when performing operations over contiguous data.

         * dfg/DFGOperations.cpp:
         * runtime/ArrayStorage.h:
         (ArrayStorage):
         (JSC::ArrayStorage::vector):
         * runtime/Butterfly.h:
         (JSC::ContiguousData::ContiguousData):
         (ContiguousData):
         (JSC::ContiguousData::operator[]):
         (JSC::ContiguousData::data):
         (JSC::ContiguousData::length):
         (JSC):
         (JSC::Butterfly::contiguousInt32):
         (Butterfly):
         (JSC::Butterfly::contiguousDouble):
         (JSC::Butterfly::contiguous):
         * runtime/JSArray.cpp:
         (JSC::JSArray::sortNumericVector):
         (ContiguousTypeAccessor):
         (JSC::ContiguousTypeAccessor::getAsValue):
         (JSC::ContiguousTypeAccessor::setWithValue):
         (JSC::ContiguousTypeAccessor::replaceDataReference):
         (JSC):
         (JSC::JSArray::sortCompactedVector):
         (JSC::JSArray::sort):
         (JSC::JSArray::fillArgList):
         (JSC::JSArray::copyToArguments):
         * runtime/JSArray.h:
         (JSArray):
         * runtime/JSObject.cpp:
         (JSC::JSObject::copyButterfly):
         (JSC::JSObject::visitButterfly):
         (JSC::JSObject::createInitialInt32):
         (JSC::JSObject::createInitialDouble):
         (JSC::JSObject::createInitialContiguous):
         (JSC::JSObject::convertUndecidedToInt32):
         (JSC::JSObject::convertUndecidedToDouble):
         (JSC::JSObject::convertUndecidedToContiguous):
         (JSC::JSObject::convertInt32ToDouble):
         (JSC::JSObject::convertInt32ToContiguous):
         (JSC::JSObject::genericConvertDoubleToContiguous):
         (JSC::JSObject::convertDoubleToContiguous):
         (JSC::JSObject::rageConvertDoubleToContiguous):
         (JSC::JSObject::ensureInt32Slow):
         (JSC::JSObject::ensureDoubleSlow):
         (JSC::JSObject::ensureContiguousSlow):
         (JSC::JSObject::rageEnsureContiguousSlow):
         (JSC::JSObject::ensureLengthSlow):
         * runtime/JSObject.h:
         (JSC::JSObject::ensureInt32):
         (JSC::JSObject::ensureDouble):
         (JSC::JSObject::ensureContiguous):
         (JSC::JSObject::rageEnsureContiguous):
         (JSObject):
         (JSC::JSObject::indexingData):
         (JSC::JSObject::currentIndexingData):

 2013-01-29  Brent Fulgham  <bfulgham@webkit.org>

         [Windows, WinCairo] Unreviewed build fix after r141050

         * JavaScriptCore.vcxproj/JavaScriptCoreExports.def: Update symbols
         to match JavaScriptCore.vcproj version.

 2013-01-29  Allan Sandfeld Jensen  <allan.jensen@digia.com>

         [Qt] Implement GCActivityCallback
         https://bugs.webkit.org/show_bug.cgi?id=103998

         Reviewed by Simon Hausmann.

         Implements the activity triggered garbage collector.

         * runtime/GCActivityCallback.cpp:
         (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
         (JSC::DefaultGCActivityCallback::scheduleTimer):
         (JSC::DefaultGCActivityCallback::cancelTimer):
         * runtime/GCActivityCallback.h:
         (GCActivityCallback):
         (DefaultGCActivityCallback):

 2013-01-29  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>

         Compilation warning in JSC
         https://bugs.webkit.org/show_bug.cgi?id=108178

         Reviewed by Kentaro Hara.

         Fixed 'comparison between signed and unsigned integer' warning in JSC::Structure constructor.

         * runtime/Structure.cpp:
         (JSC::Structure::Structure):

 2013-01-29  Jocelyn Turcotte  <jocelyn.turcotte@digia.com>

         [Qt] Fix the JSC build on Mac

         Unreviewed, build fix.

         * heap/HeapTimer.h:
         Qt on Mac has USE(CF) true, and should use the CF HeapTimer in that case.

 2013-01-29  Allan Sandfeld Jensen  <allan.jensen@digia.com>

         [Qt] Implement IncrementalSweeper and HeapTimer
         https://bugs.webkit.org/show_bug.cgi?id=103996

         Reviewed by Simon Hausmann.

         Implements the incremental sweeping garbage collection for the Qt platform.

         * heap/HeapTimer.cpp:
         (JSC::HeapTimer::HeapTimer):
         (JSC::HeapTimer::~HeapTimer):
         (JSC::HeapTimer::timerEvent):
         (JSC::HeapTimer::synchronize):
         (JSC::HeapTimer::invalidate):
         (JSC::HeapTimer::didStartVMShutdown):
         * heap/HeapTimer.h:
         (HeapTimer):
         * heap/IncrementalSweeper.cpp:
         (JSC::IncrementalSweeper::IncrementalSweeper):
         (JSC::IncrementalSweeper::scheduleTimer):
         * heap/IncrementalSweeper.h:
         (IncrementalSweeper):

 2013-01-28  Filip Pizlo  <fpizlo@apple.com>

         DFG should not use a graph that is a vector, Nodes shouldn't move after allocation, and we should always refer to nodes by Node*
         https://bugs.webkit.org/show_bug.cgi?id=106868

         Reviewed by Oliver Hunt.

         This adds a pool allocator for Nodes, and uses that instead of a Vector. Changes all
         uses of Node& and NodeIndex to be simply Node*. Nodes no longer have an index except
         for debugging (Node::index(), which is not guaranteed to be O(1)).

         1% speed-up on SunSpider, presumably because this improves compile times.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/DataFormat.h:
         (JSC::dataFormatToString):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::initialize):
         (JSC::DFG::AbstractState::booleanResult):
         (JSC::DFG::AbstractState::execute):
         (JSC::DFG::AbstractState::mergeStateAtTail):
         (JSC::DFG::AbstractState::mergeToSuccessors):
         (JSC::DFG::AbstractState::mergeVariableBetweenBlocks):
         (JSC::DFG::AbstractState::dump):
         * dfg/DFGAbstractState.h:
         (DFG):
         (JSC::DFG::AbstractState::forNode):
         (AbstractState):
         (JSC::DFG::AbstractState::speculateInt32Unary):
         (JSC::DFG::AbstractState::speculateNumberUnary):
         (JSC::DFG::AbstractState::speculateBooleanUnary):
         (JSC::DFG::AbstractState::speculateInt32Binary):
         (JSC::DFG::AbstractState::speculateNumberBinary):
         (JSC::DFG::AbstractState::trySetConstant):
         * dfg/DFGAbstractValue.h:
         (AbstractValue):
         * dfg/DFGAdjacencyList.h:
         (JSC::DFG::AdjacencyList::AdjacencyList):
         (JSC::DFG::AdjacencyList::initialize):
         * dfg/DFGAllocator.h: Added.
         (DFG):
         (Allocator):
         (JSC::DFG::Allocator::Region::size):
         (JSC::DFG::Allocator::Region::headerSize):
         (JSC::DFG::Allocator::Region::numberOfThingsPerRegion):
         (JSC::DFG::Allocator::Region::data):
         (JSC::DFG::Allocator::Region::isInThisRegion):
         (JSC::DFG::Allocator::Region::regionFor):
         (Region):
         (JSC::DFG::::Allocator):
         (JSC::DFG::::~Allocator):
         (JSC::DFG::::allocate):
         (JSC::DFG::::free):
         (JSC::DFG::::freeAll):
         (JSC::DFG::::reset):
         (JSC::DFG::::indexOf):
         (JSC::DFG::::allocatorOf):
         (JSC::DFG::::bumpAllocate):
         (JSC::DFG::::freeListAllocate):
         (JSC::DFG::::allocateSlow):
         (JSC::DFG::::freeRegionsStartingAt):
         (JSC::DFG::::startBumpingIn):
         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
         (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses):
         (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
         (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
         (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::originalArrayStructure):
         (JSC::DFG::ArrayMode::alreadyChecked):
         * dfg/DFGArrayMode.h:
         (ArrayMode):
         * dfg/DFGArrayifySlowPathGenerator.h:
         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
         * dfg/DFGBasicBlock.h:
         (JSC::DFG::BasicBlock::node):
         (JSC::DFG::BasicBlock::isInPhis):
         (JSC::DFG::BasicBlock::isInBlock):
         (BasicBlock):
         * dfg/DFGBasicBlockInlines.h:
         (DFG):
         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::getDirect):
         (JSC::DFG::ByteCodeParser::get):
         (JSC::DFG::ByteCodeParser::setDirect):
         (JSC::DFG::ByteCodeParser::set):
         (JSC::DFG::ByteCodeParser::setPair):
         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
         (JSC::DFG::ByteCodeParser::getLocal):
         (JSC::DFG::ByteCodeParser::setLocal):
         (JSC::DFG::ByteCodeParser::getArgument):
         (JSC::DFG::ByteCodeParser::setArgument):
         (JSC::DFG::ByteCodeParser::flushDirect):
         (JSC::DFG::ByteCodeParser::getToInt32):
         (JSC::DFG::ByteCodeParser::toInt32):
         (JSC::DFG::ByteCodeParser::getJSConstantForValue):
         (JSC::DFG::ByteCodeParser::getJSConstant):
         (JSC::DFG::ByteCodeParser::getCallee):
         (JSC::DFG::ByteCodeParser::getThis):
         (JSC::DFG::ByteCodeParser::setThis):
         (JSC::DFG::ByteCodeParser::isJSConstant):
         (JSC::DFG::ByteCodeParser::isInt32Constant):
         (JSC::DFG::ByteCodeParser::valueOfJSConstant):
         (JSC::DFG::ByteCodeParser::valueOfInt32Constant):
         (JSC::DFG::ByteCodeParser::constantUndefined):
         (JSC::DFG::ByteCodeParser::constantNull):
         (JSC::DFG::ByteCodeParser::one):
         (JSC::DFG::ByteCodeParser::constantNaN):
         (JSC::DFG::ByteCodeParser::cellConstant):
         (JSC::DFG::ByteCodeParser::addToGraph):
         (JSC::DFG::ByteCodeParser::insertPhiNode):
         (JSC::DFG::ByteCodeParser::addVarArgChild):
         (JSC::DFG::ByteCodeParser::addCall):
         (JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
         (JSC::DFG::ByteCodeParser::getPrediction):
         (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
         (JSC::DFG::ByteCodeParser::makeSafe):
         (JSC::DFG::ByteCodeParser::makeDivSafe):
         (JSC::DFG::ByteCodeParser::ConstantRecord::ConstantRecord):
         (ConstantRecord):
         (JSC::DFG::ByteCodeParser::PhiStackEntry::PhiStackEntry):
         (PhiStackEntry):
         (JSC::DFG::ByteCodeParser::handleCall):
         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
         (JSC::DFG::ByteCodeParser::handleInlining):
         (JSC::DFG::ByteCodeParser::setIntrinsicResult):
         (JSC::DFG::ByteCodeParser::handleMinMax):
         (JSC::DFG::ByteCodeParser::handleIntrinsic):
         (JSC::DFG::ByteCodeParser::handleGetByOffset):
         (JSC::DFG::ByteCodeParser::handleGetById):
         (JSC::DFG::ByteCodeParser::getScope):
         (JSC::DFG::ByteCodeParser::parseResolveOperations):
         (JSC::DFG::ByteCodeParser::parseBlock):
         (JSC::DFG::ByteCodeParser::processPhiStack):
         (JSC::DFG::ByteCodeParser::linkBlock):
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         (JSC::DFG::ByteCodeParser::parse):
         * dfg/DFGCFAPhase.cpp:
         (JSC::DFG::CFAPhase::performBlockCFA):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::run):
         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
         (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
         (JSC::DFG::CFGSimplificationPhase::fixPhis):
         (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference):
         (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::OperandSubstitution):
         (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::dump):
         (OperandSubstitution):
         (JSC::DFG::CFGSimplificationPhase::skipGetLocal):
         (JSC::DFG::CFGSimplificationPhase::recordNewTarget):
         (JSC::DFG::CFGSimplificationPhase::fixTailOperand):
         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::canonicalize):
         (JSC::DFG::CSEPhase::endIndexForPureCSE):
         (JSC::DFG::CSEPhase::pureCSE):
         (JSC::DFG::CSEPhase::constantCSE):
         (JSC::DFG::CSEPhase::weakConstantCSE):
         (JSC::DFG::CSEPhase::getCalleeLoadElimination):
         (JSC::DFG::CSEPhase::getArrayLengthElimination):
         (JSC::DFG::CSEPhase::globalVarLoadElimination):
         (JSC::DFG::CSEPhase::scopedVarLoadElimination):
         (JSC::DFG::CSEPhase::globalVarWatchpointElimination):
         (JSC::DFG::CSEPhase::globalVarStoreElimination):
         (JSC::DFG::CSEPhase::scopedVarStoreElimination):
         (JSC::DFG::CSEPhase::getByValLoadElimination):
         (JSC::DFG::CSEPhase::checkFunctionElimination):
         (JSC::DFG::CSEPhase::checkExecutableElimination):
         (JSC::DFG::CSEPhase::checkStructureElimination):
         (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
         (JSC::DFG::CSEPhase::putStructureStoreElimination):
         (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
         (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
         (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
         (JSC::DFG::CSEPhase::checkArrayElimination):
         (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
         (JSC::DFG::CSEPhase::getLocalLoadElimination):
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         (JSC::DFG::CSEPhase::performSubstitution):
         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::CSEPhase::setReplacement):
         (JSC::DFG::CSEPhase::eliminate):
         (JSC::DFG::CSEPhase::performNodeCSE):
         (JSC::DFG::CSEPhase::performBlockCSE):
         (CSEPhase):
         * dfg/DFGCommon.cpp: Added.
         (DFG):
         (JSC::DFG::NodePointerTraits::dump):
         * dfg/DFGCommon.h:
         (DFG):
         (JSC::DFG::NodePointerTraits::defaultValue):
         (NodePointerTraits):
         (JSC::DFG::verboseCompilationEnabled):
         (JSC::DFG::shouldDumpGraphAtEachPhase):
         (JSC::DFG::validationEnabled):
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter):
         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
         (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::Disassembler):
         (JSC::DFG::Disassembler::createDumpList):
         (JSC::DFG::Disassembler::dumpDisassembly):
         * dfg/DFGDisassembler.h:
         (JSC::DFG::Disassembler::setForNode):
         (Disassembler):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGEdge.cpp: Added.
         (DFG):
         (JSC::DFG::Edge::dump):
         * dfg/DFGEdge.h:
         (JSC::DFG::Edge::Edge):
         (JSC::DFG::Edge::node):
         (JSC::DFG::Edge::operator*):
         (JSC::DFG::Edge::operator->):
         (Edge):
         (JSC::DFG::Edge::setNode):
         (JSC::DFG::Edge::useKind):
         (JSC::DFG::Edge::setUseKind):
         (JSC::DFG::Edge::isSet):
         (JSC::DFG::Edge::shift):
         (JSC::DFG::Edge::makeWord):
         (JSC::DFG::operator==):
         (JSC::DFG::operator!=):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupBlock):
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::checkArray):
         (JSC::DFG::FixupPhase::blessArrayOperation):
         (JSC::DFG::FixupPhase::fixIntEdge):
         (JSC::DFG::FixupPhase::fixDoubleEdge):
         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
         (FixupPhase):
         * dfg/DFGGenerationInfo.h:
         (JSC::DFG::GenerationInfo::GenerationInfo):
         (JSC::DFG::GenerationInfo::initConstant):
         (JSC::DFG::GenerationInfo::initInteger):
         (JSC::DFG::GenerationInfo::initJSValue):
         (JSC::DFG::GenerationInfo::initCell):
         (JSC::DFG::GenerationInfo::initBoolean):
         (JSC::DFG::GenerationInfo::initDouble):
         (JSC::DFG::GenerationInfo::initStorage):
         (GenerationInfo):
         (JSC::DFG::GenerationInfo::node):
         (JSC::DFG::GenerationInfo::noticeOSRBirth):
         (JSC::DFG::GenerationInfo::use):
         (JSC::DFG::GenerationInfo::appendFill):
         (JSC::DFG::GenerationInfo::appendSpill):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::Graph):
         (JSC::DFG::Graph::~Graph):
         (DFG):
         (JSC::DFG::Graph::dumpCodeOrigin):
         (JSC::DFG::Graph::amountOfNodeWhiteSpace):
         (JSC::DFG::Graph::printNodeWhiteSpace):
         (JSC::DFG::Graph::dump):
         (JSC::DFG::Graph::dumpBlockHeader):
         (JSC::DFG::Graph::refChildren):
         (JSC::DFG::Graph::derefChildren):
         (JSC::DFG::Graph::predictArgumentTypes):
         (JSC::DFG::Graph::collectGarbage):
         (JSC::DFG::Graph::determineReachability):
         (JSC::DFG::Graph::resetExitStates):
         * dfg/DFGGraph.h:
         (Graph):
         (JSC::DFG::Graph::ref):
         (JSC::DFG::Graph::deref):
         (JSC::DFG::Graph::changeChild):
         (JSC::DFG::Graph::compareAndSwap):
         (JSC::DFG::Graph::clearAndDerefChild):
         (JSC::DFG::Graph::clearAndDerefChild1):
         (JSC::DFG::Graph::clearAndDerefChild2):
         (JSC::DFG::Graph::clearAndDerefChild3):
         (JSC::DFG::Graph::convertToConstant):
         (JSC::DFG::Graph::getJSConstantSpeculation):
         (JSC::DFG::Graph::addSpeculationMode):
         (JSC::DFG::Graph::valueAddSpeculationMode):
         (JSC::DFG::Graph::arithAddSpeculationMode):
         (JSC::DFG::Graph::addShouldSpeculateInteger):
         (JSC::DFG::Graph::mulShouldSpeculateInteger):
         (JSC::DFG::Graph::negateShouldSpeculateInteger):
         (JSC::DFG::Graph::isConstant):
         (JSC::DFG::Graph::isJSConstant):
         (JSC::DFG::Graph::isInt32Constant):
         (JSC::DFG::Graph::isDoubleConstant):
         (JSC::DFG::Graph::isNumberConstant):
         (JSC::DFG::Graph::isBooleanConstant):
         (JSC::DFG::Graph::isCellConstant):
         (JSC::DFG::Graph::isFunctionConstant):
         (JSC::DFG::Graph::isInternalFunctionConstant):
         (JSC::DFG::Graph::valueOfJSConstant):
         (JSC::DFG::Graph::valueOfInt32Constant):
         (JSC::DFG::Graph::valueOfNumberConstant):
         (JSC::DFG::Graph::valueOfBooleanConstant):
         (JSC::DFG::Graph::valueOfFunctionConstant):
         (JSC::DFG::Graph::valueProfileFor):
         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
         (JSC::DFG::Graph::numSuccessors):
         (JSC::DFG::Graph::successor):
         (JSC::DFG::Graph::successorForCondition):
         (JSC::DFG::Graph::isPredictedNumerical):
         (JSC::DFG::Graph::byValIsPure):
         (JSC::DFG::Graph::clobbersWorld):
         (JSC::DFG::Graph::varArgNumChildren):
         (JSC::DFG::Graph::numChildren):
         (JSC::DFG::Graph::varArgChild):
         (JSC::DFG::Graph::child):
         (JSC::DFG::Graph::voteNode):
         (JSC::DFG::Graph::voteChildren):
         (JSC::DFG::Graph::substitute):
         (JSC::DFG::Graph::substituteGetLocal):
         (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
         (JSC::DFG::Graph::mulImmediateShouldSpeculateInteger):
         * dfg/DFGInsertionSet.h:
         (JSC::DFG::Insertion::Insertion):
         (JSC::DFG::Insertion::element):
         (Insertion):
         (JSC::DFG::InsertionSet::insert):
         (InsertionSet):
         * dfg/DFGJITCompiler.cpp:
         * dfg/DFGJITCompiler.h:
         (JSC::DFG::JITCompiler::setForNode):
         (JSC::DFG::JITCompiler::addressOfDoubleConstant):
         (JSC::DFG::JITCompiler::noticeOSREntry):
         * dfg/DFGLongLivedState.cpp: Added.
         (DFG):
         (JSC::DFG::LongLivedState::LongLivedState):
         (JSC::DFG::LongLivedState::~LongLivedState):
         (JSC::DFG::LongLivedState::shrinkToFit):
         * dfg/DFGLongLivedState.h: Added.
         (DFG):
         (LongLivedState):
         * dfg/DFGMinifiedID.h:
         (JSC::DFG::MinifiedID::MinifiedID):
         (JSC::DFG::MinifiedID::node):
         * dfg/DFGMinifiedNode.cpp:
         (JSC::DFG::MinifiedNode::fromNode):
         * dfg/DFGMinifiedNode.h:
         (MinifiedNode):
         * dfg/DFGNode.cpp: Added.
         (DFG):
         (JSC::DFG::Node::index):
         (WTF):
         (WTF::printInternal):
         * dfg/DFGNode.h:
         (DFG):
         (JSC::DFG::Node::Node):
         (Node):
         (JSC::DFG::Node::convertToGetByOffset):
         (JSC::DFG::Node::convertToPutByOffset):
         (JSC::DFG::Node::ref):
         (JSC::DFG::Node::shouldSpeculateInteger):
         (JSC::DFG::Node::shouldSpeculateIntegerForArithmetic):
         (JSC::DFG::Node::shouldSpeculateIntegerExpectingDefined):
         (JSC::DFG::Node::shouldSpeculateDoubleForArithmetic):
         (JSC::DFG::Node::shouldSpeculateNumber):
         (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined):
         (JSC::DFG::Node::shouldSpeculateFinalObject):
         (JSC::DFG::Node::shouldSpeculateArray):
         (JSC::DFG::Node::dumpChildren):
         (WTF):
         * dfg/DFGNodeAllocator.h: Added.
         (DFG):
         (operator new ):
         * dfg/DFGOSRExit.cpp:
         (JSC::DFG::OSRExit::OSRExit):
         * dfg/DFGOSRExit.h:
         (OSRExit):
         (SpeculationFailureDebugInfo):
         * dfg/DFGOSRExitCompiler.cpp:
         * dfg/DFGOSRExitCompiler32_64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOSRExitCompiler64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOperations.cpp:
         * dfg/DFGPhase.cpp:
         (DFG):
         (JSC::DFG::Phase::beginPhase):
         (JSC::DFG::Phase::endPhase):
         * dfg/DFGPhase.h:
         (Phase):
         (JSC::DFG::runAndLog):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::setPrediction):
         (JSC::DFG::PredictionPropagationPhase::mergePrediction):
         (JSC::DFG::PredictionPropagationPhase::isNotNegZero):
         (JSC::DFG::PredictionPropagationPhase::isNotZero):
         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant):
         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive):
         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo):
         (JSC::DFG::PredictionPropagationPhase::propagate):
         (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags):
         (JSC::DFG::PredictionPropagationPhase::propagateForward):
         (JSC::DFG::PredictionPropagationPhase::propagateBackward):
         (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
         (PredictionPropagationPhase):
         (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
         * dfg/DFGScoreBoard.h:
         (JSC::DFG::ScoreBoard::ScoreBoard):
         (JSC::DFG::ScoreBoard::use):
         (JSC::DFG::ScoreBoard::useIfHasResult):
         (ScoreBoard):
         * dfg/DFGSilentRegisterSavePlan.h:
         (JSC::DFG::SilentRegisterSavePlan::SilentRegisterSavePlan):
         (JSC::DFG::SilentRegisterSavePlan::node):
         (SilentRegisterSavePlan):
         * dfg/DFGSlowPathGenerator.h:
         (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
         (JSC::DFG::SlowPathGenerator::generate):
         (SlowPathGenerator):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
         (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
         (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
         (JSC::DFG::SpeculativeJIT::silentSavePlanForFPR):
         (JSC::DFG::SpeculativeJIT::silentSpill):
         (JSC::DFG::SpeculativeJIT::silentFill):
         (JSC::DFG::SpeculativeJIT::checkArray):
         (JSC::DFG::SpeculativeJIT::arrayify):
         (JSC::DFG::SpeculativeJIT::fillStorage):
         (JSC::DFG::SpeculativeJIT::useChildren):
         (JSC::DFG::SpeculativeJIT::isStrictInt32):
         (JSC::DFG::SpeculativeJIT::isKnownInteger):
         (JSC::DFG::SpeculativeJIT::isKnownNumeric):
         (JSC::DFG::SpeculativeJIT::isKnownCell):
         (JSC::DFG::SpeculativeJIT::isKnownNotCell):
         (JSC::DFG::SpeculativeJIT::isKnownNotInteger):
         (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
         (JSC::DFG::SpeculativeJIT::writeBarrier):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeStrictEq):
         (JSC::DFG::GPRTemporary::GPRTemporary):
         (JSC::DFG::FPRTemporary::FPRTemporary):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
         (JSC::DFG::SpeculativeJIT::noticeOSRBirth):
         (JSC::DFG::SpeculativeJIT::compileMovHint):
         (JSC::DFG::SpeculativeJIT::compile):
         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
         (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
         (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
         (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
         (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
         (JSC::DFG::SpeculativeJIT::compileSoftModulo):
         (JSC::DFG::SpeculativeJIT::compileAdd):
         (JSC::DFG::SpeculativeJIT::compileArithSub):
         (JSC::DFG::SpeculativeJIT::compileArithNegate):
         (JSC::DFG::SpeculativeJIT::compileArithMul):
         (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86):
         (JSC::DFG::SpeculativeJIT::compileArithMod):
         (JSC::DFG::SpeculativeJIT::compare):
         (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):
         (JSC::DFG::SpeculativeJIT::compileStrictEq):
         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
         (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
         (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
         (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
         (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
         (JSC::DFG::SpeculativeJIT::compileRegExpExec):
         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::canReuse):
         (JSC::DFG::SpeculativeJIT::isFilled):
         (JSC::DFG::SpeculativeJIT::isFilledDouble):
         (JSC::DFG::SpeculativeJIT::use):
         (JSC::DFG::SpeculativeJIT::isConstant):
         (JSC::DFG::SpeculativeJIT::isJSConstant):
         (JSC::DFG::SpeculativeJIT::isInt32Constant):
         (JSC::DFG::SpeculativeJIT::isDoubleConstant):
         (JSC::DFG::SpeculativeJIT::isNumberConstant):
         (JSC::DFG::SpeculativeJIT::isBooleanConstant):
         (JSC::DFG::SpeculativeJIT::isFunctionConstant):
         (JSC::DFG::SpeculativeJIT::valueOfInt32Constant):
         (JSC::DFG::SpeculativeJIT::valueOfNumberConstant):
         (JSC::DFG::SpeculativeJIT::valueOfNumberConstantAsInt32):
         (JSC::DFG::SpeculativeJIT::addressOfDoubleConstant):
         (JSC::DFG::SpeculativeJIT::valueOfJSConstant):
         (JSC::DFG::SpeculativeJIT::valueOfBooleanConstant):
         (JSC::DFG::SpeculativeJIT::valueOfFunctionConstant):
         (JSC::DFG::SpeculativeJIT::isNullConstant):
         (JSC::DFG::SpeculativeJIT::valueOfJSConstantAsImm64):
         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
         (JSC::DFG::SpeculativeJIT::integerResult):
         (JSC::DFG::SpeculativeJIT::noResult):
         (JSC::DFG::SpeculativeJIT::cellResult):
         (JSC::DFG::SpeculativeJIT::booleanResult):
         (JSC::DFG::SpeculativeJIT::jsValueResult):
         (JSC::DFG::SpeculativeJIT::storageResult):
         (JSC::DFG::SpeculativeJIT::doubleResult):
         (JSC::DFG::SpeculativeJIT::initConstantInfo):
         (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck):
         (JSC::DFG::SpeculativeJIT::isInteger):
         (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage):
         (JSC::DFG::SpeculativeJIT::setNodeForOperand):
         (JSC::DFG::IntegerOperand::IntegerOperand):
         (JSC::DFG::IntegerOperand::node):
         (JSC::DFG::IntegerOperand::gpr):
         (JSC::DFG::IntegerOperand::use):
         (IntegerOperand):
         (JSC::DFG::DoubleOperand::DoubleOperand):
         (JSC::DFG::DoubleOperand::node):
         (JSC::DFG::DoubleOperand::fpr):
         (JSC::DFG::DoubleOperand::use):
         (DoubleOperand):
         (JSC::DFG::JSValueOperand::JSValueOperand):
         (JSC::DFG::JSValueOperand::node):
         (JSC::DFG::JSValueOperand::gpr):
         (JSC::DFG::JSValueOperand::fill):
         (JSC::DFG::JSValueOperand::use):
         (JSValueOperand):
         (JSC::DFG::StorageOperand::StorageOperand):
         (JSC::DFG::StorageOperand::node):
         (JSC::DFG::StorageOperand::gpr):
         (JSC::DFG::StorageOperand::use):
         (StorageOperand):
         (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand):
         (JSC::DFG::SpeculateIntegerOperand::node):
         (JSC::DFG::SpeculateIntegerOperand::gpr):
         (JSC::DFG::SpeculateIntegerOperand::use):
         (SpeculateIntegerOperand):
         (JSC::DFG::SpeculateStrictInt32Operand::SpeculateStrictInt32Operand):
         (JSC::DFG::SpeculateStrictInt32Operand::node):
         (JSC::DFG::SpeculateStrictInt32Operand::gpr):
         (JSC::DFG::SpeculateStrictInt32Operand::use):
         (SpeculateStrictInt32Operand):
         (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
         (JSC::DFG::SpeculateDoubleOperand::node):
         (JSC::DFG::SpeculateDoubleOperand::fpr):
         (JSC::DFG::SpeculateDoubleOperand::use):
         (SpeculateDoubleOperand):
         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
         (JSC::DFG::SpeculateCellOperand::node):
         (JSC::DFG::SpeculateCellOperand::gpr):
         (JSC::DFG::SpeculateCellOperand::use):
         (SpeculateCellOperand):
         (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
         (JSC::DFG::SpeculateBooleanOperand::node):
         (JSC::DFG::SpeculateBooleanOperand::gpr):
         (JSC::DFG::SpeculateBooleanOperand::use):
         (SpeculateBooleanOperand):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillDouble):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
         (JSC::DFG::SpeculativeJIT::cachedPutById):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
         (JSC::DFG::SpeculativeJIT::emitCall):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
         (JSC::DFG::SpeculativeJIT::compileDoubleCompare):
         (JSC::DFG::SpeculativeJIT::compileValueAdd):
         (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillDouble):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
         (JSC::DFG::SpeculativeJIT::cachedPutById):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
         (JSC::DFG::SpeculativeJIT::emitCall):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
         (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
         (JSC::DFG::SpeculativeJIT::compileDoubleCompare):
         (JSC::DFG::SpeculativeJIT::compileValueAdd):
         (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot):
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch):
         (JSC::DFG::SpeculativeJIT::emitBranch):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGStructureAbstractValue.h:
         (StructureAbstractValue):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         * dfg/DFGValidate.cpp:
         (DFG):
         (Validate):
         (JSC::DFG::Validate::validate):
         (JSC::DFG::Validate::reportValidationContext):
         * dfg/DFGValidate.h:
         * dfg/DFGValueSource.cpp:
         (JSC::DFG::ValueSource::dump):
         * dfg/DFGValueSource.h:
         (JSC::DFG::ValueSource::ValueSource):
         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
         (JSC::DFG::VirtualRegisterAllocationPhase::run):
         * runtime/FunctionExecutableDump.cpp: Added.
         (JSC):
         (JSC::FunctionExecutableDump::dump):
         * runtime/FunctionExecutableDump.h: Added.
         (JSC):
         (FunctionExecutableDump):
         (JSC::FunctionExecutableDump::FunctionExecutableDump):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSC):
         (DFG):
         (JSGlobalData):
         * runtime/Options.h:
         (JSC):

 2013-01-28  Laszlo Gombos  <l.gombos@samsung.com>

         Collapse testing for a list of PLATFORM() into OS() and USE() tests
         https://bugs.webkit.org/show_bug.cgi?id=108018

         Reviewed by Eric Seidel.

         No functional change as "OS(DARWIN) && USE(CF)" equals to the
         following platforms: MAC, WX, QT and CHROMIUM. CHROMIUM
         is not using JavaScriptCore.

         * runtime/DatePrototype.cpp:
         (JSC):

 2013-01-28  Geoffrey Garen  <ggaren@apple.com>

         Static size inference for JavaScript objects
         https://bugs.webkit.org/show_bug.cgi?id=108093

         Reviewed by Phil Pizlo.

         * API/JSObjectRef.cpp:
         * JavaScriptCore.order:
         * JavaScriptCore.xcodeproj/project.pbxproj: Pay the tax man.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode): op_new_object and op_create_this now
         have an extra inferredInlineCapacity argument. This is the statically
         inferred inline capacity, just from analyzing source text. op_new_object
         also gets a pointer to an allocation profile. (For op_create_this, the
         profile is in the construtor function.)

         (JSC::CodeBlock::CodeBlock): Link op_new_object.

         (JSC::CodeBlock::stronglyVisitStrongReferences): Mark our profiles.

         * bytecode/CodeBlock.h:
         (CodeBlock): Removed some dead code. Added object allocation profiles.

         * bytecode/Instruction.h:
         (JSC): New union type, since an instruction operand may point to an
         object allocation profile now.

         * bytecode/ObjectAllocationProfile.h: Added.
         (JSC):
         (ObjectAllocationProfile):
         (JSC::ObjectAllocationProfile::offsetOfAllocator):
         (JSC::ObjectAllocationProfile::offsetOfStructure):
         (JSC::ObjectAllocationProfile::ObjectAllocationProfile):
         (JSC::ObjectAllocationProfile::isNull):
         (JSC::ObjectAllocationProfile::initialize):
         (JSC::ObjectAllocationProfile::structure):
         (JSC::ObjectAllocationProfile::inlineCapacity):
         (JSC::ObjectAllocationProfile::clear):
         (JSC::ObjectAllocationProfile::visitAggregate):
         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): New class
         for tracking a prediction about object allocation: structure, inline
         capacity, allocator to use.

         * bytecode/Opcode.h:
         (JSC):
         (JSC::padOpcodeName): Updated instruction sizes.

         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
         * bytecode/UnlinkedCodeBlock.h:
         (JSC):
         (JSC::UnlinkedCodeBlock::addObjectAllocationProfile):
         (JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles):
         (UnlinkedCodeBlock): Unlinked support for allocation profiles.

         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::generate): Kill all remaining analyses at the
         end of codegen, since this is our last opportunity.

         (JSC::BytecodeGenerator::BytecodeGenerator): Added a static property
         analyzer to bytecode generation. It tracks initializing assignments and
         makes a guess about how many will happen.

         (JSC::BytecodeGenerator::newObjectAllocationProfile):
         (JSC):
         (JSC::BytecodeGenerator::emitProfiledOpcode):
         (JSC::BytecodeGenerator::emitMove):
         (JSC::BytecodeGenerator::emitResolve):
         (JSC::BytecodeGenerator::emitResolveBase):
         (JSC::BytecodeGenerator::emitResolveBaseForPut):
         (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
         (JSC::BytecodeGenerator::emitResolveWithThis):
         (JSC::BytecodeGenerator::emitGetById):
         (JSC::BytecodeGenerator::emitPutById):
         (JSC::BytecodeGenerator::emitDirectPutById):
         (JSC::BytecodeGenerator::emitPutGetterSetter):
         (JSC::BytecodeGenerator::emitGetArgumentByVal):
         (JSC::BytecodeGenerator::emitGetByVal): Added hooks to the static property
         analyzer, so it can observe allocations and stores.

         (JSC::BytecodeGenerator::emitCreateThis): Factored this into a helper
         function because it was a significant amount of logic, and I wanted to
         add to it.

         (JSC::BytecodeGenerator::emitNewObject):
         (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
         (JSC::BytecodeGenerator::emitCall):
         (JSC::BytecodeGenerator::emitCallVarargs):
         (JSC::BytecodeGenerator::emitConstruct): Added a hook to profiled opcodes
         to track their stores, in case a store kills a profiled allocation. Since
         profiled opcodes are basically the only interesting stores we do, this
         is a convenient place to notice any store that might kill an allocation.

         * bytecompiler/BytecodeGenerator.h:
         (BytecodeGenerator): As above.

         * bytecompiler/StaticPropertyAnalysis.h: Added.
         (JSC):
         (StaticPropertyAnalysis):
         (JSC::StaticPropertyAnalysis::create):
         (JSC::StaticPropertyAnalysis::addPropertyIndex):
         (JSC::StaticPropertyAnalysis::record):
         (JSC::StaticPropertyAnalysis::propertyIndexCount):
         (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis): Simple helper
         class for tracking allocations and stores.

         * bytecompiler/StaticPropertyAnalyzer.h: Added.
         (StaticPropertyAnalyzer):
         (JSC::StaticPropertyAnalyzer::StaticPropertyAnalyzer):
         (JSC::StaticPropertyAnalyzer::createThis):
         (JSC::StaticPropertyAnalyzer::newObject):
         (JSC::StaticPropertyAnalyzer::putById):
         (JSC::StaticPropertyAnalyzer::mov):
         (JSC::StaticPropertyAnalyzer::kill): Helper class for observing allocations
         and stores and making an inline capacity guess. The heuristics here are
         intentionally minimal because we don't want this one class to try to
         re-create something like a DFG or a runtime analysis. If we discover that
         we need those kinds of analyses, we should just replace this class with
         something else.

         This class tracks multiple registers that alias the same object -- that
         happens a lot, when moving locals into temporary registers -- but it
         doesn't track control flow or multiple objects that alias the same register.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute): Updated for rename.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock): Updated for inline capacity and
         allocation profile.

         * dfg/DFGNode.h:
         (JSC::DFG::Node::hasInlineCapacity):
         (Node):
         (JSC::DFG::Node::inlineCapacity):
         (JSC::DFG::Node::hasFunction): Give the graph a good way to represent
         inline capacity for an allocation.

         * dfg/DFGNodeType.h:
         (DFG): Updated for rename.

         * dfg/DFGOperations.cpp: Updated for interface change.

         * dfg/DFGOperations.h: We pass the inline capacity to the slow case as
         an argument. This is the simplest way, since it's stored as a bytecode operand.

         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate): Updated for rename.

         * dfg/DFGRepatch.cpp:
         (JSC::DFG::tryCacheGetByID): Fixed a horrible off-by-one-half bug that only
         appears when doing an inline cached load for property number 64 on a 32-bit
         system. In JSVALUE32_64 land, "offsetRelativeToPatchedStorage" is the
         offset of the 64bit JSValue -- but we'll actually issue two loads, one for
         the payload at that offset, and one for the tag at that offset + 4. We need
         to ensure that both loads have a compact representation, or we'll corrupt
         the instruction stream.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):
         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage):
         (SpeculativeJIT):
         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile): Lots of refactoring to support
         passing an allocator to our allocation function, and/or passing a Structure
         as a register instead of an immediate.

         * heap/MarkedAllocator.h:
         (DFG):
         (MarkedAllocator):
         (JSC::MarkedAllocator::offsetOfFreeListHead): Added an accessor to simplify
         JIT code generation of allocation from an arbitrary allocator.

         * jit/JIT.h:
         (JSC):
         * jit/JITInlines.h:
         (JSC):
         (JSC::JIT::emitAllocateJSObject):
         * jit/JITOpcodes.cpp:
         (JSC::JIT::emit_op_new_object):
         (JSC::JIT::emitSlow_op_new_object):
         (JSC::JIT::emit_op_create_this):
         (JSC::JIT::emitSlow_op_create_this):
         * jit/JITOpcodes32_64.cpp:
         (JSC::JIT::emit_op_new_object):
         (JSC::JIT::emitSlow_op_new_object):
         (JSC::JIT::emit_op_create_this):
         (JSC::JIT::emitSlow_op_create_this): Same refactoring as done for the DFG.

         * jit/JITStubs.cpp:
         (JSC::tryCacheGetByID): Fixed the same bug mentioned above.

         (JSC::DEFINE_STUB_FUNCTION): Updated for interface changes.

         * llint/LLIntData.cpp:
         (JSC::LLInt::Data::performAssertions): Updated for interface changes.

         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm: Same refactoring as for the JITs.

         * profiler/ProfilerBytecode.cpp:
         * profiler/ProfilerBytecodes.cpp:
         * profiler/ProfilerCompilation.cpp:
         * profiler/ProfilerCompiledBytecode.cpp:
         * profiler/ProfilerDatabase.cpp:
         * profiler/ProfilerOSRExit.cpp:
         * profiler/ProfilerOrigin.cpp:
         * profiler/ProfilerProfiledBytecodes.cpp: Include ObjectConstructor.h
         because that's where createEmptyObject() lives now.

         * runtime/Executable.h:
         (JSC::JSFunction::JSFunction): Updated for rename.

         * runtime/JSCellInlines.h:
         (JSC::allocateCell): Updated to match the allocator selection code in
         the JIT, so it's clearer that both are correct.

         * runtime/JSFunction.cpp:
         (JSC::JSFunction::JSFunction):
         (JSC::JSFunction::createAllocationProfile):
         (JSC::JSFunction::visitChildren):
         (JSC::JSFunction::getOwnPropertySlot):
         (JSC::JSFunction::put):
         (JSC::JSFunction::defineOwnProperty):
         (JSC::JSFunction::getConstructData):
         * runtime/JSFunction.h:
         (JSC::JSFunction::offsetOfScopeChain):
         (JSC::JSFunction::offsetOfExecutable):
         (JSC::JSFunction::offsetOfAllocationProfile):
         (JSC::JSFunction::allocationProfile):
         (JSFunction):
         (JSC::JSFunction::tryGetAllocationProfile):
         (JSC::JSFunction::addAllocationProfileWatchpoint): Changed inheritorID
         data member to be an ObjectAllocationProfile, which includes a pointer
         to the desired allocator. This simplifies JIT code, since we don't have
         to compute the allocator on the fly. I verified by code inspection that
         JSFunction is still only 64 bytes.

         * runtime/JSGlobalObject.cpp:
         (JSC::JSGlobalObject::reset):
         (JSC::JSGlobalObject::visitChildren):
         * runtime/JSGlobalObject.h:
         (JSGlobalObject):
         (JSC::JSGlobalObject::dateStructure): No direct pointer to the empty
         object structure anymore, because now clients need to specify how much
         inline capacity they want.

         * runtime/JSONObject.cpp:
         * runtime/JSObject.h:
         (JSC):
         (JSFinalObject):
         (JSC::JSFinalObject::defaultInlineCapacity):
         (JSC::JSFinalObject::maxInlineCapacity):
         (JSC::JSFinalObject::createStructure): A little refactoring to try to
         clarify where some of these constants derive from.

         (JSC::maxOffsetRelativeToPatchedStorage): Used for bug fix, above.

         * runtime/JSProxy.cpp:
         (JSC::JSProxy::setTarget): Ugly, but effective.

         * runtime/LiteralParser.cpp:
         * runtime/ObjectConstructor.cpp:
         (JSC::constructObject):
         (JSC::constructWithObjectConstructor):
         (JSC::callObjectConstructor):
         (JSC::objectConstructorCreate): Updated for interface changes.

         * runtime/ObjectConstructor.h:
         (JSC::constructEmptyObject): Clarified your options for how to allocate
         an empty object, to emphasize what things can actually vary.

         * runtime/PropertyOffset.h: These constants have moved because they're
         really higher level concepts to do with the layout of objects and the
         collector. PropertyOffset is just an abstract number line, independent
         of those things.

         * runtime/PrototypeMap.cpp:
         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
         * runtime/PrototypeMap.h:
         (PrototypeMap): The map key is now a pair of prototype and inline capacity,
         since Structure encodes inline capacity.

         * runtime/Structure.cpp:
         (JSC::Structure::Structure):
         (JSC::Structure::materializePropertyMap):
         (JSC::Structure::addPropertyTransition):
         (JSC::Structure::nonPropertyTransition):
         (JSC::Structure::copyPropertyTableForPinning):
         * runtime/Structure.h:
         (Structure):
         (JSC::Structure::totalStorageSize):
         (JSC::Structure::transitionCount):
         (JSC::Structure::create): Fixed a nasty refactoring bug that only shows
         up after enabling variable-sized inline capacities: we were passing our
         type info where our inline capacity was expected. The compiler didn't
         notice because both have type int :(.

 2013-01-28  Oliver Hunt  <oliver@apple.com>

         Add more assertions to the property storage use in arrays
         https://bugs.webkit.org/show_bug.cgi?id=107728

         Reviewed by Filip Pizlo.

         Add a bunch of assertions to array and object butterfly
         usage.  This should make debugging somewhat easier.

         I also converted a couple of assertions to release asserts
         as they were so low cost it seemed a sensible thing to do.

         * runtime/JSArray.cpp:
         (JSC::JSArray::sortVector):
         (JSC::JSArray::compactForSorting):
         * runtime/JSObject.h:
         (JSC::JSObject::getHolyIndexQuickly):

 2013-01-28  Adam Barth  <abarth@webkit.org>

         Remove webkitNotifications.createHTMLNotification
         https://bugs.webkit.org/show_bug.cgi?id=107598

         Reviewed by Benjamin Poulain.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-28  Michael Saboff  <msaboff@apple.com>

         Cleanup ARM version of debugName() in DFGFPRInfo.h
         https://bugs.webkit.org/show_bug.cgi?id=108090

         Reviewed by David Kilzer.

         Fixed debugName() so it will compile by adding static_cast<int> and missing commas.

         * dfg/DFGFPRInfo.h:
         (JSC::DFG::FPRInfo::debugName):

 2013-01-27  Andreas Kling  <akling@apple.com>

         JSC: FunctionParameters are memory hungry.
         <http://webkit.org/b/108033>
         <rdar://problem/13094803>

         Reviewed by Sam Weinig.

         Instead of inheriting from Vector<Identifier>, make FunctionParameters a simple fixed-size array
         with a custom-allocating create() function. Removes one step of indirection and cuts memory usage
         roughly in half.

         2.73 MB progression on Membuster3.

         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::UnlinkedFunctionExecutable::paramString):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::BytecodeGenerator):
         * parser/Nodes.cpp:
         (JSC::FunctionParameters::create):
         (JSC::FunctionParameters::FunctionParameters):
         (JSC::FunctionParameters::~FunctionParameters):
         * parser/Nodes.h:
         (FunctionParameters):
         (JSC::FunctionParameters::size):
         (JSC::FunctionParameters::at):
         (JSC::FunctionParameters::identifiers):

 2013-01-27  Andreas Kling  <akling@apple.com>

         JSC: SourceProviderCache is memory hungry.
         <http://webkit.org/b/108029>
         <rdar://problem/13094806>

         Reviewed by Sam Weinig.

         Use fixed-size arrays for SourceProviderCacheItem's lists of captured variables.
         Since the lists never change after the object is created, there's no need to keep them in Vectors
         and we can instead create the whole cache item in a single allocation.

         13.37 MB progression on Membuster3.

         * parser/Parser.cpp:
         (JSC::::parseFunctionInfo):
         * parser/Parser.h:
         (JSC::Scope::copyCapturedVariablesToVector):
         (JSC::Scope::fillParametersForSourceProviderCache):
         (JSC::Scope::restoreFromSourceProviderCache):
         * parser/SourceProviderCacheItem.h:
         (SourceProviderCacheItemCreationParameters):
         (SourceProviderCacheItem):
         (JSC::SourceProviderCacheItem::approximateByteSize):
         (JSC::SourceProviderCacheItem::usedVariables):
         (JSC::SourceProviderCacheItem::writtenVariables):
         (JSC::SourceProviderCacheItem::~SourceProviderCacheItem):
         (JSC::SourceProviderCacheItem::create):
         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):

 2013-01-27  Zoltan Arvai  <zarvai@inf.u-szeged.hu>

         Fixing atomicIncrement implementation for Windows by dropping support before XP SP2.
         https://bugs.webkit.org/show_bug.cgi?id=106740

         Reviewed by Benjamin Poulain.

         * config.h:

 2013-01-25  Filip Pizlo  <fpizlo@apple.com>

         DFG variable event stream shouldn't use NodeIndex
         https://bugs.webkit.org/show_bug.cgi?id=107996

         Reviewed by Oliver Hunt.

         Introduce the notion of a DFG::MinifiedID, which is just a unique ID of a DFG Node.
         Internally it currently uses a NodeIndex, but we could change this without having
         to recode all of the users of MinifiedID. This effectively decouples the OSR exit
         compiler's way of identifying nodes from the speculative JIT's way of identifying
         nodes, and should make it easier to make changes to the speculative JIT's internals
         in the future.

         Also changed variable event stream logging to exclude information about births and
         deaths of constants, since the OSR exit compiler never cares about which register
         holds a constant; if a value is constant then the OSR exit compiler can reify it.

         Also changed the variable event stream's value recovery computation to use a
         HashMap keyed by MinifiedID rather than a Vector indexed by NodeIndex.

         This appears to be performance-neutral. It's primarily meant as a small step
         towards https://bugs.webkit.org/show_bug.cgi?id=106868.

         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * dfg/DFGGenerationInfo.h:
         (JSC::DFG::GenerationInfo::GenerationInfo):
         (JSC::DFG::GenerationInfo::initConstant):
         (JSC::DFG::GenerationInfo::initInteger):
         (JSC::DFG::GenerationInfo::initJSValue):
         (JSC::DFG::GenerationInfo::initCell):
         (JSC::DFG::GenerationInfo::initBoolean):
         (JSC::DFG::GenerationInfo::initDouble):
         (JSC::DFG::GenerationInfo::initStorage):
         (JSC::DFG::GenerationInfo::noticeOSRBirth):
         (JSC::DFG::GenerationInfo::use):
         (JSC::DFG::GenerationInfo::appendFill):
         (JSC::DFG::GenerationInfo::appendSpill):
         (GenerationInfo):
         * dfg/DFGJITCompiler.cpp:
         (JSC::DFG::JITCompiler::link):
         * dfg/DFGMinifiedGraph.h:
         (JSC::DFG::MinifiedGraph::at):
         (MinifiedGraph):
         * dfg/DFGMinifiedID.h: Added.
         (DFG):
         (MinifiedID):
         (JSC::DFG::MinifiedID::MinifiedID):
         (JSC::DFG::MinifiedID::operator!):
         (JSC::DFG::MinifiedID::nodeIndex):
         (JSC::DFG::MinifiedID::operator==):
         (JSC::DFG::MinifiedID::operator!=):
         (JSC::DFG::MinifiedID::operator<):
         (JSC::DFG::MinifiedID::operator>):
         (JSC::DFG::MinifiedID::operator<=):
         (JSC::DFG::MinifiedID::operator>=):
         (JSC::DFG::MinifiedID::hash):
         (JSC::DFG::MinifiedID::dump):
         (JSC::DFG::MinifiedID::isHashTableDeletedValue):
         (JSC::DFG::MinifiedID::invalidID):
         (JSC::DFG::MinifiedID::otherInvalidID):
         (JSC::DFG::MinifiedID::fromBits):
         (JSC::DFG::MinifiedIDHash::hash):
         (JSC::DFG::MinifiedIDHash::equal):
         (MinifiedIDHash):
         (WTF):
         * dfg/DFGMinifiedNode.cpp:
         (JSC::DFG::MinifiedNode::fromNode):
         * dfg/DFGMinifiedNode.h:
         (JSC::DFG::MinifiedNode::id):
         (JSC::DFG::MinifiedNode::child1):
         (JSC::DFG::MinifiedNode::getID):
         (JSC::DFG::MinifiedNode::compareByNodeIndex):
         (MinifiedNode):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileMovHint):
         (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::setNodeIndexForOperand):
         * dfg/DFGValueSource.cpp:
         (JSC::DFG::ValueSource::dump):
         * dfg/DFGValueSource.h:
         (JSC::DFG::ValueSource::ValueSource):
         (JSC::DFG::ValueSource::isSet):
         (JSC::DFG::ValueSource::kind):
         (JSC::DFG::ValueSource::id):
         (ValueSource):
         (JSC::DFG::ValueSource::idFromKind):
         (JSC::DFG::ValueSource::kindFromID):
         * dfg/DFGVariableEvent.cpp:
         (JSC::DFG::VariableEvent::dump):
         (JSC::DFG::VariableEvent::dumpFillInfo):
         (JSC::DFG::VariableEvent::dumpSpillInfo):
         * dfg/DFGVariableEvent.h:
         (JSC::DFG::VariableEvent::fillGPR):
         (JSC::DFG::VariableEvent::fillPair):
         (JSC::DFG::VariableEvent::fillFPR):
         (JSC::DFG::VariableEvent::spill):
         (JSC::DFG::VariableEvent::death):
         (JSC::DFG::VariableEvent::movHint):
         (JSC::DFG::VariableEvent::id):
         (VariableEvent):
         * dfg/DFGVariableEventStream.cpp:
         (DFG):
         (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
         (JSC::DFG::VariableEventStream::reconstruct):
         * dfg/DFGVariableEventStream.h:
         (VariableEventStream):

 2013-01-25  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Rename LLInt projects folder and make appropriate changes to solutions.

         * JavaScriptCore.vcxproj/JavaScriptCore.sln:
         * JavaScriptCore.vcxproj/LLInt: Copied from JavaScriptCore.vcxproj/LLInt.vcproj.
         * JavaScriptCore.vcxproj/LLInt.vcproj: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.make: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj.user: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj.user: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj.user: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed.

 2013-01-24  Roger Fong  <roger_fong@apple.com>

         VS2010 JavascriptCore: Clean up property sheets, add a JSC solution, add testRegExp and testAPI projects.
         https://bugs.webkit.org/show_bug.cgi?id=106987

         Reviewed by Brent Fulgham.

         * JavaScriptCore.vcxproj/JavaScriptCore.sln: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreCF.props:
         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
         * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
         * JavaScriptCore.vcxproj/jsc/jscCommon.props:
         * JavaScriptCore.vcxproj/jsc/jscDebug.props:
         * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
         * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
         * JavaScriptCore.vcxproj/testRegExp: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Added.
         * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Added.
         * JavaScriptCore.vcxproj/testapi: Added.
         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Added.
         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Added.
         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Added.
         * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Added.
         * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Added.
         * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Added.
         * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Added.
         * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Added.

 2013-01-24  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Windows build fix.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

 2013-01-24  Filip Pizlo  <fpizlo@apple.com>

         DFG::JITCompiler::getSpeculation() methods are badly named and superfluous
         https://bugs.webkit.org/show_bug.cgi?id=107860

         Reviewed by Mark Hahnenberg.

         * dfg/DFGJITCompiler.h:
         (JITCompiler):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
         (JSC::DFG::SpeculativeJIT::emitBranch):

 2013-01-24  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Rename JSValue.h/APIJSValue.h to JSCJSValue.h/JSValue.h
         https://bugs.webkit.org/show_bug.cgi?id=107327

         Reviewed by Filip Pizlo.

         We're renaming these two files, so we have to replace the names everywhere.

         * API/APICast.h:
         * API/APIJSValue.h: Removed.
         * API/JSBlockAdaptor.mm:
         * API/JSStringRefCF.cpp:
         * API/JSValue.h: Copied from Source/JavaScriptCore/API/APIJSValue.h.
         * API/JSValue.mm:
         * API/JSValueInternal.h:
         * API/JSValueRef.cpp:
         * API/JSWeakObjectMapRefPrivate.cpp:
         * API/JavaScriptCore.h:
         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/CallLinkStatus.h:
         * bytecode/CodeBlock.cpp:
         * bytecode/MethodOfGettingAValueProfile.h:
         * bytecode/ResolveGlobalStatus.cpp:
         * bytecode/ResolveGlobalStatus.h:
         * bytecode/SpeculatedType.h:
         * bytecode/ValueRecovery.h:
         * dfg/DFGByteCodeParser.cpp:
         * dfg/DFGJITCompiler.cpp:
         * dfg/DFGNode.h:
         * dfg/DFGSpeculativeJIT.cpp:
         * dfg/DFGSpeculativeJIT64.cpp:
         * heap/CopiedBlock.h:
         * heap/HandleStack.cpp:
         * heap/HandleTypes.h:
         * heap/WeakImpl.h:
         * interpreter/Interpreter.h:
         * interpreter/Register.h:
         * interpreter/VMInspector.h:
         * jit/HostCallReturnValue.cpp:
         * jit/HostCallReturnValue.h:
         * jit/JITCode.h:
         * jit/JITExceptions.cpp:
         * jit/JITExceptions.h:
         * jit/JSInterfaceJIT.h:
         * llint/LLIntCLoop.h:
         * llint/LLIntData.h:
         * llint/LLIntSlowPaths.cpp:
         * profiler/ProfilerBytecode.h:
         * profiler/ProfilerBytecodeSequence.h:
         * profiler/ProfilerBytecodes.h:
         * profiler/ProfilerCompilation.h:
         * profiler/ProfilerCompiledBytecode.h:
         * profiler/ProfilerDatabase.h:
         * profiler/ProfilerOSRExit.h:
         * profiler/ProfilerOSRExitSite.h:
         * profiler/ProfilerOrigin.h:
         * profiler/ProfilerOriginStack.h:
         * runtime/ArgList.cpp:
         * runtime/CachedTranscendentalFunction.h:
         * runtime/CallData.h:
         * runtime/Completion.h:
         * runtime/ConstructData.h:
         * runtime/DateConstructor.cpp:
         * runtime/DateInstance.cpp:
         * runtime/DatePrototype.cpp:
         * runtime/JSAPIValueWrapper.h:
         * runtime/JSCJSValue.cpp: Copied from Source/JavaScriptCore/runtime/JSValue.cpp.
         * runtime/JSCJSValue.h: Copied from Source/JavaScriptCore/runtime/JSValue.h.
         (JSValue):
         * runtime/JSCJSValueInlines.h: Copied from Source/JavaScriptCore/runtime/JSValueInlines.h.
         * runtime/JSGlobalData.h:
         * runtime/JSGlobalObject.cpp:
         * runtime/JSGlobalObjectFunctions.h:
         * runtime/JSStringJoiner.h:
         * runtime/JSValue.cpp: Removed.
         * runtime/JSValue.h: Removed.
         * runtime/JSValueInlines.h: Removed.
         * runtime/LiteralParser.h:
         * runtime/Operations.h:
         * runtime/PropertyDescriptor.h:
         * runtime/PropertySlot.h:
         * runtime/Protect.h:
         * runtime/RegExpPrototype.cpp:
         * runtime/Structure.h:

 2013-01-23  Oliver Hunt  <oliver@apple.com>

         Harden JSC a bit with RELEASE_ASSERT
         https://bugs.webkit.org/show_bug.cgi?id=107766

         Reviewed by Mark Hahnenberg.

         Went through and replaced a pile of ASSERTs that were covering
         significantly important details (bounds checks, etc) where
         having the checks did not impact release performance in any
         measurable way.

         * API/JSContextRef.cpp:
         (JSContextCreateBacktrace):
         * assembler/MacroAssembler.h:
         (JSC::MacroAssembler::branchAdd32):
         (JSC::MacroAssembler::branchMul32):
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::handlerForBytecodeOffset):
         (JSC::CodeBlock::lineNumberForBytecodeOffset):
         (JSC::CodeBlock::bytecodeOffset):
         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::bytecodeOffsetForCallAtIndex):
         (JSC::CodeBlock::bytecodeOffset):
         (JSC::CodeBlock::exceptionHandler):
         (JSC::CodeBlock::codeOrigin):
         (JSC::CodeBlock::immediateSwitchJumpTable):
         (JSC::CodeBlock::characterSwitchJumpTable):
         (JSC::CodeBlock::stringSwitchJumpTable):
         (JSC::CodeBlock::setIdentifiers):
         (JSC::baselineCodeBlockForInlineCallFrame):
         (JSC::ExecState::uncheckedR):
         * bytecode/CodeOrigin.cpp:
         (JSC::CodeOrigin::inlineStack):
         * bytecode/CodeOrigin.h:
         (JSC::CodeOrigin::CodeOrigin):
         * dfg/DFGCSEPhase.cpp:
         * dfg/DFGOSRExit.cpp:
         * dfg/DFGScratchRegisterAllocator.h:
         (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
         (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::allocate):
         (JSC::DFG::SpeculativeJIT::spill):
         (JSC::DFG::SpeculativeJIT::integerResult):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillDouble):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
         (JSC::DFG::SpeculativeJIT::emitCall):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGValueSource.h:
         (JSC::DFG::dataFormatToValueSourceKind):
         (JSC::DFG::ValueSource::ValueSource):
         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
         * heap/BlockAllocator.cpp:
         (JSC::BlockAllocator::BlockAllocator):
         (JSC::BlockAllocator::releaseFreeRegions):
         (JSC::BlockAllocator::blockFreeingThreadMain):
         * heap/Heap.cpp:
         (JSC::Heap::lastChanceToFinalize):
         (JSC::Heap::collect):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::throwException):
         (JSC::Interpreter::execute):
         * jit/GCAwareJITStubRoutine.cpp:
         (JSC::GCAwareJITStubRoutine::observeZeroRefCount):
         * jit/JIT.cpp:
         (JSC::JIT::privateCompileMainPass):
         (JSC::JIT::privateCompileSlowCases):
         * jit/JITExceptions.cpp:
         (JSC::genericThrow):
         * jit/JITInlines.h:
         (JSC::JIT::emitLoad):
         * jit/JITOpcodes.cpp:
         (JSC::JIT::emit_op_end):
         (JSC::JIT::emit_resolve_operations):
         * jit/JITStubRoutine.cpp:
         (JSC::JITStubRoutine::observeZeroRefCount):
         * jit/JITStubs.cpp:
         (JSC::returnToThrowTrampoline):
         * runtime/Arguments.cpp:
         (JSC::Arguments::getOwnPropertySlot):
         (JSC::Arguments::getOwnPropertyDescriptor):
         (JSC::Arguments::deleteProperty):
         (JSC::Arguments::defineOwnProperty):
         (JSC::Arguments::didTearOffActivation):
         * runtime/ArrayPrototype.cpp:
         (JSC::shift):
         (JSC::unshift):
         (JSC::arrayProtoFuncLastIndexOf):
         * runtime/ButterflyInlines.h:
         (JSC::Butterfly::growPropertyStorage):
         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
         * runtime/CodeCache.h:
         (JSC::CacheMap::add):
         * runtime/Completion.cpp:
         (JSC::checkSyntax):
         (JSC::evaluate):
         * runtime/Executable.cpp:
         (JSC::FunctionExecutable::FunctionExecutable):
         (JSC::EvalExecutable::unlinkCalls):
         (JSC::ProgramExecutable::compileOptimized):
         (JSC::ProgramExecutable::unlinkCalls):
         (JSC::ProgramExecutable::initializeGlobalProperties):
         (JSC::FunctionExecutable::baselineCodeBlockFor):
         (JSC::FunctionExecutable::compileOptimizedForCall):
         (JSC::FunctionExecutable::compileOptimizedForConstruct):
         (JSC::FunctionExecutable::compileForCallInternal):
         (JSC::FunctionExecutable::compileForConstructInternal):
         (JSC::FunctionExecutable::unlinkCalls):
         (JSC::NativeExecutable::hashFor):
         * runtime/Executable.h:
         (JSC::EvalExecutable::compile):
         (JSC::ProgramExecutable::compile):
         (JSC::FunctionExecutable::compileForCall):
         (JSC::FunctionExecutable::compileForConstruct):
         * runtime/IndexingHeader.h:
         (JSC::IndexingHeader::setVectorLength):
         * runtime/JSArray.cpp:
         (JSC::JSArray::pop):
         (JSC::JSArray::shiftCountWithArrayStorage):
         (JSC::JSArray::shiftCountWithAnyIndexingType):
         (JSC::JSArray::unshiftCountWithArrayStorage):
         * runtime/JSGlobalObjectFunctions.cpp:
         (JSC::jsStrDecimalLiteral):
         * runtime/JSObject.cpp:
         (JSC::JSObject::copyButterfly):
         (JSC::JSObject::defineOwnIndexedProperty):
         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
         * runtime/JSString.cpp:
         (JSC::JSRopeString::getIndexSlowCase):
         * yarr/YarrInterpreter.cpp:
         (JSC::Yarr::Interpreter::popParenthesesDisjunctionContext):

 2013-01-23  Filip Pizlo  <fpizlo@apple.com>

         Constant folding an access to an uncaptured variable that is captured later in the same basic block shouldn't lead to assertion failures
         https://bugs.webkit.org/show_bug.cgi?id=107750
         <rdar://problem/12387265>

         Reviewed by Mark Hahnenberg.

         The point of this assertion was that if there is no variable capturing going on, then there should only be one GetLocal
         for the variable anywhere in the basic block. But if there is some capturing, then we'll have an unbounded number of
         GetLocals. The assertion was too imprecise for the latter case. I want to keep this assertion, so I introduced a
         checker that verifies this precisely: if there are any captured accesses to the variable anywhere at or after the
         GetLocal we are eliminating, then we allow redundant GetLocals.

         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         (ConstantFoldingPhase):
         (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter):

 2013-01-23  Oliver Hunt  <oliver@apple.com>

         Replace ASSERT_NOT_REACHED with RELEASE_ASSERT_NOT_REACHED in JSC
         https://bugs.webkit.org/show_bug.cgi?id=107736

         Reviewed by Mark Hahnenberg.

         Mechanical change with no performance impact.

         * API/JSBlockAdaptor.mm:
         (BlockArgumentTypeDelegate::typeVoid):
         * API/JSCallbackObjectFunctions.h:
         (JSC::::construct):
         (JSC::::call):
         * API/JSScriptRef.cpp:
         * API/ObjCCallbackFunction.mm:
         (ArgumentTypeDelegate::typeVoid):
         * assembler/ARMv7Assembler.h:
         (JSC::ARMv7Assembler::link):
         (JSC::ARMv7Assembler::replaceWithLoad):
         (JSC::ARMv7Assembler::replaceWithAddressComputation):
         * assembler/MacroAssembler.h:
         (JSC::MacroAssembler::invert):
         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::countLeadingZeros32):
         (JSC::MacroAssemblerARM::divDouble):
         * assembler/MacroAssemblerMIPS.h:
         (JSC::MacroAssemblerMIPS::absDouble):
         (JSC::MacroAssemblerMIPS::replaceWithJump):
         (JSC::MacroAssemblerMIPS::maxJumpReplacementSize):
         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::absDouble):
         (JSC::MacroAssemblerSH4::replaceWithJump):
         (JSC::MacroAssemblerSH4::maxJumpReplacementSize):
         * assembler/SH4Assembler.h:
         (JSC::SH4Assembler::shllImm8r):
         (JSC::SH4Assembler::shlrImm8r):
         (JSC::SH4Assembler::cmplRegReg):
         (JSC::SH4Assembler::branch):
         * assembler/X86Assembler.h:
         (JSC::X86Assembler::replaceWithLoad):
         (JSC::X86Assembler::replaceWithAddressComputation):
         * bytecode/CallLinkInfo.cpp:
         (JSC::CallLinkInfo::unlink):
         * bytecode/CodeBlock.cpp:
         (JSC::debugHookName):
         (JSC::CodeBlock::printGetByIdOp):
         (JSC::CodeBlock::printGetByIdCacheStatus):
         (JSC::CodeBlock::visitAggregate):
         (JSC::CodeBlock::finalizeUnconditionally):
         (JSC::CodeBlock::usesOpcode):
         * bytecode/DataFormat.h:
         (JSC::needDataFormatConversion):
         * bytecode/ExitKind.cpp:
         (JSC::exitKindToString):
         (JSC::exitKindIsCountable):
         * bytecode/MethodOfGettingAValueProfile.cpp:
         (JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
         * bytecode/Opcode.h:
         (JSC::opcodeLength):
         * bytecode/PolymorphicPutByIdList.cpp:
         (JSC::PutByIdAccess::fromStructureStubInfo):
         (JSC::PutByIdAccess::visitWeak):
         * bytecode/StructureStubInfo.cpp:
         (JSC::StructureStubInfo::deref):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::ResolveResult::checkValidity):
         (JSC::BytecodeGenerator::emitGetLocalVar):
         (JSC::BytecodeGenerator::beginSwitch):
         * bytecompiler/NodesCodegen.cpp:
         (JSC::BinaryOpNode::emitBytecode):
         (JSC::emitReadModifyAssignment):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         (JSC::DFG::AbstractState::mergeStateAtTail):
         (JSC::DFG::AbstractState::mergeToSuccessors):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::makeSafe):
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
         (JSC::DFG::CFGSimplificationPhase::fixTailOperand):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         * dfg/DFGCapabilities.cpp:
         (JSC::DFG::canHandleOpcodes):
         * dfg/DFGCommon.h:
         (JSC::DFG::useKindToString):
         * dfg/DFGDoubleFormatState.h:
         (JSC::DFG::mergeDoubleFormatStates):
         (JSC::DFG::doubleFormatStateToString):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::blessArrayOperation):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::clobbersWorld):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::valueOfJSConstant):
         (JSC::DFG::Node::successor):
         * dfg/DFGNodeFlags.cpp:
         (JSC::DFG::nodeFlagsAsString):
         * dfg/DFGNodeType.h:
         (JSC::DFG::defaultFlags):
         * dfg/DFGRepatch.h:
         (JSC::DFG::dfgResetGetByID):
         (JSC::DFG::dfgResetPutByID):
         * dfg/DFGSlowPathGenerator.h:
         (JSC::DFG::SlowPathGenerator::call):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
         (JSC::DFG::SpeculativeJIT::silentSpill):
         (JSC::DFG::SpeculativeJIT::silentFill):
         (JSC::DFG::SpeculativeJIT::checkArray):
         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
         (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::bitOp):
         (JSC::DFG::SpeculativeJIT::shiftOp):
         (JSC::DFG::SpeculativeJIT::integerResult):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillDouble):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillInteger):
         (JSC::DFG::SpeculativeJIT::fillDouble):
         (JSC::DFG::SpeculativeJIT::fillJSValue):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         * dfg/DFGValueSource.h:
         (JSC::DFG::ValueSource::valueRecovery):
         * dfg/DFGVariableEvent.cpp:
         (JSC::DFG::VariableEvent::dump):
         * dfg/DFGVariableEventStream.cpp:
         (JSC::DFG::VariableEventStream::reconstruct):
         * heap/BlockAllocator.h:
         (JSC::BlockAllocator::regionSetFor):
         * heap/GCThread.cpp:
         (JSC::GCThread::gcThreadMain):
         * heap/MarkedBlock.cpp:
         (JSC::MarkedBlock::sweepHelper):
         * heap/MarkedBlock.h:
         (JSC::MarkedBlock::isLive):
         * interpreter/CallFrame.h:
         (JSC::ExecState::inlineCallFrame):
         * interpreter/Interpreter.cpp:
         (JSC::getCallerInfo):
         (JSC::getStackFrameCodeType):
         (JSC::Interpreter::execute):
         * jit/ExecutableAllocatorFixedVMPool.cpp:
         (JSC::FixedVMPoolExecutableAllocator::notifyPageIsFree):
         * jit/JIT.cpp:
         (JSC::JIT::privateCompileMainPass):
         (JSC::JIT::privateCompileSlowCases):
         (JSC::JIT::privateCompile):
         * jit/JITArithmetic.cpp:
         (JSC::JIT::emitSlow_op_mod):
         * jit/JITArithmetic32_64.cpp:
         (JSC::JIT::emitBinaryDoubleOp):
         (JSC::JIT::emitSlow_op_mod):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::isDirectPutById):
         * jit/JITStubs.cpp:
         (JSC::getPolymorphicAccessStructureListSlot):
         (JSC::DEFINE_STUB_FUNCTION):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::jitCompileAndSetHeuristics):
         * parser/Lexer.cpp:
         (JSC::::lex):
         * parser/Nodes.h:
         (JSC::ExpressionNode::emitBytecodeInConditionContext):
         * parser/Parser.h:
         (JSC::Parser::getTokenName):
         (JSC::Parser::updateErrorMessageSpecialCase):
         * parser/SyntaxChecker.h:
         (JSC::SyntaxChecker::operatorStackPop):
         * runtime/Arguments.cpp:
         (JSC::Arguments::tearOffForInlineCallFrame):
         * runtime/DatePrototype.cpp:
         (JSC::formatLocaleDate):
         * runtime/Executable.cpp:
         (JSC::samplingDescription):
         * runtime/Executable.h:
         (JSC::ScriptExecutable::unlinkCalls):
         * runtime/Identifier.cpp:
         (JSC):
         * runtime/InternalFunction.cpp:
         (JSC::InternalFunction::getCallData):
         * runtime/JSArray.cpp:
         (JSC::JSArray::push):
         (JSC::JSArray::sort):
         * runtime/JSCell.cpp:
         (JSC::JSCell::defaultValue):
         (JSC::JSCell::getOwnPropertyNames):
         (JSC::JSCell::getOwnNonIndexPropertyNames):
         (JSC::JSCell::className):
         (JSC::JSCell::getPropertyNames):
         (JSC::JSCell::customHasInstance):
         (JSC::JSCell::putDirectVirtual):
         (JSC::JSCell::defineOwnProperty):
         (JSC::JSCell::getOwnPropertyDescriptor):
         * runtime/JSCell.h:
         (JSCell):
         * runtime/JSNameScope.cpp:
         (JSC::JSNameScope::put):
         * runtime/JSObject.cpp:
         (JSC::JSObject::getOwnPropertySlotByIndex):
         (JSC::JSObject::putByIndex):
         (JSC::JSObject::ensureArrayStorageSlow):
         (JSC::JSObject::deletePropertyByIndex):
         (JSC::JSObject::getOwnPropertyNames):
         (JSC::JSObject::putByIndexBeyondVectorLength):
         (JSC::JSObject::putDirectIndexBeyondVectorLength):
         (JSC::JSObject::getOwnPropertyDescriptor):
         * runtime/JSObject.h:
         (JSC::JSObject::canGetIndexQuickly):
         (JSC::JSObject::getIndexQuickly):
         (JSC::JSObject::tryGetIndexQuickly):
         (JSC::JSObject::canSetIndexQuickly):
         (JSC::JSObject::canSetIndexQuicklyForPutDirect):
         (JSC::JSObject::setIndexQuickly):
         (JSC::JSObject::initializeIndex):
         (JSC::JSObject::hasSparseMap):
         (JSC::JSObject::inSparseIndexingMode):
         * runtime/JSScope.cpp:
         (JSC::JSScope::isDynamicScope):
         * runtime/JSSymbolTableObject.cpp:
         (JSC::JSSymbolTableObject::putDirectVirtual):
         * runtime/JSSymbolTableObject.h:
         (JSSymbolTableObject):
         * runtime/LiteralParser.cpp:
         (JSC::::parse):
         * runtime/RegExp.cpp:
         (JSC::RegExp::compile):
         (JSC::RegExp::compileMatchOnly):
         * runtime/StructureTransitionTable.h:
         (JSC::newIndexingType):
         * tools/CodeProfile.cpp:
         (JSC::CodeProfile::sample):
         * yarr/YarrCanonicalizeUCS2.h:
         (JSC::Yarr::getCanonicalPair):
         (JSC::Yarr::areCanonicallyEquivalent):
         * yarr/YarrInterpreter.cpp:
         (JSC::Yarr::Interpreter::matchCharacterClass):
         (JSC::Yarr::Interpreter::matchBackReference):
         (JSC::Yarr::Interpreter::backtrackParenthesesTerminalEnd):
         (JSC::Yarr::Interpreter::matchParentheses):
         (JSC::Yarr::Interpreter::backtrackParentheses):
         (JSC::Yarr::Interpreter::matchDisjunction):
         * yarr/YarrJIT.cpp:
         (JSC::Yarr::YarrGenerator::generateTerm):
         (JSC::Yarr::YarrGenerator::backtrackTerm):
         * yarr/YarrParser.h:
         (JSC::Yarr::Parser::CharacterClassParserDelegate::assertionWordBoundary):
         (JSC::Yarr::Parser::CharacterClassParserDelegate::atomBackReference):
         * yarr/YarrPattern.cpp:
         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):

 2013-01-23  Tony Chang  <tony@chromium.org>

         Unreviewed, set svn:eol-style to CRLF on Windows .sln files.

         * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style.
         * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style.

 2013-01-23  Oliver Hunt  <oliver@apple.com>

         Replace numerous manual CRASH's in JSC with RELEASE_ASSERT
         https://bugs.webkit.org/show_bug.cgi?id=107726

         Reviewed by Filip Pizlo.

         Fairly manual change from if (foo) CRASH(); to RELEASE_ASSERT(!foo);

         * assembler/MacroAssembler.h:
         (JSC::MacroAssembler::branchAdd32):
         (JSC::MacroAssembler::branchMul32):
         * bytecode/CodeBlockHash.cpp:
         (JSC::CodeBlockHash::CodeBlockHash):
         * heap/BlockAllocator.h:
         (JSC::Region::create):
         (JSC::Region::createCustomSize):
         * heap/GCAssertions.h:
         * heap/HandleSet.cpp:
         (JSC::HandleSet::visitStrongHandles):
         (JSC::HandleSet::writeBarrier):
         * heap/HandleSet.h:
         (JSC::HandleSet::allocate):
         * heap/Heap.cpp:
         (JSC::Heap::collect):
         * heap/SlotVisitor.cpp:
         (JSC::SlotVisitor::validate):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::execute):
         * jit/ExecutableAllocator.cpp:
         (JSC::DemandExecutableAllocator::allocateNewSpace):
         (JSC::ExecutableAllocator::allocate):
         * jit/ExecutableAllocator.h:
         (JSC::roundUpAllocationSize):
         * jit/ExecutableAllocatorFixedVMPool.cpp:
         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
         (JSC::ExecutableAllocator::allocate):
         * runtime/ButterflyInlines.h:
         (JSC::Butterfly::createUninitialized):
         * runtime/Completion.cpp:
         (JSC::evaluate):
         * runtime/JSArray.h:
         (JSC::constructArray):
         * runtime/JSGlobalObject.cpp:
         (JSC::slowValidateCell):
         * runtime/JSObject.cpp:
         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
         (JSC::JSObject::createArrayStorage):
         * tools/TieredMMapArray.h:
         (JSC::TieredMMapArray::append):
         * yarr/YarrInterpreter.cpp:
         (JSC::Yarr::Interpreter::allocDisjunctionContext):
         (JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext):
         (JSC::Yarr::Interpreter::InputStream::readChecked):
         (JSC::Yarr::Interpreter::InputStream::uncheckInput):
         (JSC::Yarr::Interpreter::InputStream::atEnd):
         (JSC::Yarr::Interpreter::interpret):

 2013-01-22  Filip Pizlo  <fpizlo@apple.com>

         Convert CSE phase to not rely too much on NodeIndex
         https://bugs.webkit.org/show_bug.cgi?id=107616

         Reviewed by Geoffrey Garen.

         - Instead of looping over the graph (which assumes that you can simply loop over all
           nodes without considering blocks first) to reset node.replacement, do that in the
           loop that sets up relevantToOSR, just before running CSE on the block.

         - Instead of having a relevantToOSR bitvector indexed by NodeIndex, made
           NodeRelevantToOSR be a NodeFlag. We had exactly one bit left in NodeFlags, so I did
           some reshuffling to fit it in.

         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::CSEPhase):
         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::CSEPhase::performNodeCSE):
         (JSC::DFG::CSEPhase::performBlockCSE):
         (CSEPhase):
         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGNodeType.h:
         (DFG):

 2013-01-21  Kentaro Hara  <haraken@chromium.org>

         Implement UIEvent constructor
         https://bugs.webkit.org/show_bug.cgi?id=107430

         Reviewed by Adam Barth.

         Editor's draft: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm

         UIEvent constructor is implemented under a DOM4_EVENTS_CONSTRUCTOR flag,
         which is enabled on Safari and Chromium for now.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-22  Roger Fong  <roger_fong@apple.com>

         Unreviewed VS2010 build fix following r140259.

         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

 2013-01-22  Roger Fong  <roger_fong@apple.com>

         JavaScriptCore property sheets, project files and modified build scripts.
         https://bugs.webkit.org/show_bug.cgi?id=106987

         Reviewed by Brent Fulgham.

         * JavaScriptCore.vcxproj: Added.
         * JavaScriptCore.vcxproj/JavaScriptCore.resources: Added.
         * JavaScriptCore.vcxproj/JavaScriptCore.resources/Info.plist: Added.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added.
         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreCF.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreExports.def: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: Added.
         * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: Added.
         * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd: Added.
         * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: Added.
         * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.make: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Added.
         * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Added.
         * JavaScriptCore.vcxproj/build-generated-files.sh: Added.
         * JavaScriptCore.vcxproj/copy-files.cmd: Added.
         * JavaScriptCore.vcxproj/jsc: Added.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Added.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Added.
         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.user: Added.
         * JavaScriptCore.vcxproj/jsc/jscCommon.props: Added.
         * JavaScriptCore.vcxproj/jsc/jscDebug.props: Added.
         * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Added.
         * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Added.
         * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Added.
         * JavaScriptCore.vcxproj/jsc/jscRelease.props: Added.
         * config.h:

 2013-01-22  Joseph Pecoraro  <pecoraro@apple.com>

         [Mac] Enable Page Visibility (PAGE_VISIBILITY_API)
         https://bugs.webkit.org/show_bug.cgi?id=107230

         Reviewed by David Kilzer.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-22  Tobias Netzel  <tobias.netzel@googlemail.com>

         Yarr JIT isn't big endian compatible
         https://bugs.webkit.org/show_bug.cgi?id=102897

         Reviewed by Oliver Hunt.

         This patch was tested in the current mozilla codebase only and has passed the regexp tests there.

         * yarr/YarrJIT.cpp:
         (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):

 2013-01-22  David Kilzer  <ddkilzer@apple.com>

         Fix DateMath.cpp to compile with -Wshorten-64-to-32
         <http://webkit.org/b/107503>

         Reviewed by Darin Adler.

         * runtime/JSDateMath.cpp:
         (JSC::parseDateFromNullTerminatedCharacters): Remove unneeded
         static_cast<int>().

 2013-01-22  Tim Horton  <timothy_horton@apple.com>

         PDFPlugin: Build PDFPlugin everywhere, enable at runtime
         https://bugs.webkit.org/show_bug.cgi?id=107117

         Reviewed by Alexey Proskuryakov.

         Since PDFLayerController SPI is all forward-declared, the plugin should build
         on all Mac platforms, and can be enabled at runtime.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-21  Justin Schuh  <jschuh@chromium.org>

         [CHROMIUM] Suppress c4267 build warnings for Win64 targets
         https://bugs.webkit.org/show_bug.cgi?id=107499

         Reviewed by Abhishek Arya.

         * JavaScriptCore.gyp/JavaScriptCore.gyp:

 2013-01-21  Dirk Schulze  <dschulze@adobe.com>

         Add build flag for Canvas's Path object (disabled by default)
         https://bugs.webkit.org/show_bug.cgi?id=107473

         Reviewed by Dean Jackson.

         Add CANVAS_PATH build flag to build systems.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-20  Geoffrey Garen  <ggaren@apple.com>

         Weak GC maps should be easier to use
         https://bugs.webkit.org/show_bug.cgi?id=107312

         Reviewed by Sam Weinig.

         Follow-up fix.

         * runtime/PrototypeMap.cpp:
         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Restored this
         ASSERT, which was disabled because of a bug in WeakGCMap.

         * runtime/WeakGCMap.h:
         (JSC::WeakGCMap::add): We can't pass our passed-in value to add() because
         a PassWeak() clears itself when passed to another function. So, we pass
         nullptr instead, and fix things up afterwards.

 2013-01-20  Geoffrey Garen  <ggaren@apple.com>

         Unreviewed.

         Temporarily disabling this ASSERT to get the bots green
         while I investigate a fix.

         * runtime/PrototypeMap.cpp:
         (JSC::PrototypeMap::emptyObjectStructureForPrototype):

 2013-01-20  Filip Pizlo  <fpizlo@apple.com>

         Inserting a node into the DFG graph should not require five lines of code
         https://bugs.webkit.org/show_bug.cgi?id=107381

         Reviewed by Sam Weinig.

         This adds fairly comprehensive support for inserting a node into a DFG graph in one
         method call. A common example of this is:

         m_insertionSet.insertNode(indexInBlock, DontRefChildren, DontRefNode, SpecNone, ForceOSRExit, codeOrigin);

         The arguments to insert() specify what reference counting you need to have happen
         (RefChildren => recursively refs all children, RefNode => non-recursively refs the node
         that was created), the prediction to set (SpecNone is a common default), followed by
         the arguments to the Node() constructor. InsertionSet::insertNode() and similar methods
         (Graph::addNode() and BasicBlock::appendNode()) all use a common variadic template
         function macro from DFGVariadicFunction.h. Also, all of these methods will automatically
         non-recursively ref() the node being created if the flags say NodeMustGenerate.

         In all, this new mechanism retains the flexibility of the old approach (you get to
         manage ref counts yourself, albeit in less code) while ensuring that most code that adds
         nodes to the graph now needs less code to do it.

         In the future, we should revisit the reference counting methodology in the DFG: we could
         do like most compilers and get rid of it entirely, or we could make it automatic. This
         patch doesn't attempt to make any such major changes, and only seeks to simplify the
         technique we were already using (manual ref counting).

         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * bytecode/Operands.h:
         (JSC::dumpOperands):
         * dfg/DFGAdjacencyList.h:
         (AdjacencyList):
         (JSC::DFG::AdjacencyList::kind):
         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         * dfg/DFGBasicBlock.h:
         (DFG):
         (BasicBlock):
         * dfg/DFGBasicBlockInlines.h: Added.
         (DFG):
         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::run):
         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
         * dfg/DFGCommon.h:
         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase):
         (JSC::DFG::ConstantFoldingPhase::foldConstants):
         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
         (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
         (ConstantFoldingPhase):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::FixupPhase):
         (JSC::DFG::FixupPhase::fixupBlock):
         (JSC::DFG::FixupPhase::fixupNode):
         (FixupPhase):
         (JSC::DFG::FixupPhase::checkArray):
         (JSC::DFG::FixupPhase::blessArrayOperation):
         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::ref):
         (Graph):
         * dfg/DFGInsertionSet.h:
         (DFG):
         (JSC::DFG::Insertion::Insertion):
         (JSC::DFG::Insertion::element):
         (Insertion):
         (JSC::DFG::InsertionSet::InsertionSet):
         (JSC::DFG::InsertionSet::insert):
         (InsertionSet):
         (JSC::DFG::InsertionSet::execute):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::Node):
         (Node):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         * dfg/DFGVariadicFunction.h: Added.

 2013-01-19  Geoffrey Garen  <ggaren@apple.com>

         Track inheritance structures in a side table, instead of using a private
         name in each prototype
         https://bugs.webkit.org/show_bug.cgi?id=107378

         Reviewed by Sam Weinig and Phil Pizlo.

         This is a step toward object size inference.

         Using a side table frees us to use a more complex key (a pair of
         prototype and expected inline capacity).

         It also avoids ruining inline caches for prototypes. (Adding a new private
         name for a new inline capacity would change the prototype's structure,
         possibly firing watchpoints, making inline caches go polymorphic, and
         generally causing us to have a bad time.)

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri: Buildage.

         * runtime/ArrayPrototype.cpp:
         (JSC::ArrayPrototype::finishCreation): Updated to use new side table API.

         * runtime/JSFunction.cpp:
         (JSC::JSFunction::cacheInheritorID): Updated to use new side table API.

         (JSC::JSFunction::visitChildren): Fixed a long-standing bug where JSFunction
         forgot to visit one of its data members (m_cachedInheritorID). This
         wasn't a user-visible problem before because JSFunction would always
         visit its .prototype property, which visited its m_cachedInheritorID.
         But now, function.prototype only weakly owns function.m_cachedInheritorID.

         * runtime/JSGlobalData.h:
         (JSGlobalData): Added the map, taking care to make sure that its
         destructor would run after the heap destructor.

         * runtime/JSGlobalObject.cpp:
         (JSC::JSGlobalObject::reset): Updated to use new side table API.

         * runtime/JSObject.cpp:
         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
         (JSC::JSObject::setPrototype):
         * runtime/JSObject.h:
         (JSObject): Updated to use new side table API, and removed lots of code
         that used to manage the per-object private name.

         * runtime/JSProxy.cpp:
         (JSC::JSProxy::setTarget):
         * runtime/ObjectConstructor.cpp:
         (JSC::objectConstructorCreate):
         * runtime/ObjectPrototype.cpp:
         (JSC::ObjectPrototype::finishCreation): Updated to use new side table API.

         * runtime/PrototypeMap.cpp: Added.
         (JSC):
         (JSC::PrototypeMap::addPrototype):
         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
         * runtime/PrototypeMap.h: Added.
         (PrototypeMap):
         (JSC::PrototypeMap::isPrototype):
         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): New side table.
         This is a simple weak map, mapping an object to the structure you should
         use when inheriting from that object. (In future, inline capacity will
         be a part of the mapping.)

         I used two maps to preserve existing behavior that allowed us to speculate
         about an object becoming a prototype, even if it wasn't one at the moment.
         However, I suspect that behavior can be removed without harm.

         * runtime/WeakGCMap.h:
         (JSC::WeakGCMap::contains):
         (WeakGCMap): I would rate myself a 6 / 10 in C++.

 2013-01-18  Dan Bernstein  <mitz@apple.com>

         Removed duplicate references to two headers in the project files.

         Rubber-stamped by Mark Rowe.

         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-01-18  Michael Saboff  <msaboff@apple.com>

         Unreviewed build fix for building JSC with DFG_ENABLE_DEBUG_PROPAGATION_VERBOSE enabled in DFGCommon.h.
         Fixes the case where the argument node in fixupNode is freed due to the Vector storage being reallocated.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):

 2013-01-18  Michael Saboff  <msaboff@apple.com>

         Unreviewed build fix for release builds when DFG_ENABLE_DEBUG_PROPAGATION_VERBOSE is set to 1 in DFGCommon.h.

         * dfg/DFGCFAPhase.cpp: Added #include "Operations.h"

 2013-01-18  Michael Saboff  <msaboff@apple.com>

         Change set r140201 broke editing/selection/move-by-word-visually-multi-line.html
         https://bugs.webkit.org/show_bug.cgi?id=107340

         Reviewed by Filip Pizlo.

         Due to the change landed in r140201, more nodes might end up
         generating Int32ToDouble nodes.  Therefore, changed the JSVALUE64
         constant path of compileInt32ToDouble() to use the more
         restrictive isInt32Constant() check on the input.  This check was
         the same as the existing ASSERT() so the ASSERT was eliminated.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):

 2013-01-18  Viatcheslav Ostapenko  <sl.ostapenko@samsung.com>

         Weak GC maps should be easier to use
         https://bugs.webkit.org/show_bug.cgi?id=107312

         Reviewed by Ryosuke Niwa.

         Build fix for linux platforms after r140194.

         * runtime/WeakGCMap.h:
         (WeakGCMap):

 2013-01-18  Michael Saboff  <msaboff@apple.com>

         Harden ArithDiv of integers fix-up by inserting Int32ToDouble node directly
         https://bugs.webkit.org/show_bug.cgi?id=107321

         Reviewed by  Filip Pizlo.

         Split out the Int32ToDouble node insertion from fixDoubleEdge() and used it directly when we're fixing up
         an ArithDiv node with integer inputs and output for platforms that don't have integer division.
         Since we are checking that our inputs should be ints, we can just insert the Int32ToDouble node
         without any further checks.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::fixDoubleEdge):
         (FixupPhase):
         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):

 2013-01-18  Michael Saboff  <msaboff@apple.com>

         Fix up of ArithDiv nodes for non-x86 CPUs is broken
         https://bugs.webkit.org/show_bug.cgi?id=107309

         Reviewed by  Filip Pizlo.

         Changed the logic so that we insert an Int32ToDouble node when the existing edge is not SpecDouble.

         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixDoubleEdge):

 2013-01-18  Dan Bernstein  <mitz@apple.com>

         Tried to fix the build after r140194.

         * API/JSWrapperMap.mm:
         (-[JSWrapperMap wrapperForObject:]):

 2013-01-18  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Update documentation for JSValue and JSContext
         https://bugs.webkit.org/show_bug.cgi?id=107313

         Reviewed by Geoffrey Garen.

         After changing the semantics of object lifetime we need to update the API documentation to reflect the new semantics.

         * API/APIJSValue.h:
         * API/JSContext.h:

 2013-01-18  Balazs Kilvady  <kilvadyb@homejinni.com>

         r134080 causes heap problem on linux systems where PAGESIZE != 4096
         https://bugs.webkit.org/show_bug.cgi?id=102828

         Reviewed by Mark Hahnenberg.

         Make MarkStackSegment::blockSize as the capacity of segments of a MarkStackArray.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
         * heap/MarkStack.cpp:
         (JSC):
         (JSC::MarkStackArray::MarkStackArray):
         (JSC::MarkStackArray::expand):
         (JSC::MarkStackArray::donateSomeCellsTo):
         (JSC::MarkStackArray::stealSomeCellsFrom):
         * heap/MarkStack.h:
         (JSC::MarkStackSegment::data):
         (CapacityFromSize):
         (MarkStackArray):
         * heap/MarkStackInlines.h:
         (JSC::MarkStackArray::setTopForFullSegment):
         (JSC::MarkStackArray::append):
         (JSC::MarkStackArray::isEmpty):
         (JSC::MarkStackArray::size):
         * runtime/Options.h:
         (JSC):

 2013-01-18  Geoffrey Garen  <ggaren@apple.com>

         Weak GC maps should be easier to use
         https://bugs.webkit.org/show_bug.cgi?id=107312

         Reviewed by Sam Weinig.

         This patch changes WeakGCMap to not use a WeakImpl finalizer to remove
         items from the map, and to instead have the map automatically remove
         stale items itself upon insertion. This has a few advantages:

         (1) WeakGCMap is now compatible with all the specializations you would
         use for HashMap.

         (2) There's no need for clients to write special finalization munging
         functions.

         (3) Clients can specify custom value finalizers if they like.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Def!

         * API/JSWeakObjectMapRefPrivate.cpp: Setter no longer requires a global
         data, since we've reduced interdependency.

         * heap/Handle.h: No more need to forward declare, since we've reduced
         interdependency.

         * heap/Weak.h:
         (Weak): Use explicit so we can assign directly to a weak map iterator
         without ambiguity between Weak<T> and PassWeak<T>.

         * runtime/Structure.cpp:
         (JSC::StructureTransitionTable::add): See above.

         * runtime/Structure.h:
         (JSC):
         * runtime/StructureTransitionTable.h:
         (StructureTransitionTable): Bad code goes away, programmer happy.

         * runtime/WeakGCMap.h:
         (JSC):
         (WeakGCMap):
         (JSC::WeakGCMap::WeakGCMap):
         (JSC::WeakGCMap::set):
         (JSC::WeakGCMap::add):
         (JSC::WeakGCMap::find):
         (JSC::WeakGCMap::contains):
         (JSC::WeakGCMap::gcMap):
         (JSC::WeakGCMap::gcMapIfNeeded): Inherit from HashMap and override any
         function that might observe a Weak<T> that has died, just enough to
         make such items appear as if they are not in the table.

 2013-01-18  Michael Saboff  <msaboff@apple.com>

         Refactor isPowerOf2() and add getLSBSet()
         https://bugs.webkit.org/show_bug.cgi?id=107306

         Reviewed by Filip Pizlo.

         Moved implementation of isPowerOf2() to new hasOneBitSet() in wtf/MathExtras.h.

         * runtime/PropertyMapHashTable.h:
         (JSC::isPowerOf2):

 2013-01-17  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Clean up JSValue.mm
         https://bugs.webkit.org/show_bug.cgi?id=107163

         Reviewed by Darin Adler.

         m_context is no longer weak, so there is now a lot of dead code in in JSValue.mm, and a wasted message send
         on every API call.  In the head of just about every method in JSValue.mm we're doing:

         JSContext *context = [self context];
         if (!context)
             return nil;

         This is getting a retained copy of the context, which is no longer necessary now m_context is no longer weak.
         We can just delete all these lines from all functions doing this, and where they were referring to the local
         variable 'context', instead we can just access m_context directly.

         Since we're already going to be modifying most of JSValue.mm, we'll also do the following:

         1) context @property is no longer weak – the context property is declared as:

             @property(readonly, weak) JSContext *context;

         This is really only informative (since we're not presently synthesizing the ivar), but it is now misleading.
         We should change it to:

             @property(readonly, retain) JSContext *context;

         2) the JSContext ivar and accessor can be automatically generated.  Since we're no longer doing anything
         special with m_context, we can just let the compiler handle the ivar for us.  We'll delete:

             JSContext *m_context;

         and:

             - (JSContext *)context
             {
                 return m_context;

             }

         and find&replace "m_context" to "_context" in JSValue.mm.

         * API/APIJSValue.h:
         * API/JSValue.mm:
         (-[JSValue toObject]):
         (-[JSValue toBool]):
         (-[JSValue toDouble]):
         (-[JSValue toNumber]):
         (-[JSValue toString]):
         (-[JSValue toDate]):
         (-[JSValue toArray]):
         (-[JSValue toDictionary]):
         (-[JSValue valueForProperty:]):
         (-[JSValue setValue:forProperty:]):
         (-[JSValue deleteProperty:]):
         (-[JSValue hasProperty:]):
         (-[JSValue defineProperty:descriptor:]):
         (-[JSValue valueAtIndex:]):
         (-[JSValue setValue:atIndex:]):
         (-[JSValue isUndefined]):
         (-[JSValue isNull]):
         (-[JSValue isBoolean]):
         (-[JSValue isNumber]):
         (-[JSValue isString]):
         (-[JSValue isObject]):
         (-[JSValue isEqualToObject:]):
         (-[JSValue isEqualWithTypeCoercionToObject:]):
         (-[JSValue isInstanceOf:]):
         (-[JSValue callWithArguments:]):
         (-[JSValue constructWithArguments:]):
         (-[JSValue invokeMethod:withArguments:]):
         (-[JSValue objectForKeyedSubscript:]):
         (-[JSValue setObject:forKeyedSubscript:]):
         (-[JSValue initWithValue:inContext:]):
         (-[JSValue dealloc]):
         (-[JSValue description]):

 2013-01-17  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C API: Clean up JSValue
         https://bugs.webkit.org/show_bug.cgi?id=107156

         Reviewed by Oliver Hunt.

         JSContext m_protectCounts, protect, unprotect are all now unnecessary overhead, and should all be removed.
         These exist to handle the context going away before the value does; the context needs to be able to unprotect
         values early.  Since the value is now keeping the context alive there is no longer any danger of this happening;
         instead we should just protect/unprotect the value in JSValue's init/dealloc methods.

         * API/JSContext.mm:
         (-[JSContext dealloc]):
         * API/JSContextInternal.h:
         * API/JSValue.mm:
         (-[JSValue initWithValue:inContext:]):
         (-[JSValue dealloc]):

 2013-01-17  Filip Pizlo  <fpizlo@apple.com>

         DFG Node::ref() and Node::deref() should not return bool, and should have postfixRef variants
         https://bugs.webkit.org/show_bug.cgi?id=107147

         Reviewed by Mark Hahnenberg.

         This small refactoring will enable a world where ref() returns Node*, which is useful for
         https://bugs.webkit.org/show_bug.cgi?id=106868.  Also, while this refactoring does lead to
         slightly less terse code, it's also slightly more self-explanatory.  I could never quite
         remember what the meaning of the bool return from ref() and deref() was.

         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::collectGarbage):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::ref):
         (JSC::DFG::Graph::deref):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::ref):
         (Node):
         (JSC::DFG::Node::postfixRef):
         (JSC::DFG::Node::deref):
         (JSC::DFG::Node::postfixDeref):

 2013-01-17  Alexey Proskuryakov  <ap@apple.com>

         Added svn:ignore=*.pyc, so that ud_opcode.pyc and ud_optable.pyc don't show up
         in svn stat.

         * disassembler/udis86: Added property svn:ignore.

 2013-01-16  Filip Pizlo  <fpizlo@apple.com>

         DFG 32_64 backend doesn't check for hasArrayStorage() in NewArrayWithSize
         https://bugs.webkit.org/show_bug.cgi?id=107081

         Reviewed by Michael Saboff.

         This bug led to the 32_64 backend emitting contiguous allocation code to allocate
         ArrayStorage arrays. This then led to all manner of heap corruption, since
         subsequent array accesses would be accessing the contiguous array "as if" it was
         an arraystorage array.

         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-01-16  Jonathan Liu  <net147@gmail.com>

         Add missing sys/mman.h include on Mac
         https://bugs.webkit.org/show_bug.cgi?id=98089

         Reviewed by Darin Adler.

         The madvise function and MADV_FREE constant require sys/mman.h.

         * jit/ExecutableAllocatorFixedVMPool.cpp:

 2013-01-15  Michael Saboff  <msaboff@apple.com>

         DFG X86: division in the used-as-int case doesn't correctly check for -2^31/-1
         https://bugs.webkit.org/show_bug.cgi?id=106978

         Reviewed by Filip Pizlo.

         Changed the numerator equal to -2^31 check to just return if we expect an integer
         result, since the check is after we have determined that the denominator is -1.
         The int result of -2^31 / -1 is -2^31, so just return the numerator as the result.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86):

 2013-01-15  Levi Weintraub  <leviw@chromium.org>

         Unreviewed, rolling out r139792.
         http://trac.webkit.org/changeset/139792
         https://bugs.webkit.org/show_bug.cgi?id=106970

         Broke the windows build.

         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.

 2013-01-15  Pratik Solanki  <psolanki@apple.com>

         Use MADV_FREE_REUSABLE to return JIT memory to OS
         https://bugs.webkit.org/show_bug.cgi?id=106830
         <rdar://problem/11437701>

         Reviewed by Geoffrey Garen.

         Use MADV_FREE_REUSABLE to return JIT memory on OSes that have the underlying madvise bug
         fixed.

         * jit/ExecutableAllocatorFixedVMPool.cpp:
         (JSC::FixedVMPoolExecutableAllocator::notifyPageIsFree):

 2013-01-15  Levi Weintraub  <leviw@chromium.org>

         Unreviewed, rolling out r139790.
         http://trac.webkit.org/changeset/139790
         https://bugs.webkit.org/show_bug.cgi?id=106948

         The patch is failing its own test.

         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.

 2013-01-15  Zan Dobersek  <zandobersek@gmail.com>

         [Autotools] Unify JavaScriptCore sources list, regardless of target OS
         https://bugs.webkit.org/show_bug.cgi?id=106007

         Reviewed by Gustavo Noronha Silva.

         Include the Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp target
         in the general sources list as it is guarded by the ENABLE_EXECUTABLE_ALLOCATOR_FIXED
         feature define. This define is only used on 64-bit architecture and indirectly depends
         on enabling either JIT or YARR JIT feature. Both of these defines are disabled on
         Windows OS when using 64-bit architecture so there's no need to add this target to
         sources only when the target OS is Windows.

         * GNUmakefile.list.am:

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         DFG should not forget that it had proved something to be a constant during a merge just because it's merging against the empty value
         https://bugs.webkit.org/show_bug.cgi?id=106727

         Reviewed by Oliver Hunt.

         The problem was this statement:

         if (m_value != other.m_value)
             m_value = JSValue();

         This is well-intentioned, in the sense that if we want our abstract value (i.e. this) to become the superset of the other
         abstract value, and the two abstract values have proven different constants, then our abstract value should rescind its
         claim that it has been proven to be constant. But this misses the special case that if the other abstract value is
         completely clear (meaning that it wishes to contribute zero information and so the superset operation shouldn't change
         this), it will have a clear m_value. So, the code prior to this patch would rescind the constant proof even though it
         didn't have to.

         This comes up rarely and I don't believe it will be a performance win, but it is good to have the CFA been consistently
         precise as often as possible.

         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::merge):

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         Python implementation reports "MemoryError" instead of doing things
         https://bugs.webkit.org/show_bug.cgi?id=106690

         Reviewed by Oliver Hunt.

         The bug was that the CFA was assuming that a variable is dead at the end of a basic block and hence doesn't need to
         be merged to the next block if the last mention of the variable was dead. This is almost correct, except that it
         doesn't work if the last mention is a GetLocal - the GetLocal itself may be dead, but that doesn't mean that the
         variable is dead - it may still be live. The appropriate thing to do is to look at the GetLocal's Phi. If the
         variable is used in the next block then the next block will have a reference to the last mention in our block unless
         that last mention is a GetLocal, in which case it will link to the Phi. Doing it this way captures everything that
         the CFA wants: if the last use is a live GetLocal then the CFA needs to consider the GetLocal itself for possible
         refinements to the proof of the value in the variable, but if the GetLocal is dead, then this must mean that the
         variable is not mentioned in the block but may still be "passed through" it, which is what the Phi will tell us.
         Note that it is not possible for the GetLocal to refer to anything other than a Phi, and it is also not possible
         for the last mention of a variable to be a dead GetLocal while there are other mentions that aren't dead - if
         there had been SetLocals or GetLocals prior to the dead one then the dead one wouldn't have been emitted by the
         parser.

         This also fixes a similar bug in the handling of captured variables. If a variable is captured, then it doesn't
         matter if the last mention is dead, or not. Either way, we already know that a captured variable will be live in
         the next block, so we must merge it no matter what.

         Finally, this change makes the output of Operands dumping a bit more verbose: it now prints the variable name next
         to each variable's dump. I've often found the lack of this information confusing particularly for operand dumps
         that involve a lot of variables.

         * bytecode/Operands.h:
         (JSC::dumpOperands):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::mergeStateAtTail):

 2013-01-14  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Fix vcproj file. Missing file tag after http://trac.webkit.org/changeset/139541.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:

 2013-01-13  Filip Pizlo  <fpizlo@apple.com>

         DFG phases that store per-node information should store it in Node itself rather than using a secondary vector
         https://bugs.webkit.org/show_bug.cgi?id=106753

         Reviewed by Geoffrey Garen.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::AbstractState):
         (JSC::DFG::AbstractState::beginBasicBlock):
         (JSC::DFG::AbstractState::dump):
         * dfg/DFGAbstractState.h:
         (JSC::DFG::AbstractState::forNode):
         (AbstractState):
         * dfg/DFGCFGSimplificationPhase.cpp:
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::CSEPhase):
         (JSC::DFG::CSEPhase::performSubstitution):
         (JSC::DFG::CSEPhase::setReplacement):
         (CSEPhase):
         * dfg/DFGNode.h:
         (Node):

 2013-01-12  Tim Horton  <timothy_horton@apple.com>

         Unreviewed build fix.

         * API/JSBlockAdaptor.mm:
         * API/JSContext.mm:
         * API/JSValue.mm:

 2013-01-12  Csaba Osztrogonác  <ossy@webkit.org>

         Unreviewed 64 bit buildfix after r139496.

         * dfg/DFGOperations.cpp:

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, speculative build fix.

         * API/JSWrapperMap.mm:

 2013-01-10  Filip Pizlo  <fpizlo@apple.com>

         JITThunks should not compile only because of luck
         https://bugs.webkit.org/show_bug.cgi?id=105696

         Rubber stamped by Sam Weinig and Geoffrey Garen.

         This patch was supposed to just move JITThunks into its own file. But then I
         realized that there is a horrible circular dependency chain between JSCell,
         JSGlobalData, CallFrame, and Weak, which only works because of magical include
         order in JITStubs.h, and the fact that JSGlobalData.h includes JITStubs.h
         before it includes JSCell or JSValue.

         I first tried to just get JITThunks.h to just magically do the same pointless
         includes that JITStubs.h had, but then I decided to actually fix the underflying
         problem, which was that JSCell needed CallFrame, CallFrame needed JSGlobalData,
         JSGlobalData needed JITThunks, JITThunks needed Weak, and Weak needed JSCell.
         Now, all of JSCell's outgoing dependencies are placed in JSCellInlines.h. This
         also gave me an opportunity to move JSValue inline methods from JSCell.h into
         JSValueInlines.h. But to make this really work, I needed to remove includes of
         *Inlines.h from other headers (CodeBlock.h for example included JSValueInlines.h,
         which defeats the whole entire purpose of having an Inlines.h file), and I needed
         to add includes of *Inlines.h into a bunch of .cpp files. I did this mostly by
         having .cpp files include Operations.h. In future, if you're adding a .cpp file
         to JSC, you'll almost certainly have to include Operations.h unless you enjoy
         link errors.

         * API/JSBase.cpp:
         * API/JSCallbackConstructor.cpp:
         * API/JSCallbackFunction.cpp:
         * API/JSCallbackObject.cpp:
         * API/JSClassRef.cpp:
         * API/JSContextRef.cpp:
         * API/JSObjectRef.cpp:
         * API/JSScriptRef.cpp:
         * API/JSWeakObjectMapRefPrivate.cpp:
         * JSCTypedArrayStubs.h:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * bytecode/ArrayAllocationProfile.cpp:
         * bytecode/CodeBlock.cpp:
         * bytecode/GetByIdStatus.cpp:
         * bytecode/LazyOperandValueProfile.cpp:
         * bytecode/ResolveGlobalStatus.cpp:
         * bytecode/SpeculatedType.cpp:
         * bytecode/UnlinkedCodeBlock.cpp:
         * bytecompiler/BytecodeGenerator.cpp:
         * debugger/Debugger.cpp:
         * debugger/DebuggerActivation.cpp:
         * debugger/DebuggerCallFrame.cpp:
         * dfg/DFGArgumentsSimplificationPhase.cpp:
         * dfg/DFGArrayMode.cpp:
         * dfg/DFGByteCodeParser.cpp:
         * dfg/DFGConstantFoldingPhase.cpp:
         * dfg/DFGDriver.cpp:
         * dfg/DFGFixupPhase.cpp:
         * dfg/DFGGraph.cpp:
         * dfg/DFGJITCompiler.cpp:
         * dfg/DFGOSREntry.cpp:
         * dfg/DFGOSRExitCompiler.cpp:
         * dfg/DFGOSRExitCompiler32_64.cpp:
         * dfg/DFGOSRExitCompiler64.cpp:
         * dfg/DFGPredictionPropagationPhase.cpp:
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
         (DFG):
         (JSC::DFG::SpeculativeJIT::silentSavePlanForFPR):
         (JSC::DFG::SpeculativeJIT::silentSpill):
         (JSC::DFG::SpeculativeJIT::silentFill):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         * dfg/DFGSpeculativeJIT64.cpp:
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         * dfg/DFGVariableEventStream.cpp:
         * heap/CopiedBlock.h:
         * heap/CopiedSpace.cpp:
         * heap/HandleSet.cpp:
         * heap/Heap.cpp:
         * heap/HeapStatistics.cpp:
         * heap/SlotVisitor.cpp:
         * heap/WeakBlock.cpp:
         * interpreter/CallFrame.cpp:
         * interpreter/CallFrame.h:
         * jit/ClosureCallStubRoutine.cpp:
         * jit/GCAwareJITStubRoutine.cpp:
         * jit/JIT.cpp:
         * jit/JITArithmetic.cpp:
         * jit/JITArithmetic32_64.cpp:
         * jit/JITCall.cpp:
         * jit/JITCall32_64.cpp:
         * jit/JITCode.h:
         * jit/JITExceptions.cpp:
         * jit/JITStubs.h:
         * jit/JITThunks.h:
         * jsc.cpp:
         * llint/LLIntExceptions.cpp:
         * profiler/LegacyProfiler.cpp:
         * profiler/ProfileGenerator.cpp:
         * profiler/ProfilerBytecode.cpp:
         * profiler/ProfilerBytecodeSequence.cpp:
         * profiler/ProfilerBytecodes.cpp:
         * profiler/ProfilerCompilation.cpp:
         * profiler/ProfilerCompiledBytecode.cpp:
         * profiler/ProfilerDatabase.cpp:
         * profiler/ProfilerOSRExit.cpp:
         * profiler/ProfilerOSRExitSite.cpp:
         * profiler/ProfilerOrigin.cpp:
         * profiler/ProfilerOriginStack.cpp:
         * profiler/ProfilerProfiledBytecodes.cpp:
         * runtime/ArgList.cpp:
         * runtime/Arguments.cpp:
         * runtime/ArrayConstructor.cpp:
         * runtime/BooleanConstructor.cpp:
         * runtime/BooleanObject.cpp:
         * runtime/BooleanPrototype.cpp:
         * runtime/CallData.cpp:
         * runtime/CodeCache.cpp:
         * runtime/Completion.cpp:
         * runtime/ConstructData.cpp:
         * runtime/DateConstructor.cpp:
         * runtime/DateInstance.cpp:
         * runtime/DatePrototype.cpp:
         * runtime/Error.cpp:
         * runtime/ErrorConstructor.cpp:
         * runtime/ErrorInstance.cpp:
         * runtime/ErrorPrototype.cpp:
         * runtime/ExceptionHelpers.cpp:
         * runtime/Executable.cpp:
         * runtime/FunctionConstructor.cpp:
         * runtime/FunctionPrototype.cpp:
         * runtime/GetterSetter.cpp:
         * runtime/Identifier.cpp:
         * runtime/InternalFunction.cpp:
         * runtime/JSActivation.cpp:
         * runtime/JSBoundFunction.cpp:
         * runtime/JSCell.cpp:
         * runtime/JSCell.h:
         (JSC):
         * runtime/JSCellInlines.h: Added.
         (JSC):
         (JSC::JSCell::JSCell):
         (JSC::JSCell::finishCreation):
         (JSC::JSCell::structure):
         (JSC::JSCell::visitChildren):
         (JSC::allocateCell):
         (JSC::isZapped):
         (JSC::JSCell::isObject):
         (JSC::JSCell::isString):
         (JSC::JSCell::isGetterSetter):
         (JSC::JSCell::isProxy):
         (JSC::JSCell::isAPIValueWrapper):
         (JSC::JSCell::setStructure):
         (JSC::JSCell::methodTable):
         (JSC::JSCell::inherits):
         (JSC::JSCell::fastGetOwnPropertySlot):
         (JSC::JSCell::fastGetOwnProperty):
         (JSC::JSCell::toBoolean):
         * runtime/JSDateMath.cpp:
         * runtime/JSFunction.cpp:
         * runtime/JSFunction.h:
         (JSC):
         * runtime/JSGlobalData.h:
         (JSC):
         (JSGlobalData):
         * runtime/JSGlobalObject.cpp:
         * runtime/JSGlobalObjectFunctions.cpp:
         * runtime/JSLock.cpp:
         * runtime/JSNameScope.cpp:
         * runtime/JSNotAnObject.cpp:
         * runtime/JSONObject.cpp:
         * runtime/JSObject.h:
         (JSC):
         * runtime/JSProxy.cpp:
         * runtime/JSScope.cpp:
         * runtime/JSSegmentedVariableObject.cpp:
         * runtime/JSString.h:
         (JSC):
         * runtime/JSStringJoiner.cpp:
         * runtime/JSSymbolTableObject.cpp:
         * runtime/JSValue.cpp:
         * runtime/JSValueInlines.h:
         (JSC::JSValue::toInt32):
         (JSC::JSValue::toUInt32):
         (JSC):
         (JSC::JSValue::isUInt32):
         (JSC::JSValue::asUInt32):
         (JSC::JSValue::asNumber):
         (JSC::jsNaN):
         (JSC::JSValue::JSValue):
         (JSC::JSValue::encode):
         (JSC::JSValue::decode):
         (JSC::JSValue::operator bool):
         (JSC::JSValue::operator==):
         (JSC::JSValue::operator!=):
         (JSC::JSValue::isEmpty):
         (JSC::JSValue::isUndefined):
         (JSC::JSValue::isNull):
         (JSC::JSValue::isUndefinedOrNull):
         (JSC::JSValue::isCell):
         (JSC::JSValue::isInt32):
         (JSC::JSValue::isDouble):
         (JSC::JSValue::isTrue):
         (JSC::JSValue::isFalse):
         (JSC::JSValue::tag):
         (JSC::JSValue::payload):
         (JSC::JSValue::asInt32):
         (JSC::JSValue::asDouble):
         (JSC::JSValue::asCell):
         (JSC::JSValue::isNumber):
         (JSC::JSValue::isBoolean):
         (JSC::JSValue::asBoolean):
         (JSC::reinterpretDoubleToInt64):
         (JSC::reinterpretInt64ToDouble):
         (JSC::JSValue::isString):
         (JSC::JSValue::isPrimitive):
         (JSC::JSValue::isGetterSetter):
         (JSC::JSValue::isObject):
         (JSC::JSValue::getString):
         (JSC::::getString):
         (JSC::JSValue::getObject):
         (JSC::JSValue::getUInt32):
         (JSC::JSValue::toPrimitive):
         (JSC::JSValue::getPrimitiveNumber):
         (JSC::JSValue::toNumber):
         (JSC::JSValue::toObject):
         (JSC::JSValue::isFunction):
         (JSC::JSValue::inherits):
         (JSC::JSValue::toThisObject):
         (JSC::JSValue::get):
         (JSC::JSValue::put):
         (JSC::JSValue::putByIndex):
         (JSC::JSValue::structureOrUndefined):
         (JSC::JSValue::equal):
         (JSC::JSValue::equalSlowCaseInline):
         (JSC::JSValue::strictEqualSlowCaseInline):
         (JSC::JSValue::strictEqual):
         * runtime/JSVariableObject.cpp:
         * runtime/JSWithScope.cpp:
         * runtime/JSWrapperObject.cpp:
         * runtime/LiteralParser.cpp:
         * runtime/Lookup.cpp:
         * runtime/NameConstructor.cpp:
         * runtime/NameInstance.cpp:
         * runtime/NamePrototype.cpp:
         * runtime/NativeErrorConstructor.cpp:
         * runtime/NativeErrorPrototype.cpp:
         * runtime/NumberConstructor.cpp:
         * runtime/NumberObject.cpp:
         * runtime/ObjectConstructor.cpp:
         * runtime/ObjectPrototype.cpp:
         * runtime/Operations.h:
         (JSC):
         * runtime/PropertySlot.cpp:
         * runtime/RegExp.cpp:
         * runtime/RegExpCache.cpp:
         * runtime/RegExpCachedResult.cpp:
         * runtime/RegExpConstructor.cpp:
         * runtime/RegExpMatchesArray.cpp:
         * runtime/RegExpObject.cpp:
         * runtime/RegExpPrototype.cpp:
         * runtime/SmallStrings.cpp:
         * runtime/SparseArrayValueMap.cpp:
         * runtime/StrictEvalActivation.cpp:
         * runtime/StringConstructor.cpp:
         * runtime/StringObject.cpp:
         * runtime/StringRecursionChecker.cpp:
         * runtime/Structure.h:
         (JSC):
         * runtime/StructureChain.cpp:
         * runtime/TimeoutChecker.cpp:
         * testRegExp.cpp:

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         If you use Phantom to force something to be live across an OSR exit, you should put it after the OSR exit
         https://bugs.webkit.org/show_bug.cgi?id=106724

         Reviewed by Oliver Hunt.

         In cases where we were getting it wrong, I think it was benign because we would either already have an
         OSR exit prior to there, or the operand would be a constant.  But still, it's good to get this right.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         Phantom(GetLocal) should be treated as relevant to OSR
         https://bugs.webkit.org/show_bug.cgi?id=106715

         Reviewed by Mark Hahnenberg.

         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::performBlockCSE):

 2013-01-11  Pratik Solanki  <psolanki@apple.com>

         Fix function name typo ProgramExecutable::initalizeGlobalProperties()
         https://bugs.webkit.org/show_bug.cgi?id=106701

         Reviewed by Geoffrey Garen.

         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::execute):
         * runtime/Executable.cpp:
         (JSC::ProgramExecutable::initializeGlobalProperties):
         * runtime/Executable.h:

 2013-01-11  Mark Hahnenberg  <mhahnenberg@apple.com>

         testapi is failing with a block-related error in the Objc API
         https://bugs.webkit.org/show_bug.cgi?id=106055

         Reviewed by Filip Pizlo.

         Same bug as in testapi.mm. We need to actually call the static block, rather than casting the block to a bool.

         * API/ObjCCallbackFunction.mm:
         (blockSignatureContainsClass):

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         Add a run-time option to print bytecode at DFG compile time
         https://bugs.webkit.org/show_bug.cgi?id=106704

         Reviewed by Mark Hahnenberg.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * runtime/Options.h:
         (JSC):

 2013-01-11  Filip Pizlo  <fpizlo@apple.com>

         It should be possible to enable verbose printing of each OSR exit at run-time (rather than compile-time) and it should print register state
         https://bugs.webkit.org/show_bug.cgi?id=106700

         Reviewed by Mark Hahnenberg.

         * dfg/DFGAssemblyHelpers.h:
         (DFG):
         (JSC::DFG::AssemblyHelpers::debugCall):
         * dfg/DFGCommon.h:
         * dfg/DFGOSRExit.h:
         (DFG):
         * dfg/DFGOSRExitCompiler32_64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOSRExitCompiler64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * runtime/Options.h:
         (JSC):

 2013-01-11  Geoffrey Garen  <ggaren@apple.com>

         Removed getDirectLocation and offsetForLocation and all their uses
         https://bugs.webkit.org/show_bug.cgi?id=106692

         Reviewed by Filip Pizlo.

         getDirectLocation() and its associated offsetForLocation() relied on
         detailed knowledge of the rules of PropertyOffset, JSObject, and
         Structure, which is a hard thing to reverse-engineer reliably. Luckily,
         it wasn't needed, and all clients either wanted a true value or a
         PropertyOffset. So, I refactored accordingly.

         * dfg/DFGOperations.cpp: Renamed putDirectOffset to putDirect, to clarify
         that we are not putting an offset.

         * runtime/JSActivation.cpp:
         (JSC::JSActivation::getOwnPropertySlot): Get a value instead of a value
         pointer, since we never wanted a pointer to begin with.

         * runtime/JSFunction.cpp:
         (JSC::JSFunction::getOwnPropertySlot): Use a PropertyOffset instead of a pointer,
         so we don't have to reverse-engineer the offset from the pointer.

         * runtime/JSObject.cpp:
         (JSC::JSObject::put):
         (JSC::JSObject::resetInheritorID):
         (JSC::JSObject::inheritorID):
         (JSC::JSObject::removeDirect):
         (JSC::JSObject::fillGetterPropertySlot):
         (JSC::JSObject::getOwnPropertyDescriptor): Renamed getDirectOffset and
         putDirectOffset, as explaind above. We want to use the name "getDirectOffset"
         for when the thing you're getting is the offset.

         * runtime/JSObject.h:
         (JSC::JSObject::getDirect):
         (JSC::JSObject::getDirectOffset): Changed getDirectLocation to getDirectOffset,
         since clients really wants PropertyOffsets and not locations.

         (JSObject::offsetForLocation): Removed this function because it was hard
         to get right.

         (JSC::JSObject::putDirect):
         (JSC::JSObject::putDirectUndefined):
         (JSC::JSObject::inlineGetOwnPropertySlot):
         (JSC::JSObject::putDirectInternal):
         (JSC::JSObject::putDirectWithoutTransition):
         * runtime/JSScope.cpp:
         (JSC::executeResolveOperations):
         (JSC::JSScope::resolvePut):
         * runtime/JSValue.cpp:
         (JSC::JSValue::putToPrimitive): Updated for renames.

         * runtime/Lookup.cpp:
         (JSC::setUpStaticFunctionSlot): Use a PropertyOffset instead of a pointer,
         so we don't have to reverse-engineer the offset from the pointer.

         * runtime/Structure.cpp:
         (JSC::Structure::flattenDictionaryStructure): Updated for renames.

 2013-01-11  Geoffrey Garen  <ggaren@apple.com>

         Removed an unused version of getDirectLocation
         https://bugs.webkit.org/show_bug.cgi?id=106691

         Reviewed by Gavin Barraclough.

         getDirectLocation is a weird operation. Removing the unused version is
         the easy part.

         * runtime/JSObject.h:
         (JSObject):

 2013-01-11  Mark Hahnenberg  <mhahnenberg@apple.com>

         Objective-C objects that are passed to JavaScript leak (until the JSContext is destroyed)
         https://bugs.webkit.org/show_bug.cgi?id=106056

         Reviewed by Darin Adler.

         * API/APIJSValue.h:
         * API/JSValue.mm: Make the reference to the JSContext strong.
         (-[JSValue context]):
         (-[JSValue initWithValue:inContext:]):
         (-[JSValue dealloc]):
         * API/JSWrapperMap.mm: Make the reference back from wrappers to Obj-C objects weak instead of strong.
         Also add an explicit WeakGCMap in the JSWrapperMap rather than using Obj-C associated object API which
         was causing memory leaks.
         (wrapperClass):
         (-[JSObjCClassInfo wrapperForObject:]):
         (-[JSWrapperMap initWithContext:]):
         (-[JSWrapperMap dealloc]):
         (-[JSWrapperMap wrapperForObject:]):

 2013-01-11  Geoffrey Garen  <ggaren@apple.com>

         Fixed some bogus PropertyOffset ASSERTs
         https://bugs.webkit.org/show_bug.cgi?id=106686

         Reviewed by Gavin Barraclough.

         The ASSERTs were passing a JSType instead of an inlineCapacity, due to
         an incomplete refactoring.

         The compiler didn't catch this because both types are int underneath.

         * runtime/JSObject.h:
         (JSC::JSObject::getDirect):
         (JSC::JSObject::getDirectLocation):
         (JSC::JSObject::offsetForLocation):
         * runtime/Structure.cpp:
         (JSC::Structure::addPropertyTransitionToExistingStructure): Validate against
         our inline capacity, as we intended.

 2013-01-11  Geoffrey Garen  <ggaren@apple.com>

         Rename propertyOffsetFor => offsetForPropertyNumber
         https://bugs.webkit.org/show_bug.cgi?id=106685

         Reviewed by Gavin Barraclough.

         Since the argument is just a typedef and not an object, I wanted to clarify the meaning.

         * runtime/PropertyMapHashTable.h:
         (JSC::PropertyTable::nextOffset): Updated for rename.

         * runtime/PropertyOffset.h:
         (JSC::offsetForPropertyNumber): Renamed. Also changed some PropertyOffset variables
         to plain ints, because they're not actually on the PropertyOffsets number line.

         * runtime/Structure.cpp:
         (JSC::Structure::flattenDictionaryStructure):
         * runtime/Structure.h:
         (JSC::Structure::lastValidOffset): Updated for rename.

 2013-01-10  Zan Dobersek  <zandobersek@gmail.com>

         Remove the ENABLE_ANIMATION_API feature define occurences
         https://bugs.webkit.org/show_bug.cgi?id=106544

         Reviewed by Simon Fraser.

         The Animation API code was removed in r137243. The ENABLE_ANIMATION_API
         feature define handling still lingers in various build systems and configurations
         but is of no use, so it should be removed.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-09  Roger Fong  <roger_fong@apple.com>

         Unreviewed. Just move the JavaScriptCore exports file around in the vcproj to make things clearer.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:

 2013-01-09  Filip Pizlo  <fpizlo@apple.com>

         Dont use a node reference after appending to the graph.
         https://bugs.webkit.org/show_bug.cgi?id=103305
         <rdar://problem/12753096>

         Reviewed by Mark Hahnenberg.

         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):

 2013-01-09  Roger Fong  <roger_fong@apple.com>

         Rename export files to make them more easily findable.
         https://bugs.webkit.org/show_bug.cgi?id=98695.

         Reviewed by Timothy Horton.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Removed.
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Copied from Source/JavaScriptCore/JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def.

 2013-01-09  Carlos Garcia Campos  <cgarcia@igalia.com>

         Unreviewed. Fix make distcheck.

         * GNUmakefile.list.am: Add mips.rb to offlineasm_nosources.

 2013-01-08  Oliver Hunt  <oliver@apple.com>

         Support op_typeof in the DFG
         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.


 2013-01-08  Filip Pizlo  <fpizlo@apple.com>

         DFG shouldn't treat the 'this' argument as being captured if a code block uses arguments
         https://bugs.webkit.org/show_bug.cgi?id=106398
         <rdar://problem/12439776>

         Reviewed by Mark Hahnenberg.

         This is a possible optimization for inlined calls, and fixes crashes for inlined constructors, in the case
         that the inlined code used arguments. The problem was that assuming that 'this' was captured implies the
         assumption that it was initialized by the caller, which is wrong for constructors and this.

         Also added a pretty essential DFG IR validation rule: we shouldn't have any live locals at the top of the
         root block. This helps to catch this bug: our assumption that 'this' was captured in an inlined constructor
         that used arguments led to liveness for the temporary that would have held 'this' in the caller being
         propagated all the way up to the entrypoint of the function.

         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::isCaptured):
         * dfg/DFGValidate.cpp:
         (JSC::DFG::Validate::validate):
         (JSC::DFG::Validate::reportValidationContext):
         (Validate):
         (JSC::DFG::Validate::dumpGraphIfAppropriate):

 2013-01-08  Filip Pizlo  <fpizlo@apple.com>

         REGRESSION (r138921): Crash in JSC::Arguments::create
         https://bugs.webkit.org/show_bug.cgi?id=106329
         <rdar://problem/12974196>

         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):

 2013-01-08  Filip Pizlo  <fpizlo@apple.com>

         DFG initrinsic handling should ensure that we backwards propagate the fact that all operands may escape
         https://bugs.webkit.org/show_bug.cgi?id=106365

         Reviewed by Mark Hahnenberg.

         Use the fact that Phantom means that things escaped, and just insert Phantoms for all
         of the operands.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleCall):

 2013-01-08  Filip Pizlo  <fpizlo@apple.com>

         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.

         * runtime/JSArray.h:
         (JSC::JSArray::tryCreateUninitialized):

 2013-01-07  Filip Pizlo  <fpizlo@apple.com>

         DFG should backwards-propagate NodeUsedAsValue for Phantom
         https://bugs.webkit.org/show_bug.cgi?id=106299

         Reviewed by Mark Hahnenberg.

         This is currently benign because Phantom is only inserted by the bytecode parser for
         things that already happen to be used in contexts that backwards propagate
         NodeUsedAsValue. But that doesn't change the fact that the semantics of Phantom are
         that the value can be arbitrarily used by the baseline JIT.

         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):

 2013-01-07  Filip Pizlo  <fpizlo@apple.com>

         Rationalize closure call heuristics and profiling
         https://bugs.webkit.org/show_bug.cgi?id=106270

         Reviewed by Oliver Hunt.

         Did a number of things:

         - CallLinkInfo now remembers if it was ever a closure call, and CallLinkStatus uses
           this. Reduces the likelihood that we will inline a closure call as if it was a
           normal call.

         - Made InlineCallFrame print inferred function names, and refactored
           CodeBlock::inferredName() to better use FunctionExecutable's API.

         - Made bytecode dumping print frequent exit sites that led to recompilation.

         - Made bytecode dumping for op_call and op_construct print what the CallLinkStatus
           saw.

         * bytecode/CallLinkInfo.h:
         (JSC::CallLinkInfo::CallLinkInfo):
         (CallLinkInfo):
         * bytecode/CallLinkStatus.cpp:
         (JSC::CallLinkStatus::computeFor):
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::inferredName):
         (JSC::CodeBlock::dumpBytecodeCommentAndNewLine):
         (JSC::CodeBlock::printCallOp):
         * bytecode/CodeOrigin.cpp:
         (JSC::CodeOrigin::dump):
         (JSC::InlineCallFrame::inferredName):
         (JSC):
         (JSC::InlineCallFrame::dumpBriefFunctionInformation):
         (JSC::InlineCallFrame::dump):
         * bytecode/CodeOrigin.h:
         (InlineCallFrame):
         * bytecode/DFGExitProfile.cpp:
         (JSC::DFG::ExitProfile::exitSitesFor):
         (DFG):
         * bytecode/DFGExitProfile.h:
         (ExitProfile):
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION):

 2013-01-07  Ryosuke Niwa  <rniwa@webkit.org>

         Sorted the xcodeproj file.

         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-01-07  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, it should be possible to build JSC on ARM.

         * API/JSBase.h:
         * jit/JITStubs.cpp:
         (JSC::performPlatformSpecificJITAssertions):
         (JSC):
         * jit/JITStubs.h:
         (JSC):
         * jit/JITThunks.cpp:
         (JSC::JITThunks::JITThunks):
         * jit/JITThunks.h:
         (JITThunks):
         * offlineasm/armv7.rb:
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):

 2013-01-07  Balazs Kilvady  <kilvadyb@homejinni.com>

         MIPS LLInt implementation.
         https://bugs.webkit.org/show_bug.cgi?id=99706

         Reviewed by Filip Pizlo.

         LLInt implementation for MIPS.

         * assembler/MacroAssemblerMIPS.h:
         (JSC::MacroAssemblerMIPS::jump):
         * dfg/DFGOperations.cpp:
         (JSC):
         * jit/JITStubs.cpp:
         (JSC):
         * jit/JITStubs.h:
         (JITStackFrame):
         * llint/LLIntOfflineAsmConfig.h:
         * llint/LowLevelInterpreter.asm:
         * llint/LowLevelInterpreter32_64.asm:
         * offlineasm/backends.rb:
         * offlineasm/instructions.rb:
         * offlineasm/mips.rb: Added.

 2013-01-07  Mark Hahnenberg  <mhahnenberg@apple.com>

         testapi is failing with a block-related error in the Objc API
         https://bugs.webkit.org/show_bug.cgi?id=106055

         Reviewed by Geoffrey Garen.

         Casting a block to a bool will always return true, which isn't the behavior that is intended here.
         Instead we need to call the block, but C semantics don't allow this, so we need to change
         testapi.m to be Objective-C++ and therefore testapi.mm.

         * API/tests/testapi.m: Removed.
         * API/tests/testapi.mm: Copied from Source/JavaScriptCore/API/tests/testapi.m.
         (blockSignatureContainsClass):
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2013-01-06  Filip Pizlo  <fpizlo@apple.com>

         Simplify slow case profiling
         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:

 2013-01-05  Filip Pizlo  <fpizlo@apple.com>

         DFG should inline closure calls
         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):

 2013-01-05  Filip Pizlo  <fpizlo@apple.com>

         Data flow paths that carry non-numbers, non-undefined, non-null values should not cause subtractions and arithmetic additions (i.e. ++) to speculate double
         https://bugs.webkit.org/show_bug.cgi?id=106190

         Reviewed by Sam Weinig.

         The problem is that the DFG logic for deciding when to speculate integer was
         confusing the special case of ValueAdd (where non-numeric values should cause us
         to not speculate integer, because we want to fall off into the generic case) with
         the more normal case of ArithAdd and ArithSub (where we want to speculate integer
         unless we have evidence that the operands are doubles, since the DFG doesn't have
         generic handling of non-numeric arithmetic). Prior to this change doing a - b where
         either a or b were possibly non-numeric would always force the subtraction to be
         done using doubles.

         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::addSpeculationMode):
         (Graph):
         (JSC::DFG::Graph::valueAddSpeculationMode):
         (JSC::DFG::Graph::arithAddSpeculationMode):
         (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):

 2013-01-04  Filip Pizlo  <fpizlo@apple.com>

         DFG should trust array profiling over value profiling
         https://bugs.webkit.org/show_bug.cgi?id=106155

         Reviewed by Gavin Barraclough.

         The real problem is that prediction propagation is not flow-sensitive. We had code
         like:

         var a = (some load from memory); // returns either an array or false
         if (a)
             a[i] = v;

         Because 'a' could be 'false', we were emitting a fully generic unoptimized PutByVal.
         This patch changes ArrayMode to ignore the type of the base of an array access, if
         array profiling tells us that the array access can be optimized.

         In the future, we could probably make this work even better with some flow
         sensitivity in the prediction propagator, but I also tend to think that this is a
         more robust overall solution. If we ever did want to support array accesses on
         array-or-false then we should change the array profiler to be able to tell us that
         this is what is going on.

         3.7% speed-up on V8/earley.

         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::refine):

 2013-01-04  Filip Pizlo  <fpizlo@apple.com>

         Rationalize exit site profiling for calls
         https://bugs.webkit.org/show_bug.cgi?id=106150

         Reviewed by Sam Weinig.

         This adds two new exit kinds for calls: BadFunction and BadExecutable. The latter is not used
         yet, but is already integrated with profiling. CheckFunction uses a BadFunction speculation
         instead of BadCache, now. This allows CallLinkStatus to turn itself into a closure call status
         if we had a BadFunction exit site but the CallLinkInfo told us to use a non-closure call. This
         might happen if we had call unlinking that led to information loss along the way.

         No performance impact. This is meant as another step towards inlining closure calls.

         * bytecode/CallLinkStatus.cpp:
         * bytecode/CallLinkStatus.h:
         (JSC::CallLinkStatus::setIsProved):
         (JSC::CallLinkStatus::setHasBadFunctionExitSite):
         (CallLinkStatus):
         (JSC::CallLinkStatus::setHasBadCacheExitSite):
         (JSC::CallLinkStatus::setHasBadExecutableExitSite):
         * bytecode/ExitKind.cpp:
         (JSC::exitKindToString):
         * bytecode/ExitKind.h:
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleCall):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):

 2013-01-03  Filip Pizlo  <fpizlo@apple.com>

         DFG should not elide CheckStructure if it's needed to perform a cell check
         https://bugs.webkit.org/show_bug.cgi?id=106074

         Reviewed by Ryosuke Niwa.

         The problem here was that the constant folding phase was misinterpreting the meaning of the sets
         in DFG::AbstractValue.  AbstractValue describes a constraint on the values that a variable (i.e.
         a DFG Node, or a virtual register, i.e. local or argument) may have. It does so by containing
         four sets: the set of JSValues (either empty, the singleton set containing one JSValue, or the
         set of all JSValues); the set of "current known" structures, i.e. the set of structures that you
         already know that this value may have right now (also either empty, the singleton set, or the set
         of all structures); the set of "future possible" structures, i.e. the set of structures that this
         value could have in the future if none of the structure transition watchpoints for those
         structures had fired (also empty, singleton, or all); and the set of types, which is a
         SpeculatedType bitmask. The correct way to interpret the sets is to think of the AbstractValue as
         the intersection of these three sets of values:

         - The set of JSValues that have a type that belongs to the m_type set.
         - If m_value is not the empty value then: the set of all JSValues that are == m_value;
                                             else: the set of all JSValues.
           where '==' is as defined by JSValue::operator==.
         - Union of { the set of all cells that have a structure that belongs to m_currentKnownStructure }
                and { the set of all JSValues that are not cells }.

         You can then further intersect this set with the following set, if you guard the code with
         watchpoints on all structures in the m_futurePossibleStructure:

         - Union of { the set of all cells that have a structure that belongs to m_futurePossibleStructure }
                and { the set of all JSValues that are not cells }.

         One way to think of this is that m_currentKnownStructure is filtered by m_futurePossibleStructure
         (i.e. is set to the intersection of m_currentKnownStructure and m_futurePossibleStructure), if the
         code for which you're doing this is always preceded by watchpoints on all structures in
         m_futurePossibleStructure, and is always before any side-effects that could change the structures
         of objects.

         The incorrect optimization related to CheckStructure. CheckStructure checks that the value is a
         cell, and that it has a particular structure. It was incorrectly assuming that you could eliminate
         the CheckStructure, if m_currentKnownStructure contained the structure that CheckStructure was
         checking. But this is not the case, since m_currentKnownStructure does not prove that the value is
         a cell with a particular structure; it only proves that if the value was a cell then it would have
         a particular structure. Hence, to eliminate CheckStructure, it is also necessary to check that
         AbstractValue::m_type contains only cells (i.e. isCellSpeculation(m_type) == true).

         It wasn't doing that, and this changes makes sure that it does do that.

         * dfg/DFGConstantFoldingPhase.cpp:
         (JSC::DFG::ConstantFoldingPhase::foldConstants):

 2013-01-04  Adam Klein  <adamk@chromium.org>

         Remove ENABLE_MUTATION_OBSERVERS #define
         https://bugs.webkit.org/show_bug.cgi?id=105459

         Reviewed by Ryosuke Niwa.

         * Configurations/FeatureDefines.xcconfig:

 2013-01-03  Filip Pizlo  <fpizlo@apple.com>

         DFG::ByteCodeCache serves little or no purpose ever since we decided to keep bytecode around permanently
         https://bugs.webkit.org/show_bug.cgi?id=106058

         Reviewed by Michael Saboff.

         All baseline code blocks now always have bytecode, so the bytecode cache's ability to minimize the
         number of times that the DFG produces bytecode sequences for code blocks is superfluous.

         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * dfg/DFGByteCodeCache.h: Removed.
         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::handleInlining):
         * runtime/Executable.cpp:
         (JSC):
         * runtime/Executable.h:
         (FunctionExecutable):

 2013-01-03  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, fix build for DFG JIT disabled.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpValueProfiling):
         (JSC::CodeBlock::dumpArrayProfiling):
         * runtime/Executable.cpp:
         (JSC):
         (JSC::ExecutableBase::intrinsic):

 2013-01-03  Filip Pizlo  <fpizlo@apple.com>

         CallLinkStatus should be aware of closure calls, and the DFG bytecode parser should use that as its sole internal notion of how to optimize calls
         https://bugs.webkit.org/show_bug.cgi?id=106027

         Reviewed by Mark Hahnenberg.

         Previously, the DFG bytecode parser had its own internal notion of exactly what CallLinkStatus was
         meant to do, in the form of a CallType, expectedFunction, intrinsic, etc. This change makes CallLinkStatus
         smart enough to do all of that, and also gives it the ability to understand closure calls.

         * bytecode/CallLinkStatus.cpp:
         (JSC::CallLinkStatus::CallLinkStatus):
         (JSC):
         (JSC::CallLinkStatus::function):
         (JSC::CallLinkStatus::internalFunction):
         (JSC::CallLinkStatus::intrinsicFor):
         (JSC::CallLinkStatus::setIsProved):
         (JSC::CallLinkStatus::computeFromLLInt):
         (JSC::CallLinkStatus::computeFor):
         (JSC::CallLinkStatus::dump):
         * bytecode/CallLinkStatus.h:
         (JSC):
         (JSC::CallLinkStatus::CallLinkStatus):
         (CallLinkStatus):
         (JSC::CallLinkStatus::takesSlowPath):
         (JSC::CallLinkStatus::isSet):
         (JSC::CallLinkStatus::isClosureCall):
         (JSC::CallLinkStatus::callTarget):
         (JSC::CallLinkStatus::executable):
         (JSC::CallLinkStatus::structure):
         (JSC::CallLinkStatus::isProved):
         (JSC::CallLinkStatus::canOptimize):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleCall):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::valueOfFunctionConstant):

 2013-01-02  Simon Hausmann  <simon.hausmann@digia.com>

         [MinGW-w64] Centralize workaround for pow() implementation
         https://bugs.webkit.org/show_bug.cgi?id=105925

         Reviewed by Sam Weinig.

         As suggested by Sam, move the MinGW-w64 workaround into MathExtras.h
         away from the JSC usage.

         * runtime/MathObject.cpp:
         (JSC::mathPow):

 2013-01-02  Gavin Barraclough  <barraclough@apple.com>

         Objective-C API for JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=105889

         Reviewed by Geoff Garen.

         Fixes for more issues raised by Darin.

         * API/JSBlockAdaptor.mm:
         (BlockArgument):
         (BlockArgumentStruct::BlockArgumentStruct):
         (BlockArgumentTypeDelegate::typeStruct):
         (BlockResult):
         (BlockResultStruct::BlockResultStruct):
         (buildBlockSignature):
         (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]):
         (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
             - fix * position for Objective-C types
         * API/JSContext.h:
             - fix * position for Objective-C types
         * API/JSContext.mm:
         (-[JSContext initWithVirtualMachine:]):
         (-[JSContext virtualMachine]):
         (contextInternalContext):
             - fix * position for Objective-C types
         (-[JSContext dealloc]):
         (-[JSContext protect:]):
         (-[JSContext unprotect:]):
             - HashMap<JSValueRef, size_t> -> HashCountedSet<JSValueRef>
         * API/JSContextInternal.h:
         (WeakContextRef):
             - fix * position for Objective-C types
         * API/JSValue.mm:
         (valueToString):
             - fix * position for Objective-C types
         (isNSBoolean):
             - Added helper to check for booleans.
         (objectToValueWithoutCopy):
             - Added contextRef
             - fix * position for Objective-C types
             - Remove @YES, @NO literal usage, use isNSBoolean instead
         (objectToValue):
             - Added contextRef
         (+[JSValue valueWithValue:inContext:]):
         (-[JSValue initWithValue:inContext:]):
             - fix * position for Objective-C types
         (createStructHandlerMap):
         (handerForStructTag):
             - getStructTagHandler -> handerForStructTag
             - Split out createStructHandlerMap
             - strncmp -> memcmp
             - String(type).impl() -> StringImpl::create(type)
         (+[JSValue selectorForStructToValue:]):
         (+[JSValue selectorForValueToStruct:]):
             - getStructTagHandler -> handerForStructTag
         (typeToValueInvocationFor):
         (valueToTypeInvocationFor):
             - fix * position for Objective-C types
         * API/JSValueInternal.h:
             - fix * position for Objective-C types
         * API/JSVirtualMachineInternal.h:
             - fix * position for Objective-C types
         * API/JSWrapperMap.h:
             - fix * position for Objective-C types
         * API/JSWrapperMap.mm:
         (selectorToPropertyName):
         (createObjectWithCustomBrand):
         (createRenameMap):
         (putNonEnumerable):
         (copyMethodsToObject):
         (copyPrototypeProperties):
         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
         (-[JSWrapperMap initWithContext:]):
         (-[JSWrapperMap wrapperForObject:]):
         (getJSExportProtocol):
             - fix * position for Objective-C types
         * API/ObjCCallbackFunction.h:
             - fix * position for Objective-C types
         * API/ObjCCallbackFunction.mm:
         (CallbackArgument):
         (CallbackArgumentStruct::CallbackArgumentStruct):
             - fix * position for Objective-C types
         (CallbackArgumentBlockCallback::createAdoptingJSBlockAdaptor):
             - Added to make adopt explicit
         (CallbackArgumentBlockCallback):
         (CallbackArgumentBlockCallback::CallbackArgumentBlockCallback):
         (ArgumentTypeDelegate::typeBlock):
             - Call createAdoptingJSBlockAdaptor
         (ArgumentTypeDelegate::typeStruct):
         (CallbackResult):
         (CallbackResultStruct::CallbackResultStruct):
         (ResultTypeDelegate::typeStruct):
         (ObjCCallbackFunction::ObjCCallbackFunction):
         (ObjCCallbackFunction::context):
         (objCCallbackFunctionForInvocation):
         (objCCallbackFunctionForMethod):
         (objCCallbackFunctionForBlock):
             - fix * position for Objective-C types
         * API/ObjcRuntimeExtras.h:
         (protocolImplementsProtocol):
         (forEachProtocolImplementingProtocol):
         (forEachMethodInProtocol):
         (forEachPropertyInProtocol):
             - fix * position for Objective-C types
         * API/tests/testapi.m:
         (-[TestObject testArgumentTypesWithInt:double:boolean:string:number:array:dictionary:]):
         (testObjectiveCAPI):
             - fix * position for Objective-C types

 2013-01-02  Geoffrey Garen  <ggaren@apple.com>

         Some renaming in the CodeCache
         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):

 2013-01-02  Filip Pizlo  <fpizlo@apple.com>

         DFG inlining machinery should be robust against the inline callee varying while the executable stays the same
         https://bugs.webkit.org/show_bug.cgi?id=105953

         Reviewed by Mark Hahnenberg.

         This institutes the policy that if InlineCallFrame::callee is null, then the callee and scope have already
         been stored into the true call frame (i.e. the place where the call frame of the inlined call would have
         been) and so any attempt to access the callee or scope should do a load instead of assuming that the value
         is constant. This wires the changes through the bytecode parser, the stack scanning logic, and the compiler
         optimization phases and backends.

         * bytecode/CodeOrigin.cpp:
         (JSC::InlineCallFrame::dump):
         * bytecode/CodeOrigin.h:
         (CodeOrigin):
         (InlineCallFrame):
         (JSC::InlineCallFrame::isClosureCall):
         (JSC::CodeOrigin::stackOffset):
         (JSC):
         * dfg/DFGAssemblyHelpers.h:
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::get):
         (InlineStackEntry):
         (JSC::DFG::ByteCodeParser::getScope):
         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
         * dfg/DFGCSEPhase.cpp:
         (CSEPhase):
         (JSC::DFG::CSEPhase::genericPureCSE):
         (JSC::DFG::CSEPhase::pureCSE):
         (JSC::DFG::CSEPhase::pureCSERequiringSameInlineCallFrame):
         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGOSRExitCompiler32_64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOSRExitCompiler64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * interpreter/CallFrame.cpp:
         (JSC::CallFrame::trueCallFrame):

 2013-01-02  Gavin Barraclough  <barraclough@apple.com>

         Objective-C API for JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=105889

         Reviewed by Geoff Garen.

         Fixes for a number of issues raised by Darin.

         * API/APIJSValue.h:
             - Fix typos in comment
             - Add newline before NS_CLASS_AVAILABLE(10_9, NA)
             - cls -> expectedClass
             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
         * API/JSBase.h:
             - JS_OBJC_API_ENABLED no longer implies __OBJC__
         * API/JSBlockAdaptor.mm:
         (BlockArgumentStruct::BlockArgumentStruct):
         (BlockArgumentStruct):
             - mark virtual functions as virtual, override, and private
             - refactor out buffer allocation for struct types
         (BlockArgumentTypeDelegate::typeVoid):
         (BlockArgumentTypeDelegate::typeBlock):
         (BlockArgumentTypeDelegate::typeStruct):
             - return nil -> return 0
         (BlockResultStruct::BlockResultStruct):
         (BlockResultStruct):
             - mark virtual functions as virtual, override, and private
             - refactor out buffer allocation for struct types
         (buildBlockSignature):
             - %lu is not an appropriate format specifier for NSInteger
         (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]):
             - nil check [super init]
         (-[JSBlockAdaptor blockMatchesSignature:]):
         (-[JSBlockAdaptor blockFromValue:inContext:withException:]):
             - ctx -> contextRef
         * API/JSContext.h:
             - Fix typos in comment
             - Add newline before NS_CLASS_AVAILABLE(10_9, NA)
             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
         * API/JSContext.mm:
         (-[JSContext initWithVirtualMachine:]):
             - nil check [super init]
         (+[JSContext currentArguments]):
             - args -> argumentArray
         (-[JSContext setObject:forKeyedSubscript:]):
             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
         (-[JSContext dealloc]):
         (-[JSContext protect:]):
         (-[JSContext unprotect:]):
             - m_protected -> m_protectCounts
         * API/JSValue.mm:
         (-[JSValue toObjectOfClass:]):
             - cls -> expectedClass
         (-[JSValue toBool]):
         (-[JSValue deleteProperty:]):
         (-[JSValue hasProperty:]):
         (-[JSValue isUndefined]):
         (-[JSValue isNull]):
         (-[JSValue isBoolean]):
         (-[JSValue isNumber]):
         (-[JSValue isString]):
         (-[JSValue isObject]):
         (-[JSValue isEqualToObject:]):
         (-[JSValue isEqualWithTypeCoercionToObject:]):
         (-[JSValue isInstanceOf:]):
             - removed ? YES : NO
         (-[JSValue callWithArguments:]):
         (-[JSValue constructWithArguments:]):
         (-[JSValue invokeMethod:withArguments:]):
             - args -> argumentArray
         (+[JSValue valueWithPoint:inContext:]):
         (+[JSValue valueWithRange:inContext:]):
         (+[JSValue valueWithRect:inContext:]):
         (+[JSValue valueWithSize:inContext:]):
             - [NSNumber numberWithFloat:] -> @()
         (-[JSValue objectForKeyedSubscript:]):
         (-[JSValue setObject:forKeyedSubscript:]):
             - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> *
         (JSContainerConvertor):
         (JSContainerConvertor::isWorkListEmpty):
         (JSContainerConvertor::convert):
         (ObjcContainerConvertor):
         (ObjcContainerConvertor::isWorkListEmpty):
             - remove WTF::
             - isWorkListEmpty is const
         (objectToValue):
             -  use fast enumeration
         (-[JSValue initWithValue:inContext:]):
             - nil check [super init]
         (getStructTagHandler):
             - m_structHandlers -> structHandlers
         * API/JSVirtualMachine.h:
             - Add newline before NS_CLASS_AVAILABLE(10_9, NA)
         * API/JSVirtualMachine.mm:
         (-[JSVirtualMachine init]):
             - nil check [super init]
         * API/JSWrapperMap.mm:
         (selectorToPropertyName):
         (copyPrototypeProperties):
             - remove WTF::
             - use static_cast
         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]):
         (-[JSWrapperMap initWithContext:]):
             - nil check [super init]
         (-[JSWrapperMap wrapperForObject:]):
         (tryUnwrapObjcObject):
             - enable ASSERT
         (getJSExportProtocol):
         (getNSBlockClass):
             - remove if check on initializing static
         * API/JavaScriptCore.h:
             - JS_OBJC_API_ENABLED no longer implies __OBJC__
         * API/ObjCCallbackFunction.mm:
         (CallbackArgumentOfClass):
         (CallbackArgumentOfClass::~CallbackArgumentOfClass):
         (CallbackArgumentStruct::CallbackArgumentStruct):
         (CallbackArgumentStruct):
         (CallbackArgumentBlockCallback):
             - mark virtual functions as virtual, override, and private
             - refactor out buffer allocation for struct types
         (ArgumentTypeDelegate::typeVoid):
         (ArgumentTypeDelegate::typeOfClass):
         (ArgumentTypeDelegate::typeStruct):
             - return nil -> return 0
         (CallbackResultStruct::CallbackResultStruct):
         (CallbackResultStruct):
             - mark virtual functions as virtual, override, and private
             - refactor out buffer allocation for struct types
         (ResultTypeDelegate::typeStruct):
             - return nil -> return 0
         (ObjCCallbackFunction):
             - remove WTF::
         (objCCallbackFunctionFinalize):
             - use static_cast
         (objCCallbackFunctionCallAsFunction):
             - Fix typos in comment
         (createObjCCallbackFunctionClass):
         (objCCallbackFunctionClass):
             - Split out createObjCCallbackFunctionClass from objCCallbackFunctionClass
         (ObjCCallbackFunction::call):
             - ctx -> contextRef
         (blockSignatureContainsClass):
             - Remove tri-state enum.
         (skipNumber):
             - isdigit -> isASCIIDigit
         (objCCallbackFunctionForInvocation):
             - clean up & comment blockSignatureContainsClass() usage
         (tryUnwrapBlock):
             - use static_cast
         * API/ObjcRuntimeExtras.h:
         (forEachProtocolImplementingProtocol):
         (forEachMethodInClass):
         (forEachMethodInProtocol):
         (forEachPropertyInProtocol):
             - Remove WTF::
             - Remove if (count) checks
         (skipPair):
             - NSUInteger -> size_t
         (StringRange):
         (StringRange::operator const char*):
         (StringRange::get):
         (StructBuffer):
         (StructBuffer::StructBuffer):
         (StructBuffer::~StructBuffer):
         (StructBuffer::operator void*):
             - Added helper for creating an aligned buffer, used by struct conversion invocations.
         (parseObjCType):
             - *(position++) -> *position++
         * API/tests/testapi.c:
             - PLATFORM(MAC) -> JS_OBJC_API_ENABLED
         * API/tests/testapi.m:
         (blockSignatureContainsClass):
             - Remove tri-state enum.
         (testObjectiveCAPI):
             - Added more result type checks.

 2013-01-02  Filip Pizlo  <fpizlo@apple.com>

         DFG should not use the InlineCallFrame's callee when it could have used the executable istead
         https://bugs.webkit.org/show_bug.cgi?id=105947

         Reviewed by Mark Hahnenberg.

         We shouldn't use the callee to get the executable when we have the executable already. Not only
         does this make the logic more clear, but it also allows for a world where the executable is known
         but the callee isn't.

         * dfg/DFGAssemblyHelpers.h:
         (JSC::DFG::AssemblyHelpers::strictModeFor):

 2013-01-02  Filip Pizlo  <fpizlo@apple.com>

         DFG inliner should not use the callee's bytecode variable for resolving references to the callee in inlined code
         https://bugs.webkit.org/show_bug.cgi?id=105938

         Reviewed by Mark Hahnenberg.

         This simplifies a bunch of code for referring to the callee. It also ought to simplify how we do
         closure call inlining: for inlined closure call frames we will simply require that the callee is
         already stashed on the stack in the Callee slot in the inline call frame header.

         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::getDirect):
         (JSC::DFG::ByteCodeParser::get):
         (InlineStackEntry):
         (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand):
         (JSC::DFG::ByteCodeParser::handleCall):
         (JSC::DFG::ByteCodeParser::handleInlining):
         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
         (JSC::DFG::ByteCodeParser::parse):

 2013-01-02  Ryosuke Niwa  <rniwa@webkit.org>

         Another Windows port build fix attempt. Try not exporting this symbol from JSC
         since it's also compiled in WebCore.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2013-01-02  Csaba Osztrogonác  <ossy@webkit.org>

         One more unreviewed buildfix after r138609.

         * jit/JITCall.cpp: Add a missing include.

 2013-01-02  Csaba Osztrogonác  <ossy@webkit.org>

         Unreviewed buildfix after r138609.

         * jit/JITCall32_64.cpp: Add a missing include.

 2013-01-01  Filip Pizlo  <fpizlo@apple.com>

         Baseline JIT should have closure call caching
         https://bugs.webkit.org/show_bug.cgi?id=105900

         Reviewed by Gavin Barraclough.

         This is not a speed-up by itself, but is meant to allow the DFG inliner to
         accurately discern between closure calls and non-closure calls, so that it can
         do closure call inlining in the future.

         * bytecode/CallLinkStatus.cpp:
         (JSC::CallLinkStatus::computeFromLLInt):
         (JSC::CallLinkStatus::computeFor):
         * bytecode/CallLinkStatus.h:
         (JSC::CallLinkStatus::CallLinkStatus):
         (JSC::CallLinkStatus::isClosureCall):
         (CallLinkStatus):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::handleCall):
         * jit/JIT.cpp:
         (JSC::JIT::linkFor):
         (JSC::JIT::linkSlowCall):
         * jit/JIT.h:
         (JSC::JIT::compileClosureCall):
         * jit/JITCall.cpp:
         (JSC::JIT::privateCompileClosureCall):
         * jit/JITCall32_64.cpp:
         (JSC::JIT::privateCompileClosureCall):
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION):
         * jit/JITStubs.h:
         * jit/ThunkGenerators.cpp:
         (JSC::linkClosureCallGenerator):
         * jit/ThunkGenerators.h:

 2013-01-01  Dan Bernstein  <mitz@apple.com>

         <rdar://problem/12942239> Update copyright strings

         Reviewed by Sam Weinig.

         * Info.plist:

 2012-12-31  Gavin Barraclough  <barraclough@apple.com>

         Objective-C API for JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=105889

         Reviewed by Filip Pizlo.

         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.

 2012-12-27  Csaba Osztrogonác  <ossy@webkit.org>

         One more unreviwed holiday MIPS and SH4 buildfixes after r138516.

         * jit/ThunkGenerators.cpp:

 2012-12-27  Csaba Osztrogonác  <ossy@webkit.org>

         Unreviwed holiday ARM and SH4 buildfixes after r138516.

         * jit/ThunkGenerators.cpp:
         (JSC::nativeForGenerator):

 2012-12-26  Filip Pizlo  <fpizlo@apple.com>

         All JIT stubs should go through the getCTIStub API
         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):

 2012-12-25  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

         [CMAKE] Remove header files in JavaScriptCore/CMakeLists.txt
         https://bugs.webkit.org/show_bug.cgi?id=105753

         Reviewed by Laszlo Gombos.

         * CMakeLists.txt: Remove header files in source list.

 2012-12-25  Filip Pizlo  <fpizlo@apple.com>

         JITThunks should be in its own file
         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:

 2012-12-25  Ilya Tikhonovsky  <loislo@chromium.org>

         Unreviewed follow-up for r138455.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-12-24  Ilya Tikhonovsky  <loislo@chromium.org>

         Unreviewed compilation fix for r138452.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-12-24  Laszlo Gombos  <l.gombos@samsung.com>

         Remove wtf/Platform.h includes from {c|cpp} files
         https://bugs.webkit.org/show_bug.cgi?id=105678

         Reviewed by Kentaro Hara.

         Remove wtf/Platform.h from the include list as it is already
         included in config.h.

         * disassembler/udis86/udis86.c:
         * disassembler/udis86/udis86_decode.c:
         * disassembler/udis86/udis86_input.c:
         * disassembler/udis86/udis86_itab_holder.c:
         * disassembler/udis86/udis86_syn-att.c:
         * disassembler/udis86/udis86_syn-intel.c:
         * disassembler/udis86/udis86_syn.c:
         * heap/VTableSpectrum.cpp:

 2012-12-21  Filip Pizlo  <fpizlo@apple.com>

         DFG Arrayify slow path should be out-of-line
         https://bugs.webkit.org/show_bug.cgi?id=105400

         Reviewed by Gavin Barraclough.

         The interesting bit of this change is allowing out-of-line slow path generators
         to emit speculation checks. This is accomplished by having a version of
         speculationCheck() that returns a jump placeholder instead of taking a jump (or
         jump list) as an argument. You can then fill in that jump placeholder at a
         later time, so long as you do it before OSR exit linking. Slow path generators
         run before linking, so that just naturally ends up working.

         This isn't really a big win, but we know that out-of-lining slow paths is
         generally a good thing to do, so it's fair to assume that this is a move in the
         right direction.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * dfg/DFGArrayifySlowPathGenerator.h: Added.
         (DFG):
         (ArrayifySlowPathGenerator):
         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
         (JSC::DFG::ArrayifySlowPathGenerator::generateInternal):
         * dfg/DFGOSRExitJumpPlaceholder.cpp: Added.
         (DFG):
         (JSC::DFG::OSRExitJumpPlaceholder::fill):
         * dfg/DFGOSRExitJumpPlaceholder.h: Added.
         (DFG):
         (OSRExitJumpPlaceholder):
         (JSC::DFG::OSRExitJumpPlaceholder::OSRExitJumpPlaceholder):
         (JSC::DFG::OSRExitJumpPlaceholder::operator!):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (DFG):
         (JSC::DFG::SpeculativeJIT::arrayify):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):

 2012-12-20  Oliver Hunt  <oliver@apple.com>

         Finally found the problem.  Using the wrong JSContextGroup.

         * API/tests/testapi.c:
         (main):

 2012-12-20  Oliver Hunt  <oliver@apple.com>

         Try to convince bots to be happy with testapi.

         * API/JSScriptRefPrivate.h:

 2012-12-20  Michael Saboff  <msaboff@apple.com>

         JIT: Change uninitialized pointer value -1 to constant
         https://bugs.webkit.org/show_bug.cgi?id=105576

         Rubber stamped by Gavin Barraclough.

         Changed the use of -1 as a pointer value in the JITs to be the constant unusedPointer defined in the
         new file jit/UnusedPointer.h.  Made it's value 0xd1e7beef, which is a bad pointer on most architectures
         because it is odd, and to distinguish it from other common values.

         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * dfg/DFGRepatch.cpp:
         (JSC::DFG::dfgResetGetByID):
         (JSC::DFG::dfgResetPutByID):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::cachedGetById):
         (JSC::DFG::SpeculativeJIT::cachedPutById):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::cachedGetById):
         (JSC::DFG::SpeculativeJIT::cachedPutById):
         * jit/JIT.h:
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::resetPatchGetById):
         (JSC::JIT::resetPatchPutById):
         * jit/JITPropertyAccess32_64.cpp:
         (JSC::JIT::resetPatchGetById):
         (JSC::JIT::resetPatchPutById):
         * jit/JITWriteBarrier.h:
         (JSC::JITWriteBarrierBase::clearToUnusedPointer):
         (JSC::JITWriteBarrierBase::get):
         * jit/UnusedPointer.h: Added.

 2012-12-20  Filip Pizlo  <fpizlo@apple.com>

         DFG shouldn't emit CheckStructure on array accesses if exit profiling tells it not to
         https://bugs.webkit.org/show_bug.cgi?id=105577

         Reviewed by Mark Hahnenberg.

         I don't know why this wasn't there from the beginning.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):

 2012-12-19  Filip Pizlo  <fpizlo@apple.com>

         DFG speculation checks that take JumpList should consolidate OSRExits
         https://bugs.webkit.org/show_bug.cgi?id=105401

         Reviewed by Oliver Hunt.

         Change OSRExitCompilationInfo to always contain a JumpList, and change JumpList
         to be more compact. This way, a speculationCheck that takes a JumpList only has
         to emit one OSRExit structure, and one OSRExit landing pad.

         The downside is that we get less precise information about *where* we exited
         from. So, this also includes changes to the profiler to be more relaxed about
         what an ExitSite is.

         * assembler/AbstractMacroAssembler.h:
         (JumpList):
         * dfg/DFGJITCompiler.cpp:
         (JSC::DFG::JITCompiler::linkOSRExits):
         (JSC::DFG::JITCompiler::link):
         * dfg/DFGJITCompiler.h:
         (DFG):
         (JSC::DFG::JITCompiler::appendExitInfo):
         (JITCompiler):
         * dfg/DFGOSRExitCompilationInfo.h:
         (OSRExitCompilationInfo):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
         (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
         * profiler/ProfilerCompilation.cpp:
         (JSC::Profiler::Compilation::addOSRExitSite):
         * profiler/ProfilerCompilation.h:
         (Compilation):
         * profiler/ProfilerOSRExitSite.cpp:
         (JSC::Profiler::OSRExitSite::toJS):
         * profiler/ProfilerOSRExitSite.h:
         (JSC::Profiler::OSRExitSite::OSRExitSite):
         (JSC::Profiler::OSRExitSite::codeAddress):
         (OSRExitSite):

 2012-12-19  Oliver Hunt  <oliver@apple.com>

         Fix some incorrect tests in testapi.c

         Reviewed by Simon Fraser.

         * API/tests/testapi.c:
         (main):

 2012-12-19  Filip Pizlo  <fpizlo@apple.com>

         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.

         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):

 2012-12-19  Oliver Hunt  <oliver@apple.com>

         Tidy up JSScriptRef API
         https://bugs.webkit.org/show_bug.cgi?id=105470

         Reviewed by Anders Carlsson.

         People found the API's use of a context confusing, so we'll switch to a JSContextGroup based
         API, and drop a number of the unnecessary uses of contexts.

         * API/JSScriptRef.cpp:
         (OpaqueJSScript::globalData):
         (parseScript):
         * API/JSScriptRefPrivate.h:
         * API/tests/testapi.c:
         (main):

 2012-12-19  Alexis Menard  <alexis@webkit.org>

         Implement CSS parsing for CSS transitions unprefixed.
         https://bugs.webkit.org/show_bug.cgi?id=104804

         Reviewed by Dean Jackson.

         Add a new flag ENABLE_CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED
         to cover the work of unprefixing Transforms, Animations and
         Transitions. It will let the possibility of each ports to turn it off
         in their release branches until we're confident that these CSS
         properties are ready to be unprefixed.

         * Configurations/FeatureDefines.xcconfig:

 2012-12-18  Filip Pizlo  <fpizlo@apple.com>

         Proxies should set InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero
         https://bugs.webkit.org/show_bug.cgi?id=105379

         Reviewed by Gavin Barraclough.

         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):

 2012-12-18  Oliver Hunt  <oliver@apple.com>

         Add a JSScriptRef API to JSC so that we can allow API users to avoid the full cost of reparsing everytime the execute a script.
         https://bugs.webkit.org/show_bug.cgi?id=105340

         Reviewed by Gavin Barraclough.

         This patch adds a (currently private) API to allow users of the JSC API to create a JSScript object
         that references a reusable version of the script that they wish to evaluate.  This can help us avoid
         numeorus copies that are otherwise induced by our existing API and gives us an opaque object that we
         can hang various caches off.  Currently this is simply a simple SourceProvider, but in future we may
         be able to add more caching without requiring new/replacement APIs.

         * API/JSScriptRef.cpp: Added.
         * API/JSScriptRefPrivate.h: Added.
         * API/tests/testapi.c:
           Add tests for new APIs.
         * JavaScriptCore.xcodeproj/project.pbxproj:

 2012-12-18  Filip Pizlo  <fpizlo@apple.com>

         DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode incorrectly checks for non-array array storage when it should be checking for array array storage
         https://bugs.webkit.org/show_bug.cgi?id=105365

         Reviewed by Mark Hahnenberg.

         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):

 2012-12-18  Filip Pizlo  <fpizlo@apple.com>

         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):

 2012-12-18  Filip Pizlo  <fpizlo@apple.com>

         Convert indexingTypeToString to IndexingTypeDump
         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):

 2012-12-18  Beth Dakin  <bdakin@apple.com>

         https://bugs.webkit.org/show_bug.cgi?id=102579
         [mac] Enable scaled cursors

         Reviewed by Dean Jackson.

         * Configurations/FeatureDefines.xcconfig:

 2012-12-18  Mark Hahnenberg  <mhahnenberg@apple.com>

         Restrictions on oversize CopiedBlock allocations should be relaxed
         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):

 2012-12-18  Joseph Pecoraro  <pecoraro@apple.com>

         [Mac] Add Build Phase to Check Headers for Inappropriate Macros (Platform.h macros)
         https://bugs.webkit.org/show_bug.cgi?id=104279

         Reviewed by David Kilzer.

         Add a build phase to check the public JavaScriptCore headers for
         inappropriate macros.

         * JavaScriptCore.xcodeproj/project.pbxproj:

 2012-12-18  Michael Saboff  <msaboff@apple.com>

         [Qt] Fix the ARMv7 build after r137976
         https://bugs.webkit.org/show_bug.cgi?id=105270

         Reviewed by Csaba Osztrogonác.

         Add default value for Jump parameter to fix build.

         * assembler/AbstractMacroAssembler.h:
         (JSC::AbstractMacroAssembler::Jump::Jump):

 2012-12-17  Geoffrey Garen  <ggaren@apple.com>

         Constant fold !{number} in the parser
         https://bugs.webkit.org/show_bug.cgi?id=105232

         Reviewed by Filip Pizlo.

         Typically, we wait for hot execution and constant fold in the DFG.
         However, !0 and !1 are common enough in minifiers that it can be good
         to get them out of the way early, for faster/smaller parsing and startup.

         * parser/ASTBuilder.h:
         (JSC::ASTBuilder::createLogicalNot): !{literal} is super simple, especially
         since there's no literal form of NaN or Inf.

 2012-12-17  Filip Pizlo  <fpizlo@apple.com>

         DFG is too aggressive eliding overflow checks for additions involving large constants
         https://bugs.webkit.org/show_bug.cgi?id=105239

         Reviewed by Gavin Barraclough.

         If we elide overflow checks on an addition (or subtraction) involving a larger-than-2^32 immediate,
         then make sure that the non-constant child of the addition knows that he's got to do an overflow
         check, by flowing the UsedAsNumber property at him.

         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::addSpeculationMode):
         (Graph):
         (JSC::DFG::Graph::addShouldSpeculateInteger):
         (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):

 2012-12-17  Michael Saboff  <msaboff@apple.com>

         DFG: Refactor DFGCorrectableJumpPoint to reduce size of OSRExit data
         https://bugs.webkit.org/show_bug.cgi?id=105237

         Reviewed by Filip Pizlo.

         Replaced DFGCorrectableJumpPoint with OSRExitCompilationInfo which is used and kept alive only while we are
         compiling in the DFG.  Moved the patchable branch offset directly into OSRExit.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * assembler/AbstractMacroAssembler.h:
         * dfg/DFGCorrectableJumpPoint.cpp: Removed.
         * dfg/DFGCorrectableJumpPoint.h: Removed.
         * dfg/DFGJITCompiler.cpp:
         (JSC::DFG::JITCompiler::linkOSRExits):
         (JSC::DFG::JITCompiler::link):
         * dfg/DFGJITCompiler.h:
         (JSC::DFG::JITCompiler::appendExitJump):
         (JITCompiler):
         * dfg/DFGOSRExit.cpp:
         (JSC::DFG::OSRExit::OSRExit):
         (JSC::DFG::OSRExit::setPatchableCodeOffset):
         (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump):
         (JSC::DFG::OSRExit::codeLocationForRepatch):
         (JSC::DFG::OSRExit::correctJump):
         * dfg/DFGOSRExit.h:
         (OSRExit):
         * dfg/DFGOSRExitCompilationInfo.h: Added.
         (OSRExitCompilationInfo):
         (JSC::DFG::OSRExitCompilationInfo::OSRExitCompilationInfo):
         (JSC::DFG::OSRExitCompilationInfo::failureJump):
         * dfg/DFGOSRExitCompiler.cpp:
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):

 2012-12-17  Filip Pizlo  <fpizlo@apple.com>

         DFG is too aggressive with eliding overflow checks in loops
         https://bugs.webkit.org/show_bug.cgi?id=105226

         Reviewed by Mark Hahnenberg and Oliver Hunt.

         If we see a variable's live range cross basic block boundaries, conservatively assume that it may
         be part of a data-flow back-edge, and as a result, we may have entirely integer operations that
         could lead to the creation of an integer that is out of range of 2^52 (the significand of a double
         float). This does not seem to regress any of the benchmarks we care about, and it fixes the bug.

         In future we may want to actually look at whether or not there was a data-flow back-edge instead
         of being super conservative about it. But we have no evidence, yet, that this would help us on
         real code.

         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):

 2012-12-17  Mark Hahnenberg  <mhahnenberg@apple.com>

         Butterfly::growArrayRight shouldn't be called on null Butterfly objects
         https://bugs.webkit.org/show_bug.cgi?id=105221

         Reviewed by Filip Pizlo.

         Currently we depend upon the fact that Butterfly::growArrayRight works with null Butterfly
         objects purely by coincidence. We should add a new static function that null checks the old
         Butterfly object and creates a new one if it's null, or calls growArrayRight if it isn't for
         use in the couple of places in JSObject that expect such behavior to work.

         * runtime/Butterfly.h:
         (Butterfly):
         * runtime/ButterflyInlines.h:
         (JSC::Butterfly::createOrGrowArrayRight):
         (JSC):
         * runtime/JSObject.cpp:
         (JSC::JSObject::createInitialIndexedStorage):
         (JSC::JSObject::createArrayStorage):

 2012-12-17  Filip Pizlo  <fpizlo@apple.com>

         javascript integer overflow
         https://bugs.webkit.org/show_bug.cgi?id=104967

         Reviewed by Mark Hahnenberg.

         Fix PutScopedVar backward flow.

         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):

 2012-12-16  Filip Pizlo  <fpizlo@apple.com>

         Rationalize array profiling for out-of-bounds and hole cases
         https://bugs.webkit.org/show_bug.cgi?id=105139

         Reviewed by Geoffrey Garen.

         This makes ArrayProfile track whether or not we had out-of-bounds, which allows
         for more precise decision-making in the DFG.

         Also cleaned up ExitKinds for out-of-bounds and hole cases to make it easier to
         look at them in the profiler.

         Slight speed-up (5-8%) on SunSpider/crypto-md5.

         * bytecode/ArrayProfile.cpp:
         (JSC::ArrayProfile::computeUpdatedPrediction):
         (JSC::ArrayProfile::briefDescription):
         * bytecode/ArrayProfile.h:
         (JSC::ArrayProfile::ArrayProfile):
         (JSC::ArrayProfile::addressOfOutOfBounds):
         (JSC::ArrayProfile::expectedStructure):
         (JSC::ArrayProfile::structureIsPolymorphic):
         (JSC::ArrayProfile::outOfBounds):
         (JSC::ArrayProfile::polymorphicStructure):
         * bytecode/CodeBlock.cpp:
         (JSC::dumpChain):
         * bytecode/ExitKind.cpp:
         (JSC::exitKindToString):
         (JSC::exitKindIsCountable):
         * bytecode/ExitKind.h:
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::compile):
         * jit/JIT.h:
         * jit/JITInlines.h:
         (JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::emitSlow_op_get_by_val):
         (JSC::JIT::emitSlow_op_put_by_val):
         * jit/JITPropertyAccess32_64.cpp:
         (JSC::JIT::emitSlow_op_get_by_val):
         (JSC::JIT::emitSlow_op_put_by_val):
         * llint/LowLevelInterpreter32_64.asm:
         * llint/LowLevelInterpreter64.asm:

 2012-12-17  Balazs Kilvady  <kilvadyb@homejinni.com>

         Implement add64 for MIPS assembler after r136601
         https://bugs.webkit.org/show_bug.cgi?id=104106

         Reviewed by Zoltan Herczeg.

         Added add64 function to MacroAssebler of MIPS.

         * assembler/MacroAssemblerMIPS.h:
         (JSC::MacroAssemblerMIPS::add32):
         (JSC::MacroAssemblerMIPS::add64):
         (MacroAssemblerMIPS):

 2012-12-17  Jonathan Liu  <net147@gmail.com>

         Fix Math.pow implementation with MinGW-w64
         https://bugs.webkit.org/show_bug.cgi?id=105087

         Reviewed by Simon Hausmann.

         The MinGW-w64 runtime has different behaviour for pow()
         compared to other C runtimes. This results in the following
         test262 tests failing with the latest MinGW-w64 runtime:
         - S15.8.2.13_A14
         - S15.8.2.13_A16
         - S15.8.2.13_A20
         - S15.8.2.13_A22

         Handle the special cases that are different with MinGW-w64.

         * runtime/MathObject.cpp:
         (JSC::mathPow):

 2012-12-16  Filip Pizlo  <fpizlo@apple.com>

         Bytecode dumping should show rare case profiles
         https://bugs.webkit.org/show_bug.cgi?id=105133

         Reviewed by Geoffrey Garen.

         Refactored the dumper to call dumpBytecodeCommandAndNewLine in just one place,
         rather than in all of the places. Changed the rare case profile getters to use
         tryBinarySearch rather than binarySearch, so that they can be used speculatively
         even if you don't know that the bytecode has rare case profiles. This actually
         increases our assertion level, since it means that in release builds we will get
         null and crash rather than getting some random adjacent profile. And then this
         adds some printing of the rare case profiles.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::printUnaryOp):
         (JSC::CodeBlock::printBinaryOp):
         (JSC::CodeBlock::printConditionalJump):
         (JSC::CodeBlock::printCallOp):
         (JSC::CodeBlock::printPutByIdOp):
         (JSC::CodeBlock::beginDumpProfiling):
         (JSC):
         (JSC::CodeBlock::dumpValueProfiling):
         (JSC::CodeBlock::dumpArrayProfiling):
         (JSC::CodeBlock::dumpRareCaseProfile):
         (JSC::CodeBlock::dumpBytecode):
         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
         (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset):

 2012-12-13  Filip Pizlo  <fpizlo@apple.com>

         Attempt to rationalize and simplify WTF::binarySearch
         https://bugs.webkit.org/show_bug.cgi?id=104890

         Reviewed by Maciej Stachowiak.

         Switch to using the new binarySearch() API. No change in behavior.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::bytecodeOffset):
         (JSC::CodeBlock::codeOriginForReturn):
         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::getStubInfo):
         (JSC::CodeBlock::getByValInfo):
         (JSC::CodeBlock::getCallLinkInfo):
         (JSC::CodeBlock::dfgOSREntryDataForBytecodeIndex):
         (JSC::CodeBlock::valueProfileForBytecodeOffset):
         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
         (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset):
         * dfg/DFGGraph.h:
         (JSC::DFG::Graph::blockIndexForBytecodeOffset):
         * dfg/DFGMinifiedGraph.h:
         (JSC::DFG::MinifiedGraph::at):
         * dfg/DFGOSRExitCompiler32_64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * dfg/DFGOSRExitCompiler64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         * profiler/ProfilerBytecodeSequence.cpp:
         (JSC::Profiler::BytecodeSequence::indexForBytecodeIndex):

 2012-12-13  Filip Pizlo  <fpizlo@apple.com>

         Don't assert that flags <= 0x3ff in JSTypeInfo
         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):

 2012-12-13  Filip Pizlo  <fpizlo@apple.com>

         Named lookups on HTML documents produce inconsistent results in JavaScriptCore bindings
         https://bugs.webkit.org/show_bug.cgi?id=104623

         Reviewed by Geoffrey Garen.

         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):

 2012-12-13  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed, roll out http://trac.webkit.org/changeset/137683.
         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):

 2012-13-11  Oliver Hunt  <oliver@apple.com>

         Support op_typeof in the DFG
         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.

 2012-12-12  Filip Pizlo  <fpizlo@apple.com>

         OSR exit compiler should emit code for resetting the execution counter that matches the logic of ExecutionCounter.cpp
         https://bugs.webkit.org/show_bug.cgi?id=104791

         Reviewed by Oliver Hunt.

         The OSR exit compiler wants to make it so that every OSR exit does the equivalent
         of:

         codeBlock->m_jitExecuteCounter.setNewThreshold(
             codeBlock->counterValueForOptimizeAfterLongWarmUp());

         This logically involves:

         - Resetting the counter to zero.
         - Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
         - Figuring out the scaled threshold, subtracting the count so far (which is zero,
           so this part is a no-op), and clipping (ExecuteCounter::clippedThreshold()).
         - Setting m_counter to the negated clipped threshold.
         - Setting m_totalCount to the previous count so far (which is zero) plus the
           clipped threshold.

         Because of the reset, which sets the count-so-far to zero, this amounts to:

         - Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
         - Figuring out the clipped scaled threshold.
         - Setting m_counter to the negated clipped scaled threshold.
         - Setting m_totalCount to the (positive) clipped scaled threshold.

         The code was previously not doing this, but now is. This is performance neutral.
         The only change in behavior over what the code was previously doing (setting the
         m_counter to the negated scaled threshold, without clipping, and then setting
         the m_totalCount to the clipped scaled threshold) is that this will respond more
         gracefully under memory pressure and will ensure that we get more value profile
         LUBing before triggering recompilation. More LUBing is almost always a good
         thing.

         * dfg/DFGOSRExitCompiler.cpp:
         (JSC::DFG::OSRExitCompiler::handleExitCounts):

 2012-12-12  Ilya Tikhonovsky  <loislo@chromium.org>

         Web Inspector: Native Memory Instrumentation: remove fake root MemoryObjectInfo.
         https://bugs.webkit.org/show_bug.cgi?id=104796

         Reviewed by Yury Semikhatsky.

         It was not a good idea to introduce a fake root MemoryObjectInfo.
         It makes a problem when we visit an object without its own MemoryObjectType.

         Example: RenderBox has a global pointer to a hash map.
         HashMap doesn't have its own object type because it is a generic container.
         It will inherit object type from the fake root memory object info.
         The same could happen for another container in another class with other MemoryObjectType.

         This fact forces me to create custom process method for root objects
         because they need to have their own MemoryObjectInfo with customisable memory object type.

         Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
         for instrumented and not instrumented object classes.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-12-11  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

         Implement add64 for ARM traditional assembler after r136601
         https://bugs.webkit.org/show_bug.cgi?id=104103

         Reviewed by Zoltan Herczeg.

         Implement add64 function for ARM traditional macroassembler.

         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::add64):
         (MacroAssemblerARM):

 2012-12-11  Filip Pizlo  <fpizlo@apple.com>

         Unreviewed. Fix build with DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE).

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::tallyFrequentExitSites):

 2012-12-11  Filip Pizlo  <fpizlo@apple.com>

         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.

         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:

 2012-12-11  Oswald Buddenhagen  <oswald.buddenhagen@digia.com>

         [Qt] delete dead include paths

         Reviewed by Simon Hausmann.

         followup to https://bugs.webkit.org/show_bug.cgi?id=93446

         * JavaScriptCore.pri:

 2012-12-11  Julien BRIANCEAU   <jbrianceau@nds.com>

         Implement add64 for SH4 assembler to fix build after r136601
         https://bugs.webkit.org/show_bug.cgi?id=104377

         Reviewed by Zoltan Herczeg.

         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::add64):
         (MacroAssemblerSH4):

 2012-12-10  Yury Semikhatsky  <yurys@chromium.org>

         Memory instrumentation: make sure each edge is reported only once
         https://bugs.webkit.org/show_bug.cgi?id=104630

         Reviewed by Pavel Feldman.

         Changed exported symbols for MemoryInstrumentation.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-12-10  Filip Pizlo  <fpizlo@apple.com>

         Don't OSR exit just because a string is a rope
         https://bugs.webkit.org/show_bug.cgi?id=104621

         Reviewed by Michael Saboff.

         Slight SunSpider speed-up at around the 0.7% level. This patch does the obvious
         thing of calling a slow path to resolve ropes rather than OSR exiting if the
         string is a rope.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGArrayMode.h:
         (JSC::DFG::ArrayMode::getIndexedPropertyStorageMayTriggerGC):
         (ArrayMode):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::putStructureStoreElimination):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
         * dfg/DFGSpeculativeJIT.h:
         (JSC::DFG::SpeculativeJIT::callOperation):

 2012-12-10  Gustavo Noronha Silva  <gns@gnome.org>

         Unreviewed distcheck fix.

         * GNUmakefile.list.am:

 2012-12-10  Filip Pizlo  <fpizlo@apple.com>

         JSC profiling and debug dump code should use inferred names when possible
         https://bugs.webkit.org/show_bug.cgi?id=104519

         Reviewed by Oliver Hunt.

         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:

 2012-12-09  Filip Pizlo  <fpizlo@apple.com>

         Profiler should say things about OSR exits
         https://bugs.webkit.org/show_bug.cgi?id=104497

         Reviewed by Oliver Hunt.

         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:

 2012-12-10  Alexis Menard  <alexis@webkit.org>

         [CSS3 Backgrounds and Borders] Remove CSS3_BACKGROUND feature flag.
         https://bugs.webkit.org/show_bug.cgi?id=104539

         Reviewed by Antonio Gomes.

         As discussed on webkit-dev it is not needed to keep this feature flag
         as support for <position> type is a small feature that is already
         implemented by three other UAs. It was useful while landing this
         feature as partial bits were landed one after one.

         * Configurations/FeatureDefines.xcconfig:

 2012-12-09  Filip Pizlo  <fpizlo@apple.com>

         DFG ArrayPush/Pop should not pass their second child as the index for blessArrayOperation()
         https://bugs.webkit.org/show_bug.cgi?id=104500

         Reviewed by Oliver Hunt.

         Slight across-the-board speed-up.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupNode):

 2012-12-08  Filip Pizlo  <fpizlo@apple.com>

         JSC should scale the optimization threshold for a code block according to the cost of compiling it
         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:

 2012-12-07  Jonathan Liu  <net147@gmail.com>

         Add missing forward declaration for JSC::ArrayAllocationProfile
         https://bugs.webkit.org/show_bug.cgi?id=104425

         Reviewed by Kentaro Hara.

         The header for the JSC::ArrayConstructor class is missing a forward
         declaration for the JSC::ArrayAllocationProfile class which causes
         compilation to fail when compiling with MinGW-w64.

         * runtime/ArrayConstructor.h:
         (JSC):

 2012-12-07  Jonathan Liu  <net147@gmail.com>

         Add missing const qualifier to JSC::CodeBlock::getJITType()
         https://bugs.webkit.org/show_bug.cgi?id=104424

         Reviewed by Laszlo Gombos.

         JSC::CodeBlock::getJITType() has the const qualifier when JIT is
         enabled but is missing the const qualifier when JIT is disabled.

         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::getJITType):

 2012-12-07  Oliver Hunt  <oliver@apple.com>

         Make function code cache proportional to main codeblock cache
         https://bugs.webkit.org/show_bug.cgi?id=104420

         Reviewed by Geoffrey Garen.

         Makes the constants determining the recently used function cache proportional
         to the number of root codeblocks in the cache.  Also renames the constants to
         make them more clear.

         * runtime/CodeCache.h:

 2012-12-06  Filip Pizlo  <fpizlo@apple.com>

         Strange results calculating a square root in a loop
         https://bugs.webkit.org/show_bug.cgi?id=104247
         <rdar://problem/12826880>

         Reviewed by Oliver Hunt.

         Fixed the CFG simplification phase to ignore dead GetLocals in the first of the blocks
         under the merge. This fixes the assertion, and is also cleaner: our general rule is
         to not "revive" things that we've already proved to be dead.

         Also fixed some rotted debug code.

         * dfg/DFGCFGSimplificationPhase.cpp:
         (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):

 2012-12-07  Geoffrey Garen  <ggaren@apple.com>

         Crash in JSC::Bindings::RootObject::globalObject() sync'ing notes in Evernote
         https://bugs.webkit.org/show_bug.cgi?id=104321
         <rdar://problem/12770497>

         Reviewed by Sam Weinig.

         Work around a JSValueUnprotect(NULL) in Evernote.

         * API/JSValueRef.cpp:
         (evernoteHackNeeded):
         (JSValueUnprotect):

 2012-12-06  Filip Pizlo  <fpizlo@apple.com>

         Incorrect inequality for checking whether a statement is within bounds of a handler
         https://bugs.webkit.org/show_bug.cgi?id=104313
         <rdar://problem/12808934>

         Reviewed by Geoffrey Garen.

         The most relevant change is in handlerForBytecodeOffset(), which fixes the inequality
         used for checking whether a handler is pertinent to the current instruction. '<' is
         correct, but '<=' isn't, since the 'end' is not inclusive.

         Also found, and addressed, a benign goof in how the finally inliner works: sometimes
         we will have end > start. This falls out naturally from how the inliner works and how
         we pop scopes in the bytecompiler, but it's sufficiently surprising that, to avoid any
         future confusion, I added a comment and some code to prune those handlers out. Because
         of how the handler resolution works, these handlers would have been skipped anyway.

         Also made various fixes to debugging code, which was necessary for tracking this down.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::handlerForBytecodeOffset):
         * bytecompiler/BytecodeGenerator.cpp:
         (JSC::BytecodeGenerator::generate):
         * bytecompiler/Label.h:
         (JSC::Label::bind):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::throwException):
         * llint/LLIntExceptions.cpp:
         (JSC::LLInt::interpreterThrowInCaller):
         (JSC::LLInt::returnToThrow):
         (JSC::LLInt::callToThrow):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         (JSC::LLInt::handleHostCall):

 2012-12-06  Rick Byers  <rbyers@chromium.org>

         CSS cursor property should support webkit-image-set
         https://bugs.webkit.org/show_bug.cgi?id=99493

         Reviewed by Beth Dakin.

         Add ENABLE_MOUSE_CURSOR_SCALE (disabled by default)

         * Configurations/FeatureDefines.xcconfig:

 2012-12-06  Laszlo Gombos  <l.gombos@samsung.com>

         [CMake] Consolidate list of files to build for JavaScriptCore
         https://bugs.webkit.org/show_bug.cgi?id=104287

         Reviewed by Gyuyoung Kim.

         Add MemoryStatistics.cpp and ExecutableAllocator.cpp to the common
         list of files and remove them from the port specific lists.

         * CMakeLists.txt:
         * PlatformBlackBerry.cmake:
         * PlatformEfl.cmake:
         * PlatformWinCE.cmake:

 2012-12-06  Oliver Hunt  <oliver@apple.com>

         Tell heap that we've released all the compiled code.

         Reviewed by Geoff Garen.

         When we discard compiled code, inform the heap that we've
         released an entire object graph.  This informs the heap that
         it might want to perform a GC soon.

         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::discardAllCode):

 2012-12-06  Laszlo Gombos  <l.gombos@samsung.com>

         [EFL] Remove ENABLE_GLIB_SUPPORT CMake variable
         https://bugs.webkit.org/show_bug.cgi?id=104278

         Reviewed by Brent Fulgham.

         The conditional is not required as it is always set for EFL.

         * PlatformEfl.cmake:

 2012-12-06  Oliver Hunt  <oliver@apple.com>

         Build fix, last patch rolled out logic that is now needed on ToT.

         * parser/ASTBuilder.h:
         (ASTBuilder):
         (JSC::ASTBuilder::setFunctionStart):
         * parser/Nodes.h:
         (JSC::FunctionBodyNode::setFunctionStart):
         (JSC::FunctionBodyNode::functionStart):
         (FunctionBodyNode):
         * parser/Parser.cpp:
         (JSC::::parseFunctionInfo):
         * parser/SyntaxChecker.h:
         (JSC::SyntaxChecker::setFunctionStart):

 2012-12-05  Oliver Hunt  <oliver@apple.com>

         Remove harmful string->function cache
         https://bugs.webkit.org/show_bug.cgi?id=104193

         Reviewed by Alexey Proskuryakov.

         Remove the string->function code cache that turned out to actually
         be quite harmful.

         * runtime/CodeCache.cpp:
         (JSC::CodeCache::getFunctionCodeBlock):
         * runtime/CodeCache.h:
         (JSC::CodeCache::clear):

 2012-12-05  Halton Huo  <halton.huo@intel.com>

         [CMake] Unify coding style for CMake files
         https://bugs.webkit.org/show_bug.cgi?id=103605

         Reviewed by Laszlo Gombos.

         Update cmake files(.cmake, CMakeLists.txt) with following style rules:
         1. Indentation
         1.1 Use spaces, not tabs.
         1.2 Four spaces as indent.
         2. Spacing
         2.1 Place one space between control statements and their parentheses.
             For eg, if (), else (), elseif (), endif (), foreach (),
             endforeach (), while (), endwhile (), break ().
         2.2 Do not place spaces between function and macro statements and
             their parentheses. For eg, macro(), endmacro(), function(),
             endfunction().
         2.3 Do not place spaces between a command or function or macro and its
             parentheses, or between a parenthesis and its content. For eg,
             message("testing") not message( "testing") or message ("testing" )
         2.4 No space at line ending.
         3. Lowercase when call commands macros and functions. For eg,
            add_executable() not ADD_EXECUTABLE(), set() not SET().

         * CMakeLists.txt:
         * PlatformBlackBerry.cmake:
         * PlatformEfl.cmake:
         * PlatformWinCE.cmake:
         * shell/CMakeLists.txt:
         * shell/PlatformBlackBerry.cmake:
         * shell/PlatformEfl.cmake:
         * shell/PlatformWinCE.cmake:

 2012-12-05  Oliver Hunt  <oliver@apple.com>

         Empty parse cache when receiving a low memory warning
         https://bugs.webkit.org/show_bug.cgi?id=104161

         Reviewed by Filip Pizlo.

         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):

 2012-12-05  Filip Pizlo  <fpizlo@apple.com>

         JSC profiler should not count executions of op_call_put_result because doing so changes DFG codegen
         https://bugs.webkit.org/show_bug.cgi?id=104102

         Reviewed by Oliver Hunt.

         This removes op_call_put_result from profiling, since profiling it has an effect on
         codegen. This fix enables all of SunSpider, V8, and Kraken to be profiled with the
         new profiler.

         To make this all fit together, the profiler now also reports in its output the exact
         bytecode opcode name for each instruction (in addition to the stringified dump of that
         bytecode), so that tools that grok the output can take note of op_call_put_result and
         work around the fact that it has no counts.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * jit/JIT.cpp:
         (JSC::JIT::privateCompileMainPass):
         * profiler/ProfilerBytecode.cpp:
         (JSC::Profiler::Bytecode::toJS):
         * profiler/ProfilerBytecode.h:
         (JSC::Profiler::Bytecode::Bytecode):
         (JSC::Profiler::Bytecode::opcodeID):
         (Bytecode):
         * profiler/ProfilerDatabase.cpp:
         (JSC::Profiler::Database::ensureBytecodesFor):
         * runtime/CommonIdentifiers.h:

 2012-12-04  Filip Pizlo  <fpizlo@apple.com>

         display-profiler-output should be able to show source code
         https://bugs.webkit.org/show_bug.cgi?id=104073

         Reviewed by Oliver Hunt.

         Modify the profiler database to store source code. For functions, we store the
         function including the function signature.

         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::unlinkedCodeBlock):
         (CodeBlock):
         * profiler/ProfilerBytecodes.cpp:
         (JSC::Profiler::Bytecodes::Bytecodes):
         (JSC::Profiler::Bytecodes::toJS):
         * profiler/ProfilerBytecodes.h:
         (Bytecodes):
         (JSC::Profiler::Bytecodes::sourceCode):
         * profiler/ProfilerDatabase.cpp:
         (JSC::Profiler::Database::addBytecodes):
         (JSC::Profiler::Database::ensureBytecodesFor):
         * profiler/ProfilerDatabase.h:
         (Database):
         * runtime/CommonIdentifiers.h:
         * runtime/Executable.h:
         (FunctionExecutable):
         (JSC::FunctionExecutable::unlinkedExecutable):

 2012-12-02  Filip Pizlo  <fpizlo@apple.com>

         JSC should be able to report profiling data associated with the IR dumps and disassembly
         https://bugs.webkit.org/show_bug.cgi?id=102999

         Reviewed by Gavin Barraclough.

         Added a new profiler to JSC. It's simply called "Profiler" in anticipation of it
         ultimately replacing the previous profiling infrastructure. This profiler counts the
         number of times that a bytecode executes in various engines, and will record both the
         counts and all disassembly and bytecode dumps, into a database that can be at any
         time turned into either a JS object using any global object or global data of your
         choice, or can be turned into a JSON string, or saved to a file.

         Currently the only use of this is the new '-p <file>' flag to the jsc command-line.

         The profiler is always compiled in and normally incurs no execution time cost, but is
         only activated when you create a Profiler::Database and install it in
         JSGlobalData::m_perBytecodeProfiler. From that point on, all code blocks will be
         compiled along with disassembly and bytecode dumps stored into the Profiler::Database,
         and all code blocks will have execution counts, which are also stored in the database.
         The database will continue to keep information about code blocks alive even after they
         are otherwise GC'd.

         This currently still has some glitches, like the fact that it only counts executions
         in the JITs. Doing execution counting in the LLInt might require a bit of a rethink
         about how the counting is expressed - currently it is implicit in bytecode, so there
         is no easy way to "turn it on" in the LLInt. Also, right now there is no information
         recorded about OSR exits or out-of-line stubs. But, even so, it's quite cool, and
         gives you a peek into what JSC is doing that would otherwise not be possible.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::~CodeBlock):
         * bytecode/CodeBlock.h:
         (CodeBlock):
         (JSC::CodeBlock::baselineVersion):
         * bytecode/CodeOrigin.cpp:
         (JSC::InlineCallFrame::baselineCodeBlock):
         (JSC):
         * bytecode/CodeOrigin.h:
         (InlineCallFrame):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::dump):
         (DFG):
         (JSC::DFG::Disassembler::reportToProfiler):
         (JSC::DFG::Disassembler::dumpHeader):
         (JSC::DFG::Disassembler::append):
         (JSC::DFG::Disassembler::createDumpList):
         * dfg/DFGDisassembler.h:
         (Disassembler):
         (JSC::DFG::Disassembler::DumpedOp::DumpedOp):
         (DumpedOp):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::Graph):
         (JSC::DFG::Graph::dumpCodeOrigin):
         (JSC::DFG::Graph::dump):
         * dfg/DFGGraph.h:
         (Graph):
         * dfg/DFGJITCompiler.cpp:
         (JSC::DFG::JITCompiler::JITCompiler):
         (JSC::DFG::JITCompiler::compile):
         (JSC::DFG::JITCompiler::compileFunction):
         * dfg/DFGNode.h:
         (Node):
         (JSC::DFG::Node::hasExecutionCounter):
         (JSC::DFG::Node::executionCounter):
         * 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):
         * jit/JIT.cpp:
         (JSC::JIT::JIT):
         (JSC::JIT::privateCompileMainPass):
         (JSC::JIT::privateCompile):
         * jit/JIT.h:
         (JIT):
         * jit/JITDisassembler.cpp:
         (JSC::JITDisassembler::dump):
         (JSC::JITDisassembler::reportToProfiler):
         (JSC):
         (JSC::JITDisassembler::dumpHeader):
         (JSC::JITDisassembler::firstSlowLabel):
         (JSC::JITDisassembler::dumpVectorForInstructions):
         (JSC::JITDisassembler::dumpForInstructions):
         (JSC::JITDisassembler::reportInstructions):
         * jit/JITDisassembler.h:
         (JITDisassembler):
         (DumpedOp):
         * jsc.cpp:
         (CommandLine::CommandLine):
         (CommandLine):
         (printUsageStatement):
         (CommandLine::parseArguments):
         (jscmain):
         * profiler/ProfilerBytecode.cpp: Added.
         (Profiler):
         (JSC::Profiler::Bytecode::toJS):
         * profiler/ProfilerBytecode.h: Added.
         (Profiler):
         (Bytecode):
         (JSC::Profiler::Bytecode::Bytecode):
         (JSC::Profiler::Bytecode::bytecodeIndex):
         (JSC::Profiler::Bytecode::description):
         (JSC::Profiler::getBytecodeIndexForBytecode):
         * profiler/ProfilerBytecodes.cpp: Added.
         (Profiler):
         (JSC::Profiler::Bytecodes::Bytecodes):
         (JSC::Profiler::Bytecodes::~Bytecodes):
         (JSC::Profiler::Bytecodes::indexForBytecodeIndex):
         (JSC::Profiler::Bytecodes::forBytecodeIndex):
         (JSC::Profiler::Bytecodes::dump):
         (JSC::Profiler::Bytecodes::toJS):
         * profiler/ProfilerBytecodes.h: Added.
         (Profiler):
         (Bytecodes):
         (JSC::Profiler::Bytecodes::append):
         (JSC::Profiler::Bytecodes::id):
         (JSC::Profiler::Bytecodes::hash):
         (JSC::Profiler::Bytecodes::size):
         (JSC::Profiler::Bytecodes::at):
         * profiler/ProfilerCompilation.cpp: Added.
         (Profiler):
         (JSC::Profiler::Compilation::Compilation):
         (JSC::Profiler::Compilation::~Compilation):
         (JSC::Profiler::Compilation::addDescription):
         (JSC::Profiler::Compilation::executionCounterFor):
         (JSC::Profiler::Compilation::toJS):
         * profiler/ProfilerCompilation.h: Added.
         (Profiler):
         (Compilation):
         (JSC::Profiler::Compilation::bytecodes):
         (JSC::Profiler::Compilation::kind):
         * profiler/ProfilerCompilationKind.cpp: Added.
         (WTF):
         (WTF::printInternal):
         * profiler/ProfilerCompilationKind.h: Added.
         (Profiler):
         (WTF):
         * profiler/ProfilerCompiledBytecode.cpp: Added.
         (Profiler):
         (JSC::Profiler::CompiledBytecode::CompiledBytecode):
         (JSC::Profiler::CompiledBytecode::~CompiledBytecode):
         (JSC::Profiler::CompiledBytecode::toJS):
         * profiler/ProfilerCompiledBytecode.h: Added.
         (Profiler):
         (CompiledBytecode):
         (JSC::Profiler::CompiledBytecode::originStack):
         (JSC::Profiler::CompiledBytecode::description):
         * profiler/ProfilerDatabase.cpp: Added.
         (Profiler):
         (JSC::Profiler::Database::Database):
         (JSC::Profiler::Database::~Database):
         (JSC::Profiler::Database::addBytecodes):
         (JSC::Profiler::Database::ensureBytecodesFor):
         (JSC::Profiler::Database::notifyDestruction):
         (JSC::Profiler::Database::newCompilation):
         (JSC::Profiler::Database::toJS):
         (JSC::Profiler::Database::toJSON):
         (JSC::Profiler::Database::save):
         * profiler/ProfilerDatabase.h: Added.
         (Profiler):
         (Database):
         * profiler/ProfilerExecutionCounter.h: Added.
         (Profiler):
         (ExecutionCounter):
         (JSC::Profiler::ExecutionCounter::ExecutionCounter):
         (JSC::Profiler::ExecutionCounter::address):
         (JSC::Profiler::ExecutionCounter::count):
         * profiler/ProfilerOrigin.cpp: Added.
         (Profiler):
         (JSC::Profiler::Origin::Origin):
         (JSC::Profiler::Origin::dump):
         (JSC::Profiler::Origin::toJS):
         * profiler/ProfilerOrigin.h: Added.
         (JSC):
         (Profiler):
         (Origin):
         (JSC::Profiler::Origin::Origin):
         (JSC::Profiler::Origin::operator!):
         (JSC::Profiler::Origin::bytecodes):
         (JSC::Profiler::Origin::bytecodeIndex):
         (JSC::Profiler::Origin::operator!=):
         (JSC::Profiler::Origin::operator==):
         (JSC::Profiler::Origin::hash):
         (JSC::Profiler::Origin::isHashTableDeletedValue):
         (JSC::Profiler::OriginHash::hash):
         (JSC::Profiler::OriginHash::equal):
         (OriginHash):
         (WTF):
         * profiler/ProfilerOriginStack.cpp: Added.
         (Profiler):
         (JSC::Profiler::OriginStack::OriginStack):
         (JSC::Profiler::OriginStack::~OriginStack):
         (JSC::Profiler::OriginStack::append):
         (JSC::Profiler::OriginStack::operator==):
         (JSC::Profiler::OriginStack::hash):
         (JSC::Profiler::OriginStack::dump):
         (JSC::Profiler::OriginStack::toJS):
         * profiler/ProfilerOriginStack.h: Added.
         (JSC):
         (Profiler):
         (OriginStack):
         (JSC::Profiler::OriginStack::OriginStack):
         (JSC::Profiler::OriginStack::operator!):
         (JSC::Profiler::OriginStack::size):
         (JSC::Profiler::OriginStack::fromBottom):
         (JSC::Profiler::OriginStack::fromTop):
         (JSC::Profiler::OriginStack::isHashTableDeletedValue):
         (JSC::Profiler::OriginStackHash::hash):
         (JSC::Profiler::OriginStackHash::equal):
         (OriginStackHash):
         (WTF):
         * runtime/CommonIdentifiers.h:
         * runtime/ExecutionHarness.h:
         (JSC::prepareForExecution):
         (JSC::prepareFunctionForExecution):
         * runtime/JSGlobalData.cpp:
         (JSC::JSGlobalData::JSGlobalData):
         (JSC::JSGlobalData::~JSGlobalData):
         * runtime/JSGlobalData.h:
         (JSGlobalData):
         * runtime/Options.h:
         (JSC):

 2012-12-04  Filip Pizlo  <fpizlo@apple.com>

         Rename Profiler to LegacyProfiler
         https://bugs.webkit.org/show_bug.cgi?id=104031

         Rubber stamped by Mark Hahnenberg

         Make room in the namespace for https://bugs.webkit.org/show_bug.cgi?id=102999.

         * API/JSProfilerPrivate.cpp:
         (JSStartProfiling):
         (JSEndProfiling):
         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::throwException):
         (JSC::Interpreter::execute):
         (JSC::Interpreter::executeCall):
         (JSC::Interpreter::executeConstruct):
         * jit/JIT.h:
         * jit/JITCode.h:
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION):
         * jit/JITStubs.h:
         (JSC):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
         * profiler/LegacyProfiler.cpp: Added.
         (JSC):
         (JSC::LegacyProfiler::profiler):
         (JSC::LegacyProfiler::startProfiling):
         (JSC::LegacyProfiler::stopProfiling):
         (JSC::dispatchFunctionToProfiles):
         (JSC::LegacyProfiler::willExecute):
         (JSC::LegacyProfiler::didExecute):
         (JSC::LegacyProfiler::exceptionUnwind):
         (JSC::LegacyProfiler::createCallIdentifier):
         (JSC::createCallIdentifierFromFunctionImp):
         * profiler/LegacyProfiler.h: Added.
         (JSC):
         (LegacyProfiler):
         (JSC::LegacyProfiler::currentProfiles):
         * profiler/ProfileGenerator.cpp:
         (JSC::ProfileGenerator::addParentForConsoleStart):
         * profiler/ProfileNode.cpp:
         * profiler/Profiler.cpp: Removed.
         * profiler/Profiler.h: Removed.
         * runtime/JSGlobalData.h:
         (JSC):
         (JSC::JSGlobalData::enabledProfiler):
         (JSGlobalData):
         * runtime/JSGlobalObject.cpp:
         (JSC::JSGlobalObject::~JSGlobalObject):

 2012-12-03  Filip Pizlo  <fpizlo@apple.com>

         DFG should inline code blocks that use scoped variable access
         https://bugs.webkit.org/show_bug.cgi?id=103974

         Reviewed by Oliver Hunt.

         This mostly just turns on something we could have done all along, but also adds a few key
         necessities to make this right:

         1) Constant folding of SkipScope, since if we inline with a known JSFunction* then the
            scope is constant.

         2) Interference analysis for GetLocal<->PutScopedVar and SetLocal<->GetScopedVar.

         This is not meant to be a speed-up on major benchmarks since we don't yet inline most
         closure calls for entirely unrelated reasons. But on toy programs it can be >2x faster.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::getScope):
         (JSC::DFG::ByteCodeParser::parseResolveOperations):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::scopedVarLoadElimination):
         (JSC::DFG::CSEPhase::scopedVarStoreElimination):
         (JSC::DFG::CSEPhase::getLocalLoadElimination):
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         * dfg/DFGCapabilities.h:
         (JSC::DFG::canInlineResolveOperations):

 2012-12-03  Filip Pizlo  <fpizlo@apple.com>

         Replace JSValue::description() with JSValue::dump(PrintStream&)
         https://bugs.webkit.org/show_bug.cgi?id=103866

         Reviewed by Darin Adler.

         JSValue now has a dump() method. Anywhere that you would have wanted to use
         description(), you can either do toCString(value).data(), or if the callee
         is a print()/dataLog() method then you just pass the value directly.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
         * bytecode/CodeBlock.cpp:
         (JSC::valueToSourceString):
         (JSC::CodeBlock::finalizeUnconditionally):
         * bytecode/ValueProfile.h:
         (JSC::ValueProfileBase::dump):
         * bytecode/ValueRecovery.h:
         (JSC::ValueRecovery::dump):
         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::dump):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dump):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::dumpRegisters):
         * jsc.cpp:
         (functionDescribe):
         * llint/LLIntSlowPaths.cpp:
         (JSC::LLInt::llint_trace_value):
         * runtime/JSValue.cpp:
         (JSC::JSValue::dump):
         * runtime/JSValue.h:

 2012-12-04  Filip Pizlo  <fpizlo@apple.com>

         jsc command line tool's support for typed arrays should be robust against array buffer allocation errors
         https://bugs.webkit.org/show_bug.cgi?id=104020
         <rdar://problem/12802478>

         Reviewed by Mark Hahnenberg.

         Check for null buffers, since that's what typed array allocators are supposed to do. WebCore does it,
         and that is indeed the contract of ArrayBuffer and TypedArrayBase.

         * JSCTypedArrayStubs.h:
         (JSC):

 2012-12-03  Peter Rybin  <prybin@chromium.org>

         Web Inspector: make ASSERTION FAILED: foundPropertiesCount == object->size() more useful
         https://bugs.webkit.org/show_bug.cgi?id=103254

         Reviewed by Pavel Feldman.

         Missing symbol WTFReportFatalError is added to the linker list.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-12-03  Alexis Menard  <alexis@webkit.org>

         [Mac] Enable CSS3 background-position offset by default.
         https://bugs.webkit.org/show_bug.cgi?id=103905

         Reviewed by Simon Fraser.

         Turn the flag on by default.

         * Configurations/FeatureDefines.xcconfig:

 2012-12-02  Filip Pizlo  <fpizlo@apple.com>

         DFG should trigger rage conversion from double to contiguous if it sees a GetByVal on Double being used in an integer context
         https://bugs.webkit.org/show_bug.cgi?id=103858

         Reviewed by Gavin Barraclough.

         A rage conversion from double to contiguous is one where you try to convert each
         double to an int32.

         This is probably not the last we'll hear of rage conversion from double to contiguous.
         It may be better to do this right during parsing, which will result in fewer cases of
         Arrayification. But even so, this looks like a straight win already - 1% speed-up on
         Kraken, no major regression anywhere else.

         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGArrayMode.cpp:
         (JSC::DFG::ArrayMode::refine):
         (JSC::DFG::arrayConversionToString):
         (JSC::DFG::ArrayMode::dump):
         (WTF):
         (WTF::printInternal):
         * dfg/DFGArrayMode.h:
         (JSC::DFG::ArrayMode::withConversion):
         (ArrayMode):
         (JSC::DFG::ArrayMode::doesConversion):
         (WTF):
         * dfg/DFGFixupPhase.cpp:
         (JSC::DFG::FixupPhase::fixupBlock):
         (JSC::DFG::FixupPhase::fixupNode):
         (JSC::DFG::FixupPhase::checkArray):
         (FixupPhase):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dump):
         * dfg/DFGNodeFlags.h:
         (DFG):
         * dfg/DFGOperations.cpp:
         * dfg/DFGOperations.h:
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::arrayify):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):
         * runtime/JSObject.cpp:
         (JSC):
         (JSC::JSObject::genericConvertDoubleToContiguous):
         (JSC::JSObject::convertDoubleToContiguous):
         (JSC::JSObject::rageConvertDoubleToContiguous):
         (JSC::JSObject::ensureContiguousSlow):
         (JSC::JSObject::rageEnsureContiguousSlow):
         * runtime/JSObject.h:
         (JSObject):
         (JSC::JSObject::rageEnsureContiguous):

 2012-12-02  Filip Pizlo  <fpizlo@apple.com>

         DFG CSE should not keep alive things that aren't relevant to OSR
         https://bugs.webkit.org/show_bug.cgi?id=103849

         Reviewed by Oliver Hunt.

         Most Phantom nodes are inserted by CSE, and by default have the same children as the
         node that CSE had eliminated. This change makes CSE inspect all Phantom nodes (both
         those it creates and those that were created by other phases) to see if they have
         children that are redundant - i.e. children that are not interesting to OSR, which
         is the only reason why Phantoms exist in the first place. Being relevant to OSR is
         defined as one of: (1) you're a Phi, (2) you're a SetLocal, (3) somewhere between
         your definition and the Phantom there was a SetLocal that referred to you.

         This is a slight speed-up in a few places.

         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::CSEPhase):
         (JSC::DFG::CSEPhase::run):
         (JSC::DFG::CSEPhase::performSubstitution):
         (CSEPhase):
         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
         (JSC::DFG::CSEPhase::setReplacement):
         (JSC::DFG::CSEPhase::eliminate):
         (JSC::DFG::CSEPhase::performNodeCSE):
         (JSC::DFG::CSEPhase::performBlockCSE):

 2012-12-02  Filip Pizlo  <fpizlo@apple.com>

         It should be possible to build and run with DFG_ENABLE(PROPAGATION_VERBOSE)
         https://bugs.webkit.org/show_bug.cgi?id=103848

         Reviewed by Sam Weinig.

         Fix random dataLog() and print() statements.

         * dfg/DFGArgumentsSimplificationPhase.cpp:
         (JSC::DFG::ArgumentsSimplificationPhase::run):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dumpBlockHeader):
         * dfg/DFGPredictionPropagationPhase.cpp:
         (JSC::DFG::PredictionPropagationPhase::propagate):
         * dfg/DFGStructureCheckHoistingPhase.cpp:
         (JSC::DFG::StructureCheckHoistingPhase::run):

 2012-12-01  Filip Pizlo  <fpizlo@apple.com>

         CodeBlock should be able to dump bytecode to something other than WTF::dataFile()
         https://bugs.webkit.org/show_bug.cgi?id=103832

         Reviewed by Oliver Hunt.

         Add a PrintStream& argument to all of the CodeBlock bytecode dumping methods.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpBytecodeCommentAndNewLine):
         (JSC::CodeBlock::printUnaryOp):
         (JSC::CodeBlock::printBinaryOp):
         (JSC::CodeBlock::printConditionalJump):
         (JSC::CodeBlock::printGetByIdOp):
         (JSC::dumpStructure):
         (JSC::dumpChain):
         (JSC::CodeBlock::printGetByIdCacheStatus):
         (JSC::CodeBlock::printCallOp):
         (JSC::CodeBlock::printPutByIdOp):
         (JSC::CodeBlock::printStructure):
         (JSC::CodeBlock::printStructures):
         (JSC::CodeBlock::dumpBytecode):
         * bytecode/CodeBlock.h:
         (CodeBlock):
         * jit/JITDisassembler.cpp:
         (JSC::JITDisassembler::dumpForInstructions):

 2012-11-30  Pierre Rossi  <pierre.rossi@gmail.com>

         [Qt] Unreviewed speculative Mac build fix after r136232

         Update the include path so that LLIntAssembly.h is picked up.
         The bot didn't break until later when a clean build was triggered.

         * JavaScriptCore.pri:

 2012-11-30  Oliver Hunt  <oliver@apple.com>

         Optimise more cases of op_typeof
         https://bugs.webkit.org/show_bug.cgi?id=103783

         Reviewed by Mark Hahnenberg.

         Increase our coverage of typeof based typechecks by
         making sure that the codegenerators always uses
         consistent operand ordering when feeding typeof operations
         into equality operations.

         * bytecompiler/NodesCodegen.cpp:
         (JSC::BinaryOpNode::emitBytecode):
         (JSC::EqualNode::emitBytecode):
         (JSC::StrictEqualNode::emitBytecode):

 2012-11-30  Filip Pizlo  <fpizlo@apple.com>

         Rationalize and clean up DFG handling of scoped accesses
         https://bugs.webkit.org/show_bug.cgi?id=103715

         Reviewed by Oliver Hunt.

         Previously, we had a GetScope node that specified the depth to which you wanted
         to travel to get a JSScope, and the backend implementation of the node would
         perform all of the necessary footwork, including potentially skipping the top
         scope if necessary, and doing however many loads were needed. But there were
         strange things. First, if you had accesses at different scope depths, then the
         loads to get to the common depth could not be CSE'd - CSE would match only
         GetScope's that had identical depth. Second, GetScope would be emitted even if
         we already had the scope, for example in put_to_base. And finally, even though
         the ResolveOperations could tell us whether or not we had to skip the top scope,
         the backend would recompute this information itself, often pessimistically.

         This eliminates GetScope and replaces it with the following:

         GetMyScope: just get the JSScope from the call frame header. This will forever
         mean getting the JSScope associated with the machine call frame; it will not
         mean getting the scope of an inlined function. Or at least that's the intent.

         SkipTopScope: check if there is an activation, and if so, skip a scope. This
         takes a scope as a child and returns a scope.

         SkipScope: skip one scope level.

         The bytecode parser now emits the right combination of the above, and
         potentially emits multiple SkipScope's, based on the ResolveOperations.

         This change also includes some fixups to debug logging. We now always print
         the ExecutableBase* in addition to the CodeBlock* in the CodeBlock's dump,
         and we are now more verbose when dumping CodeOrigins and InlineCallFrames.

         This is performance-neutral. It's just meant to be a clean-up.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dumpAssumingJITType):
         * bytecode/CodeOrigin.cpp:
         (JSC::CodeOrigin::inlineStack):
         (JSC::CodeOrigin::dump):
         (JSC):
         (JSC::InlineCallFrame::dump):
         * bytecode/CodeOrigin.h:
         (CodeOrigin):
         (InlineCallFrame):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::execute):
         * dfg/DFGByteCodeParser.cpp:
         (ByteCodeParser):
         (JSC::DFG::ByteCodeParser::getScope):
         (DFG):
         (JSC::DFG::ByteCodeParser::parseResolveOperations):
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGCSEPhase.cpp:
         (JSC::DFG::CSEPhase::scopedVarLoadElimination):
         (JSC::DFG::CSEPhase::scopedVarStoreElimination):
         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
         (JSC::DFG::CSEPhase::setLocalStoreElimination):
         (JSC::DFG::CSEPhase::performNodeCSE):
         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::dump):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dumpCodeOrigin):
         (JSC::DFG::Graph::dumpBlockHeader):
         * dfg/DFGNode.h:
         (Node):
         * 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):
         * jit/JITDisassembler.cpp:
         (JSC::JITDisassembler::dump):

 2012-11-30  Oliver Hunt  <oliver@apple.com>

         Add direct string->function code cache
         https://bugs.webkit.org/show_bug.cgi?id=103764

         Reviewed by Michael Saboff.

         A fairly logically simple patch.  We now track the start of the
         unique portion of a functions body, and use that as our key for
         unlinked function code.  This allows us to cache identical code
         in different contexts, leading to a small but consistent improvement
         on the benchmarks we track.

         * bytecode/UnlinkedCodeBlock.cpp:
         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
         * bytecode/UnlinkedCodeBlock.h:
         (JSC::UnlinkedFunctionExecutable::functionStartOffset):
         (UnlinkedFunctionExecutable):
         * parser/ASTBuilder.h:
         (ASTBuilder):
         (JSC::ASTBuilder::setFunctionStart):
         * parser/Nodes.cpp:
         * parser/Nodes.h:
         (JSC::FunctionBodyNode::setFunctionStart):
         (JSC::FunctionBodyNode::functionStart):
         (FunctionBodyNode):
         * parser/Parser.cpp:
         (JSC::::parseFunctionInfo):
         * parser/Parser.h:
         (JSC::Parser::findCachedFunctionInfo):
         * parser/SyntaxChecker.h:
         (JSC::SyntaxChecker::setFunctionStart):
         * runtime/CodeCache.cpp:
         (JSC::CodeCache::generateFunctionCodeBlock):
         (JSC::CodeCache::getFunctionCodeBlock):
         (JSC::CodeCache::usedFunctionCode):
         * runtime/CodeCache.h:

 2012-11-30  Allan Sandfeld Jensen  <allan.jensen@digia.com>

         Crash in conversion of empty OpaqueJSString to Identifier
         https://bugs.webkit.org/show_bug.cgi?id=101867

         Reviewed by Michael Saboff.

         The constructor call used for both null and empty OpaqueJSStrings results
         in an assertion voilation and crash. This patch instead uses the Identifier
         constructors which are specifically for null and empty Identifier.

         * API/OpaqueJSString.cpp:
         (OpaqueJSString::identifier):

 2012-11-30  Tor Arne Vestbø  <tor.arne.vestbo@digia.com>

         [Qt] Place the LLIntOffsetsExtractor binaries in debug/release subdirs on Mac

         Otherwise we'll end up using the same LLIntAssembly.h for both build
         configs of JavaScriptCore -- one of them which will be for the wrong
         config.

         Reviewed by Simon Hausmann.

         * LLIntOffsetsExtractor.pro:

 2012-11-30  Julien BRIANCEAU   <jbrianceau@nds.com>

         [sh4] Fix compilation warnings in JavaScriptCore JIT for sh4 arch
         https://bugs.webkit.org/show_bug.cgi?id=103378

         Reviewed by Filip Pizlo.

         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::branchTest32):
         (JSC::MacroAssemblerSH4::branchAdd32):
         (JSC::MacroAssemblerSH4::branchMul32):
         (JSC::MacroAssemblerSH4::branchSub32):
         (JSC::MacroAssemblerSH4::branchOr32):

 2012-11-29  Rafael Weinstein  <rafaelw@chromium.org>

         [HTMLTemplateElement] Add feature flag
         https://bugs.webkit.org/show_bug.cgi?id=103694

         Reviewed by Adam Barth.

         This flag will guard the implementation of the HTMLTemplateElement.
         http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html

         * Configurations/FeatureDefines.xcconfig:

 2012-11-29  Filip Pizlo  <fpizlo@apple.com>

         It should be easy to find code blocks in debug dumps
         https://bugs.webkit.org/show_bug.cgi?id=103623

         Reviewed by Goeffrey Garen.

         This gives CodeBlock a relatively strong, but also relatively compact, hash. We compute
         it lazily so that it only impacts run-time when debug support is enabled. We stringify
         it smartly so that it's short and easy to type. We base it on the source code so that
         the optimization level is irrelevant. And, we use SHA1 since it's already in our code
         base. Now, when a piece of code wants to print some debugging to say that it's operating
         on some code block, it can use this CodeBlockHash instead of memory addresses.

         This also takes CodeBlock debugging into the new world of print() and dataLog(). In
         particular, CodeBlock::dump() corresponds to the thing you want printed if you do:

         dataLog("I heart ", *myCodeBlock);

         Probably, you want to just print some identifying information at this point rather than
         the full bytecode dump. So, the existing CodeBlock::dump() has been renamed to
         CodeBlock::dumpBytecode(), and CodeBlock::dump() now prints the CodeBlockHash plus just
         a few little tidbits.

         Here's an example of CodeBlock::dump() output:

         EkILzr:[0x103883a00, BaselineFunctionCall]

         EkILzr is the CodeBlockHash. 0x103883a00 is the CodeBlock's address in memory. The other
         part is self-explanatory.

         Finally, this new notion of CodeBlockHash is available for other purposes like bisecting
         breakage. As such CodeBlockHash has all of the comparison operator overloads. When
         bisecting in DFGDriver.cpp, you can now say things like:

         if (codeBlock->hash() < CodeBlockHash("CAAAAA"))
             return false;

         And yes, CAAAAA is near the median hash, and the largest one is smaller than E99999. Such
         is life when you use base 62 to encode a 32-bit number.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/CallLinkInfo.h:
         (CallLinkInfo):
         (JSC::CallLinkInfo::specializationKind):
         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::hash):
         (JSC):
         (JSC::CodeBlock::dumpAssumingJITType):
         (JSC::CodeBlock::dump):
         (JSC::CodeBlock::dumpBytecode):
         (JSC::CodeBlock::CodeBlock):
         (JSC::CodeBlock::finalizeUnconditionally):
         (JSC::CodeBlock::resetStubInternal):
         (JSC::CodeBlock::reoptimize):
         (JSC::ProgramCodeBlock::jettison):
         (JSC::EvalCodeBlock::jettison):
         (JSC::FunctionCodeBlock::jettison):
         (JSC::CodeBlock::shouldOptimizeNow):
         (JSC::CodeBlock::tallyFrequentExitSites):
         (JSC::CodeBlock::dumpValueProfiles):
         * bytecode/CodeBlock.h:
         (JSC::CodeBlock::specializationKind):
         (CodeBlock):
         (JSC::CodeBlock::getJITType):
         * bytecode/CodeBlockHash.cpp: Added.
         (JSC):
         (JSC::CodeBlockHash::CodeBlockHash):
         (JSC::CodeBlockHash::dump):
         * bytecode/CodeBlockHash.h: Added.
         (JSC):
         (CodeBlockHash):
         (JSC::CodeBlockHash::CodeBlockHash):
         (JSC::CodeBlockHash::hash):
         (JSC::CodeBlockHash::operator==):
         (JSC::CodeBlockHash::operator!=):
         (JSC::CodeBlockHash::operator<):
         (JSC::CodeBlockHash::operator>):
         (JSC::CodeBlockHash::operator<=):
         (JSC::CodeBlockHash::operator>=):
         * bytecode/CodeBlockWithJITType.h: Added.
         (JSC):
         (CodeBlockWithJITType):
         (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
         (JSC::CodeBlockWithJITType::dump):
         * bytecode/CodeOrigin.cpp: Added.
         (JSC):
         (JSC::CodeOrigin::inlineDepthForCallFrame):
         (JSC::CodeOrigin::inlineDepth):
         (JSC::CodeOrigin::inlineStack):
         (JSC::InlineCallFrame::hash):
         * bytecode/CodeOrigin.h:
         (InlineCallFrame):
         (JSC::InlineCallFrame::specializationKind):
         (JSC):
         * bytecode/CodeType.cpp: Added.
         (WTF):
         (WTF::printInternal):
         * bytecode/CodeType.h:
         (WTF):
         * bytecode/ExecutionCounter.cpp:
         (JSC::ExecutionCounter::dump):
         * bytecode/ExecutionCounter.h:
         (ExecutionCounter):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::dump):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dumpCodeOrigin):
         * dfg/DFGOSRExitCompiler.cpp:
         * dfg/DFGOperations.cpp:
         * dfg/DFGRepatch.cpp:
         (JSC::DFG::generateProtoChainAccessStub):
         (JSC::DFG::tryCacheGetByID):
         (JSC::DFG::tryBuildGetByIDList):
         (JSC::DFG::emitPutReplaceStub):
         (JSC::DFG::emitPutTransitionStub):
         (JSC::DFG::dfgLinkClosureCall):
         * interpreter/Interpreter.cpp:
         (JSC::Interpreter::dumpCallFrame):
         * jit/JITCode.cpp: Added.
         (WTF):
         (WTF::printInternal):
         * jit/JITCode.h:
         (JSC::JITCode::jitType):
         (WTF):
         * jit/JITDisassembler.cpp:
         (JSC::JITDisassembler::dump):
         (JSC::JITDisassembler::dumpForInstructions):
         * jit/JITPropertyAccess.cpp:
         (JSC::JIT::privateCompilePutByIdTransition):
         (JSC::JIT::privateCompilePatchGetArrayLength):
         (JSC::JIT::privateCompileGetByIdProto):
         (JSC::JIT::privateCompileGetByIdSelfList):
         (JSC::JIT::privateCompileGetByIdProtoList):
         (JSC::JIT::privateCompileGetByIdChainList):
         (JSC::JIT::privateCompileGetByIdChain):
         (JSC::JIT::privateCompileGetByVal):
         (JSC::JIT::privateCompilePutByVal):
         * jit/JITPropertyAccess32_64.cpp:
         (JSC::JIT::privateCompilePutByIdTransition):
         (JSC::JIT::privateCompilePatchGetArrayLength):
         (JSC::JIT::privateCompileGetByIdProto):
         (JSC::JIT::privateCompileGetByIdSelfList):
         (JSC::JIT::privateCompileGetByIdProtoList):
         (JSC::JIT::privateCompileGetByIdChainList):
         (JSC::JIT::privateCompileGetByIdChain):
         * jit/JITStubs.cpp:
         (JSC::DEFINE_STUB_FUNCTION):
         * runtime/CodeSpecializationKind.cpp: Added.
         (WTF):
         (WTF::printInternal):
         * runtime/CodeSpecializationKind.h:
         (JSC::specializationFromIsCall):
         (JSC):
         (JSC::specializationFromIsConstruct):
         (WTF):
         * runtime/Executable.cpp:
         (JSC::ExecutableBase::hashFor):
         (JSC):
         (JSC::NativeExecutable::hashFor):
         (JSC::ScriptExecutable::hashFor):
         * runtime/Executable.h:
         (ExecutableBase):
         (NativeExecutable):
         (ScriptExecutable):
         (JSC::ScriptExecutable::source):

 2012-11-29  Michael Saboff  <msaboff@apple.com>

         Speculative Windows build fix after r136086.

         Unreviewed build fix.

         Suspect that ?setDumpsGeneratedCode@BytecodeGenerator@JSC@@SAX_N@Z needs to be removed from Windows
         export list since the symbol was removed in r136086.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-11-28  Filip Pizlo  <fpizlo@apple.com>

         SpeculatedType dumping should not use the static char buffer[thingy] idiom
         https://bugs.webkit.org/show_bug.cgi?id=103584

         Reviewed by Michael Saboff.

         Changed SpeculatedType to be "dumpable" by saying things like:

         dataLog("thingy = ", SpeculationDump(thingy))

         Removed the old stringification functions, and changed all code that referred to them
         to use the new dataLog()/print() style.

         * CMakeLists.txt:
         * GNUmakefile.list.am:
         * JavaScriptCore.xcodeproj/project.pbxproj:
         * Target.pri:
         * bytecode/SpeculatedType.cpp:
         (JSC::dumpSpeculation):
         (JSC::speculationToAbbreviatedString):
         (JSC::dumpSpeculationAbbreviated):
         * bytecode/SpeculatedType.h:
         * bytecode/ValueProfile.h:
         (JSC::ValueProfileBase::dump):
         * bytecode/VirtualRegister.h:
         (WTF::printInternal):
         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::dump):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::Graph::dump):
         (JSC::DFG::Graph::predictArgumentTypes):
         * dfg/DFGGraph.h:
         (Graph):
         * dfg/DFGStructureAbstractValue.h:
         * dfg/DFGVariableAccessDataDump.cpp: Added.
         (JSC::DFG::VariableAccessDataDump::VariableAccessDataDump):
         (JSC::DFG::VariableAccessDataDump::dump):
         * dfg/DFGVariableAccessDataDump.h: Added.
         (VariableAccessDataDump):

 2012-11-28  Michael Saboff  <msaboff@apple.com>

         Change Bytecompiler s_dumpsGeneratedCode to an Options value
         https://bugs.webkit.org/show_bug.cgi?id=103588

         Reviewed by Filip Pizlo.

         Moved the control of dumping bytecodes to Options::dumpGeneratedBytecodes.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::CodeBlock):
         * bytecompiler/BytecodeGenerator.cpp:
         * bytecompiler/BytecodeGenerator.h:
         * jsc.cpp:
         (runWithScripts):
         * runtime/Options.h:

 2012-11-28  Mark Hahnenberg  <mhahnenberg@apple.com>

         Copying phase should use work lists
         https://bugs.webkit.org/show_bug.cgi?id=101390

         Reviewed by Filip Pizlo.

         * JavaScriptCore.xcodeproj/project.pbxproj:
         * heap/BlockAllocator.cpp:
         (JSC::BlockAllocator::BlockAllocator):
         * heap/BlockAllocator.h: New RegionSet for CopyWorkListSegments.
         (BlockAllocator):
         (JSC::CopyWorkListSegment):
         * heap/CopiedBlock.h: Added a per-block CopyWorkList to keep track of the JSCells that need to be revisited during the copying
         phase to copy their backing stores.
         (CopiedBlock):
         (JSC::CopiedBlock::CopiedBlock):
         (JSC::CopiedBlock::didSurviveGC):
         (JSC::CopiedBlock::didEvacuateBytes): There is now a one-to-one relationship between GCThreads and the CopiedBlocks they're
         responsible for evacuating, we no longer need any of that fancy compare and swap stuff.
         (JSC::CopiedBlock::pin):
         (JSC::CopiedBlock::hasWorkList):
         (JSC::CopiedBlock::workList):
         * heap/CopiedBlockInlines.h: Added.
         (JSC::CopiedBlock::reportLiveBytes): Since we now have to grab a SpinLock to perform operations on the CopyWorkList during marking,
         we don't need to do any of that fancy compare and swap stuff we were doing for tracking live bytes.
         * heap/CopiedSpace.h:
         (CopiedSpace):
         * heap/CopiedSpaceInlines.h:
         (JSC::CopiedSpace::pin):
         * heap/CopyVisitor.cpp:
         (JSC::CopyVisitor::copyFromShared): We now iterate over a range of CopiedBlocks rather than MarkedBlocks and revisit the cells in those
         blocks' CopyWorkLists.
         * heap/CopyVisitor.h:
         (CopyVisitor):
         * heap/CopyVisitorInlines.h:
         (JSC::CopyVisitor::visitCell): The function responsible for calling the correct copyBackingStore() function for each JSCell from
         a CopiedBlock's CopyWorkList.
         (JSC::CopyVisitor::didCopy): We no longer need to check if the block is empty here because we know exactly when we're done
         evacuating a CopiedBlock, which is when we've gone through all of the CopiedBlock's CopyWorkList.
         * heap/CopyWorkList.h: Added.
         (CopyWorkListSegment): Individual chunk of a CopyWorkList that is allocated from the BlockAllocator.
         (JSC::CopyWorkListSegment::create):
         (JSC::CopyWorkListSegment::size):
         (JSC::CopyWorkListSegment::isFull):
         (JSC::CopyWorkListSegment::get):
         (JSC::CopyWorkListSegment::append):
         (JSC::CopyWorkListSegment::CopyWorkListSegment):
         (JSC::CopyWorkListSegment::data):
         (JSC::CopyWorkListSegment::endOfBlock):
         (CopyWorkListIterator): Responsible for giving CopyVisitors a contiguous notion of access across the separate CopyWorkListSegments
         that make up each CopyWorkList.
         (JSC::CopyWorkListIterator::get):
         (JSC::CopyWorkListIterator::operator*):
         (JSC::CopyWorkListIterator::operator->):
         (JSC::CopyWorkListIterator::operator++):
         (JSC::CopyWorkListIterator::operator==):
         (JSC::CopyWorkListIterator::operator!=):
         (JSC::CopyWorkListIterator::CopyWorkListIterator):
         (CopyWorkList): Data structure that keeps track of the JSCells that need copying in a particular CopiedBlock.
         (JSC::CopyWorkList::CopyWorkList):
         (JSC::CopyWorkList::~CopyWorkList):
         (JSC::CopyWorkList::append):
         (JSC::CopyWorkList::begin):
         (JSC::CopyWorkList::end):
         * heap/GCThreadSharedData.cpp:
         (JSC::GCThreadSharedData::GCThreadSharedData): We no longer use the m_blockSnapshot from the Heap during the copying phase.
         (JSC::GCThreadSharedData::didStartCopying): We now copy the set of all blocks in the CopiedSpace to a separate vector for
         iterating over during the copying phase since the set stored in the CopiedSpace will change as blocks are evacuated and
         recycled throughout the copying phase.
         * heap/GCThreadSharedData.h:
         (GCThreadSharedData):
         * heap/Heap.h:
         (Heap):
         * heap/SlotVisitor.h: We now need to know the object who is being marked that has a backing store so that we can store it
         in a CopyWorkList to revisit later during the copying phase.
         * heap/SlotVisitorInlines.h:
         (JSC::SlotVisitor::copyLater):
         * runtime/JSObject.cpp:
         (JSC::JSObject::visitButterfly):

 2012-11-28  Filip Pizlo  <fpizlo@apple.com>

         Disassembly methods should be able to disassemble to any PrintStream& rather than always using WTF::dataFile()
         https://bugs.webkit.org/show_bug.cgi?id=103492

         Reviewed by Mark Hahnenberg.

         Switched disassembly code to use PrintStream&, and to use print() rather than printf().

         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::dump):
         (DFG):
         (JSC::DFG::Disassembler::dumpDisassembly):
         * dfg/DFGDisassembler.h:
         (Disassembler):
         * dfg/DFGGraph.cpp:
         (JSC::DFG::printWhiteSpace):
         (JSC::DFG::Graph::dumpCodeOrigin):
         (JSC::DFG::Graph::printNodeWhiteSpace):
         (JSC::DFG::Graph::dump):
         (DFG):
         (JSC::DFG::Graph::dumpBlockHeader):
         * dfg/DFGGraph.h:
         (Graph):
         * jit/JITDisassembler.cpp:
         (JSC::JITDisassembler::dump):
         (JSC::JITDisassembler::dumpForInstructions):
         (JSC::JITDisassembler::dumpDisassembly):
         * jit/JITDisassembler.h:
         (JITDisassembler):

 2012-11-28  Filip Pizlo  <fpizlo@apple.com>

         It should be possible to say dataLog("count = ", count, "\n") instead of dataLogF("count = %d\n", count)
         https://bugs.webkit.org/show_bug.cgi?id=103009

         Reviewed by Michael Saboff.

         Instead of converting all of JSC to use the new dataLog()/print() methods, I just changed
         one place: dumping of abstract values. This is mainly just to ensure that the code I
         added to WTF is actually doing things.

         * bytecode/CodeBlock.cpp:
         (JSC::CodeBlock::dump):
         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::dump):
         (WTF):
         (WTF::printInternal):
         * dfg/DFGStructureAbstractValue.h:
         (JSC::DFG::StructureAbstractValue::dump):
         (WTF):
         (WTF::printInternal):

 2012-11-28  Oliver Hunt  <oliver@apple.com>

         Make source cache include more information about the function extent.
         https://bugs.webkit.org/show_bug.cgi?id=103552

         Reviewed by Gavin Barraclough.

         Add a bit more information to the source cache.

         * parser/Parser.cpp:
         (JSC::::parseFunctionInfo):
            Store the function start offset
         * parser/SourceProviderCacheItem.h:
         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
         (SourceProviderCacheItem):
            Add additional field for the start of the real function string, and re-arrange
            fields to avoid growing the struct.

 2012-11-27  Filip Pizlo  <fpizlo@apple.com>

         Convert some remaining uses of FILE* to PrintStream&.

         Rubber stamped by Mark Hahnenberg.

         * bytecode/ValueProfile.h:
         (JSC::ValueProfileBase::dump):
         * bytecode/ValueRecovery.h:
         (JSC::ValueRecovery::dump):
         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseCodeBlock):
         * dfg/DFGNode.h:
         (JSC::DFG::Node::dumpChildren):

 2012-11-27  Filip Pizlo  <fpizlo@apple.com>

         Fix indentation in JSValue.h

         Rubber stamped by Mark Hahnenberg.

         * runtime/JSValue.h:

 2012-11-26  Filip Pizlo  <fpizlo@apple.com>

         DFG SetLocal should use forwardSpeculationCheck instead of its own half-baked version of same
         https://bugs.webkit.org/show_bug.cgi?id=103353

         Reviewed by Oliver Hunt and Gavin Barraclough.

         Made it possible to use forward speculations for most of the operand classes. Changed the conditional
         direction parameter from being 'bool isForward' to an enum (SpeculationDirection). Changed SetLocal
         to use forward speculations and got rid of its half-baked version of same.

         Also added the ability to force the DFG's disassembler to dump all nodes, even ones that are dead.

         * dfg/DFGByteCodeParser.cpp:
         (JSC::DFG::ByteCodeParser::parseBlock):
         * dfg/DFGDisassembler.cpp:
         (JSC::DFG::Disassembler::dump):
         * dfg/DFGDriver.cpp:
         (JSC::DFG::compile):
         * dfg/DFGSpeculativeJIT.cpp:
         (JSC::DFG::SpeculativeJIT::speculationCheck):
         (DFG):
         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
         (JSC::DFG::SpeculativeJIT::fillStorage):
         * dfg/DFGSpeculativeJIT.h:
         (SpeculativeJIT):
         (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand):
         (JSC::DFG::SpeculateIntegerOperand::gpr):
         (SpeculateIntegerOperand):
         (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
         (JSC::DFG::SpeculateDoubleOperand::fpr):
         (SpeculateDoubleOperand):
         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
         (JSC::DFG::SpeculateCellOperand::gpr):
         (SpeculateCellOperand):
         (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
         (JSC::DFG::SpeculateBooleanOperand::gpr):
         (SpeculateBooleanOperand):
         * dfg/DFGSpeculativeJIT32_64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):
         * dfg/DFGSpeculativeJIT64.cpp:
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
         (JSC::DFG::SpeculativeJIT::fillSpeculateInt):
         (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
         (JSC::DFG::SpeculativeJIT::compile):
         * runtime/Options.h:
         (JSC):

 2012-11-26  Daniel Bates  <dbates@webkit.org>

         Substitute "allSeparators8Bit" for "allSeperators8Bit" in JSC::jsSpliceSubstringsWithSeparators()
         <https://bugs.webkit.org/show_bug.cgi?id=103303>

         Reviewed by Simon Fraser.

         Fix misspelled word, "Seperators" [sic], in a local variable name in JSC::jsSpliceSubstringsWithSeparators().

         * runtime/StringPrototype.cpp:
         (JSC::jsSpliceSubstringsWithSeparators):

 2012-11-26  Daniel Bates  <dbates@webkit.org>

         JavaScript fails to handle String.replace() with large replacement string
         https://bugs.webkit.org/show_bug.cgi?id=102956
         <rdar://problem/12738012>

         Reviewed by Oliver Hunt.

         Fix an issue where we didn't check for overflow when computing the length
         of the result of String.replace() with a large replacement string.

         * runtime/StringPrototype.cpp:
         (JSC::jsSpliceSubstringsWithSeparators):

 2012-11-26  Zeno Albisser  <zeno@webkit.org>

         [Qt] Fix the LLInt build on Mac
         https://bugs.webkit.org/show_bug.cgi?id=97587

         Reviewed by Simon Hausmann.

         * DerivedSources.pri:
         * JavaScriptCore.pro:

 2012-11-26  Oliver Hunt  <oliver@apple.com>

         32-bit build fix.  Move the method decalration outside of the X86_64 only section.

         * assembler/MacroAssembler.h:
         (MacroAssembler):
         (JSC::MacroAssembler::shouldConsiderBlinding):

 2012-11-26  Oliver Hunt  <oliver@apple.com>

         Don't blind all the things.
         https://bugs.webkit.org/show_bug.cgi?id=102572

         Reviewed by Gavin Barraclough.

         No longer blind all the constants in the instruction stream.  We use a
         simple non-deterministic filter to avoid blinding everything.  Also modified
         the basic integer blinding logic to avoid blinding small negative values.

         * assembler/MacroAssembler.h:
         (MacroAssembler):
         (JSC::MacroAssembler::shouldConsiderBlinding):
         (JSC::MacroAssembler::shouldBlind):

 2012-11-26  Mark Hahnenberg  <mhahnenberg@apple.com>

         JSObject::copyButterfly doesn't handle undecided indexing types correctly
         https://bugs.webkit.org/show_bug.cgi?id=102573

         Reviewed by Filip Pizlo.

         We don't do any copying into the newly allocated vector and we don't zero-initialize CopiedBlocks
         during the copying phase, so we end up with uninitialized memory in arrays which have undecided indexing
         types. We should just do the actual memcpy from the old block to the new one.

         * runtime/JSObject.cpp:
         (JSC::JSObject::copyButterfly): Just do the same thing that we do for other contiguous indexing types.

 2012-11-26  Julien BRIANCEAU   <jbrianceau@nds.com>

         [sh4] JavaScriptCore JIT build is broken since r135330
         Add missing implementation for sh4 arch.
         https://bugs.webkit.org/show_bug.cgi?id=103145

         Reviewed by Oliver Hunt.

         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::canJumpReplacePatchableBranchPtrWithPatch):
         (MacroAssemblerSH4):
         (JSC::MacroAssemblerSH4::startOfBranchPtrWithPatchOnRegister):
         (JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch):
         (JSC::MacroAssemblerSH4::startOfPatchableBranchPtrWithPatchOnAddress):
         (JSC::MacroAssemblerSH4::revertJumpReplacementToPatchableBranchPtrWithPatch):
         * assembler/SH4Assembler.h:
         (JSC::SH4Assembler::revertJump):
         (SH4Assembler):
         (JSC::SH4Assembler::printInstr):

 2012-11-26  Yuqiang Xian  <yuqiang.xian@intel.com>

         Use load64 instead of loadPtr to load a JSValue on JSVALUE64 platforms
         https://bugs.webkit.org/show_bug.cgi?id=100909

         Reviewed by Brent Fulgham.

         This is a (trivial) fix after r132701.

         * dfg/DFGOSRExitCompiler64.cpp:
         (JSC::DFG::OSRExitCompiler::compileExit):

 2012-11-26  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

         [Qt][ARM] REGRESSION(r130826): It made 33 JSC test and 466 layout tests crash
         https://bugs.webkit.org/show_bug.cgi?id=98857

         Reviewed by Zoltan Herczeg.

         Implement a new version of patchableBranch32 to fix crashing JSC
         tests.

         * assembler/MacroAssembler.h:
         (MacroAssembler):
         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::patchableBranch32):
         (MacroAssemblerARM):

 2012-11-21  Filip Pizlo  <fpizlo@apple.com>

         Any function that can log things should be able to easily log them to a memory buffer as well
         https://bugs.webkit.org/show_bug.cgi?id=103000

         Reviewed by Sam Weinig.

         Change all users of WTF::dataFile() to expect a PrintStream& rather than a FILE*.

         * bytecode/Operands.h:
         (JSC::OperandValueTraits::dump):
         (JSC::dumpOperands):
         (JSC):
         * dfg/DFGAbstractState.cpp:
         (JSC::DFG::AbstractState::dump):
         * dfg/DFGAbstractState.h:
         (AbstractState):
         * dfg/DFGAbstractValue.h:
         (JSC::DFG::AbstractValue::dump):
         * dfg/DFGCommon.h:
         (JSC::DFG::NodeIndexTraits::dump):
         * dfg/DFGStructureAbstractValue.h:
         (JSC::DFG::StructureAbstractValue::dump):
         * dfg/DFGVariableEvent.cpp:
         (JSC::DFG::VariableEvent::dump):
         (JSC::DFG::VariableEvent::dumpFillInfo):
         (JSC::DFG::VariableEvent::dumpSpillInfo):
         * dfg/DFGVariableEvent.h:
         (VariableEvent):
         * disassembler/Disassembler.h:
         (JSC):
         (JSC::tryToDisassemble):
         * disassembler/UDis86Disassembler.cpp:
         (JSC::tryToDisassemble):

 2012-11-23  Alexis Menard  <alexis@webkit.org>

         [CSS3 Backgrounds and Borders] Implement new CSS3 background-position parsing.
         https://bugs.webkit.org/show_bug.cgi?id=102104

         Reviewed by Julien Chaffraix.

         Protect the new feature behind a feature flag.

         * Configurations/FeatureDefines.xcconfig:

 2012-11-23  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

         Fix the ARM traditional build after r135330
         https://bugs.webkit.org/show_bug.cgi?id=102871

         Reviewed by Zoltan Herczeg.

         Added missing functionality to traditional ARM architecture.

         * assembler/ARMAssembler.h:
         (JSC::ARMAssembler::revertJump):
         (ARMAssembler):
         * assembler/MacroAssemblerARM.h:
         (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatchOnAddress):
         (JSC::MacroAssemblerARM::startOfBranchPtrWithPatchOnRegister):
         (MacroAssemblerARM):
         (JSC::MacroAssemblerARM::revertJumpReplacementToBranchPtrWithPatch):

 2012-11-16  Yury Semikhatsky  <yurys@chromium.org>

         Memory instrumentation: extract MemoryObjectInfo declaration into a separate file
         https://bugs.webkit.org/show_bug.cgi?id=102510

         Reviewed by Pavel Feldman.

         Added new symbols for the methods that have moved into .../wtf/MemoryInstrumentation.cpp

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

 2012-11-23  Julien BRIANCEAU   <jbrianceau@nds.com>

         [sh4] JavaScriptCore JIT build is broken since r130839
         Add missing implementation for sh4 arch.
         https://bugs.webkit.org/show_bug.cgi?id=101479

         Reviewed by Filip Pizlo.

         * assembler/MacroAssemblerSH4.h:
         (JSC::MacroAssemblerSH4::load8Signed):
         (MacroAssemblerSH4):
         (JSC::MacroAssemblerSH4::load16Signed):
         (JSC::MacroAssemblerSH4::store8):
         (JSC::MacroAssemblerSH4::store16):
         (JSC::MacroAssemblerSH4::moveDoubleToInts):
         (JSC::MacroAssemblerSH4::moveIntsToDouble):
         (JSC::MacroAssemblerSH4::loadFloat):
         (JSC::MacroAssemblerSH4::loadDouble):
         (JSC::MacroAssemblerSH4::storeFloat):
         (JSC::MacroAssemblerSH4::storeDouble):
         (JSC::MacroAssemblerSH4::addDouble):
         (JSC::MacroAssemblerSH4::convertFloatToDouble):
         (JSC::MacroAssemblerSH4::convertDoubleToFloat):
         (JSC::MacroAssemblerSH4::urshift32):
         * assembler/SH4Assembler.h:
         (JSC::SH4Assembler::sublRegReg):
         (JSC::SH4Assembler::subvlRegReg):
         (JSC::SH4Assembler::floatfpulfrn):
         (JSC::SH4Assembler::fldsfpul):
         (JSC::SH4Assembler::fstsfpul):
         (JSC::SH4Assembler::dcnvsd):
         (SH4Assembler):
         (JSC::SH4Assembler::movbRegMem):
         (JSC::SH4Assembler::sizeOfConstantPool):
         (JSC::SH4Assembler::linkJump):
         (JSC::SH4Assembler::printInstr):
         (JSC::SH4Assembler::printBlockInstr):

 2012-11-22  Balazs Kilvady  <kilvadyb@homejinni.com>

         Fix the MIPS build after r135330
         https://bugs.webkit.org/show_bug.cgi?id=102872

         Reviewed by Gavin Barraclough.

         Revert/replace functions added to MIPS port.

         * assembler/MIPSAssembler.h:
         (JSC::MIPSAssembler::revertJumpToMove):
         (MIPSAssembler):
         (JSC::MIPSAssembler::replaceWithJump):
         * assembler/MacroAssemblerMIPS.h:
         (MacroAssemblerMIPS):
         (JSC::MacroAssemblerMIPS::startOfBranchPtrWithPatchOnRegister):
         (JSC::MacroAssemblerMIPS::revertJumpReplacementToBranchPtrWithPatch):
         (JSC::MacroAssemblerMIPS::startOfPatchableBranchPtrWithPatchOnAddress):

 2012-11-21  Filip Pizlo  <fpizlo@apple.com>

         Rename dataLog() and dataLogV() to dataLogF() and dataLogFV()
         https://bugs.webkit.org/show_bug.cgi?id=103001

         Rubber stamped by Dan Bernstein.

         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
         * assembler/LinkBuffer.cpp:
         (JSC::LinkBuffer::finalizeCodeWithDisassembly):
         (JSC::LinkBuffer::dumpLinkStatistics):
         (JSC::LinkBuffer::dumpCode):
         * assembler/LinkBuffer.h:
         (JSC):
         * assembler/SH4Assembler.h:
         (JSC::SH4Assembler::vprintfStdoutInstr):
         * bytecode/CodeBlock.cpp: