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

        REGRESSION(r137994): Random crashes occur with SH4 JSC.
        https://bugs.webkit.org/show_bug.cgi?id=115167.

        Reviewed by Oliver Hunt.

        Since r137994, uncommited pages could be inside the area of memory in
        parameter of the cacheFlush function. That's why we have to flush each
        page separately to avoid a fail of the whole flush, if an uncommited page
        is in the area.

        This patch is very similar to changeset 145194 made for ARMv7 architecture,
        see https://bugs.webkit.org/show_bug.cgi?id=111441 for further information.

        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::cacheFlush):

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-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-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:
        (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::dump):
        (JSC::CodeBlock::dumpStatistics):
        (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/Opcode.cpp:
        (JSC::OpcodeStats::~OpcodeStats):
        * bytecode/SamplingTool.cpp:
        (JSC::SamplingFlags::stop):
        (JSC::SamplingRegion::dumpInternal):
        (JSC::SamplingTool::dump):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::mergeStateAtTail):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::dump):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::makeSafe):
        (JSC::DFG::ByteCodeParser::makeDivSafe):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::processPhiStack):
        (JSC::DFG::ByteCodeParser::linkBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        (JSC::DFG::CFAPhase::performForwardCFA):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
        (JSC::DFG::CFGSimplificationPhase::fixPhis):
        (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors):
        (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::endIndexForPureCSE):
        (JSC::DFG::CSEPhase::setReplacement):
        (JSC::DFG::CSEPhase::eliminate):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::debugFail):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dump):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixDoubleEdge):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::printWhiteSpace):
        (JSC::DFG::Graph::dumpCodeOrigin):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::predictArgumentTypes):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * 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:
        * dfg/DFGPhase.cpp:
        (JSC::DFG::Phase::beginPhase):
        * dfg/DFGPhase.h:
        (JSC::DFG::runAndLog):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::propagateForward):
        (JSC::DFG::PredictionPropagationPhase::propagateBackward):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGRegisterBank.h:
        (JSC::DFG::RegisterBank::dump):
        * dfg/DFGScoreBoard.h:
        (JSC::DFG::ScoreBoard::use):
        (JSC::DFG::ScoreBoard::dump):
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::generate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        (JSC::DFG::SpeculativeJIT::dump):
        (JSC::DFG::SpeculativeJIT::checkConsistency):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:
        (Validate):
        (JSC::DFG::Validate::reportValidationContext):
        (JSC::DFG::Validate::dumpData):
        (JSC::DFG::Validate::dumpGraphIfAppropriate):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::logEvent):
        (JSC::DFG::VariableEventStream::reconstruct):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * heap/Heap.cpp:
        * heap/HeapStatistics.cpp:
        (JSC::HeapStatistics::logStatistics):
        (JSC::HeapStatistics::showObjectStatistics):
        * heap/MarkStack.h:
        * heap/MarkedBlock.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::validate):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::dumpCaller):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::dump):
        (JSC::JITDisassembler::dumpForInstructions):
        * jit/JITStubRoutine.h:
        (JSC):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JumpReplacementWatchpoint.cpp:
        (JSC::JumpReplacementWatchpoint::fireInternal):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::interpreterThrowInCaller):
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_trace_operand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        * profiler/Profile.cpp:
        (JSC::Profile::debugPrintData):
        (JSC::Profile::debugPrintDataSampleStyle):
        * profiler/ProfileNode.cpp:
        (JSC::ProfileNode::debugPrintData):
        (JSC::ProfileNode::debugPrintDataSampleStyle):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::dumpRegExpTrace):
        * runtime/RegExp.cpp:
        (JSC::RegExp::matchCompareWithInterpreter):
        * runtime/SamplingCounter.cpp:
        (JSC::AbstractSamplingCounter::dump):
        * runtime/Structure.cpp:
        (JSC::Structure::dumpStatistics):
        (JSC::PropertyMapStatisticsExitLogger::~PropertyMapStatisticsExitLogger):
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::report):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::dumpInternal):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::dumpDisjunction):

2012-11-21  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to say disassemble(stuff) instead of having to say if (!tryToDisassemble(stuff)) dataLog("I failed")
        https://bugs.webkit.org/show_bug.cgi?id=103010

        Reviewed by Anders Carlsson.

        You can still say tryToDisassemble(), which will tell you if it failed; you can then
        decide what to do instead. But it's better to say disassemble(), which will just print
        the instruction ranges if tryToDisassemble() failed. This is particularly appropriate
        since that's what all previous users of tryToDisassemble() would have done in some
        form or another.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpDisassembly):
        * disassembler/Disassembler.cpp: Added.
        (JSC):
        (JSC::disassemble):
        * disassembler/Disassembler.h:
        (JSC):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::dumpDisassembly):

2012-11-21  Filip Pizlo  <fpizlo@apple.com>

        dumpOperands() claims that it needs a non-const Operands& when that is completely false
        https://bugs.webkit.org/show_bug.cgi?id=103005

        Reviewed by Eric Carlson.

        * bytecode/Operands.h:
        (JSC::dumpOperands):
        (JSC):

2012-11-20  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT's disassembly should be just as pretty as the DFG's
        https://bugs.webkit.org/show_bug.cgi?id=102873

        Reviewed by Sam Weinig.

        Integrated the CodeBlock's bytecode dumper with the JIT's disassembler. Also fixed
        some type goof-ups (instructions are not in a Vector<Instruction> so using a Vector
        iterator makes no sense) and stream-lined some things (you don't actually need a
        full-fledged ExecState* to dump bytecode).

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printUnaryOp):
        (JSC::CodeBlock::printBinaryOp):
        (JSC::CodeBlock::printConditionalJump):
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::printPutByIdOp):
        (JSC::CodeBlock::dump):
        (JSC):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpCallFrame):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JIT):
        * jit/JITDisassembler.cpp: Added.
        (JSC):
        (JSC::JITDisassembler::JITDisassembler):
        (JSC::JITDisassembler::~JITDisassembler):
        (JSC::JITDisassembler::dump):
        (JSC::JITDisassembler::dumpForInstructions):
        (JSC::JITDisassembler::dumpDisassembly):
        * jit/JITDisassembler.h: Added.
        (JSC):
        (JITDisassembler):
        (JSC::JITDisassembler::setStartOfCode):
        (JSC::JITDisassembler::setForBytecodeMainPath):
        (JSC::JITDisassembler::setForBytecodeSlowPath):
        (JSC::JITDisassembler::setEndOfSlowPath):
        (JSC::JITDisassembler::setEndOfCode):

2012-11-21  Daniel Bates  <dbates@webkit.org>

        JavaScript fails to concatenate large strings
        <https://bugs.webkit.org/show_bug.cgi?id=102963>

        Reviewed by Michael Saboff.

        Fixes an issue where we inadvertently didn't check the length of
        a JavaScript string for overflow.

        * runtime/Operations.h:
        (JSC::jsString):
        (JSC::jsStringFromArguments):

2012-11-20  Filip Pizlo  <fpizlo@apple.com>

        DFG should be able to cache closure calls (part 2/2)
        https://bugs.webkit.org/show_bug.cgi?id=102662

        Reviewed by Gavin Barraclough.

        Added caching of calls where the JSFunction* varies, but the Structure* and ExecutableBase*
        stay the same. This is accomplished by replacing the branch that compares against a constant
        JSFunction* with a jump to a closure call stub. The closure call stub contains a fast path,
        and jumps slow directly to the virtual call thunk.

        Looks like a 1% win on V8v7.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        * bytecode/CallLinkInfo.h:
        (CallLinkInfo):
        (JSC::CallLinkInfo::isLinked):
        (JSC::getCallLinkInfoBytecodeIndex):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC):
        (JSC::CodeBlock::findClosureCallForReturnPC):
        (JSC::CodeBlock::bytecodeOffset):
        (JSC::CodeBlock::codeOriginForReturn):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getCallLinkInfo):
        (CodeBlock):
        (JSC::CodeBlock::isIncomingCallAlreadyLinked):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addJSCall):
        (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
        (JSCallRecord):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::linkSlowFor):
        (DFG):
        (JSC::DFG::dfgLinkFor):
        (JSC::DFG::dfgLinkSlowFor):
        (JSC::DFG::dfgLinkClosureCall):
        * dfg/DFGRepatch.h:
        (DFG):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGThunks.cpp:
        (DFG):
        (JSC::DFG::linkClosureCallThunkGenerator):
        * dfg/DFGThunks.h:
        (DFG):
        * heap/Heap.h:
        (Heap):
        (JSC::Heap::jitStubRoutines):
        * heap/JITStubRoutineSet.h:
        (JSC::JITStubRoutineSet::size):
        (JSC::JITStubRoutineSet::at):
        (JITStubRoutineSet):
        * jit/ClosureCallStubRoutine.cpp: Added.
        (JSC):
        (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine):
        (JSC::ClosureCallStubRoutine::~ClosureCallStubRoutine):
        (JSC::ClosureCallStubRoutine::markRequiredObjectsInternal):
        * jit/ClosureCallStubRoutine.h: Added.
        (JSC):
        (ClosureCallStubRoutine):
        (JSC::ClosureCallStubRoutine::structure):
        (JSC::ClosureCallStubRoutine::executable):
        (JSC::ClosureCallStubRoutine::codeOrigin):
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        * jit/GCAwareJITStubRoutine.h:
        (GCAwareJITStubRoutine):
        (JSC::GCAwareJITStubRoutine::isClosureCall):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):

2012-11-20  Filip Pizlo  <fpizlo@apple.com>

        DFG should be able to cache closure calls (part 1/2)
        https://bugs.webkit.org/show_bug.cgi?id=102662

        Reviewed by Gavin Barraclough.

        Add ability to revert a jump replacement back to
        branchPtrWithPatch(Condition, RegisterID, TrustedImmPtr). This is meant to be
        a mandatory piece of functionality for all assemblers. I also renamed some of
        the functions for reverting jump replacements back to
        patchableBranchPtrWithPatch(Condition, Address, TrustedImmPtr), so as to avoid
        confusion.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::BadReg):
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::revertJumpTo_movT3):
        * assembler/LinkBuffer.h:
        (JSC):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::startOfBranchPtrWithPatchOnRegister):
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
        (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatchOnAddress):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::startOfBranchPtrWithPatchOnRegister):
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::startOfPatchableBranchPtrWithPatchOnAddress):
        (JSC::MacroAssemblerX86::revertJumpReplacementToBranchPtrWithPatch):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::startOfBranchPtrWithPatchOnRegister):
        (JSC::MacroAssemblerX86_64::startOfPatchableBranchPtrWithPatchOnAddress):
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch):
        * assembler/RepatchBuffer.h:
        (JSC::RepatchBuffer::startOfBranchPtrWithPatchOnRegister):
        (RepatchBuffer):
        (JSC::RepatchBuffer::startOfPatchableBranchPtrWithPatchOnAddress):
        (JSC::RepatchBuffer::revertJumpReplacementToBranchPtrWithPatch):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::revertJumpTo_cmpl_ir_force32):
        (X86Assembler):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::replaceWithJump):
        (JSC::DFG::dfgResetGetByID):
        (JSC::DFG::dfgResetPutByID):

2012-11-20  Yong Li  <yoli@rim.com>

        [ARMv7] Neither linkCall() nor linkPointer() should flush code.
        https://bugs.webkit.org/show_bug.cgi?id=99213

        Reviewed by George Staikos.

        LinkBuffer doesn't need to flush code during linking. It will
        eventually flush the whole executable. Fixing this gives >%5
        sunspider boost (on QNX).

        Also make replaceWithLoad() and replaceWithAddressComputation() flush
        only when necessary.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::linkCall):
        (JSC::ARMv7Assembler::linkPointer):
        (JSC::ARMv7Assembler::relinkCall):
        (JSC::ARMv7Assembler::repatchInt32):
        (JSC::ARMv7Assembler::repatchPointer):
        (JSC::ARMv7Assembler::replaceWithLoad): Flush only after it did write.
        (JSC::ARMv7Assembler::replaceWithAddressComputation): Flush only after it did write.
        (JSC::ARMv7Assembler::setInt32):
        (JSC::ARMv7Assembler::setPointer):

2012-11-19  Filip Pizlo  <fpizlo@apple.com>

        Remove support for ARMv7 errata from the jump code
        https://bugs.webkit.org/show_bug.cgi?id=102759

        Reviewed by Oliver Hunt.

        The jump replacement code was wrong to begin with since it wasn't doing
        a cache flush on the inserted padding. And, to my knowledge, we don't need
        this anymore, so this patch removes all errata code from the ARMv7 port.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::computeJumpType):
        (JSC::ARMv7Assembler::replaceWithJump):
        (JSC::ARMv7Assembler::maxJumpReplacementSize):
        (JSC::ARMv7Assembler::canBeJumpT3):
        (JSC::ARMv7Assembler::canBeJumpT4):

2012-11-19  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Create JavaScriptCore ForwardingHeaders
        https://bugs.webkit.org/show_bug.cgi?id=92665

        Reviewed by Brent Fulgham.

        When using CMake to build the Windows port, we need
        to generate the forwarding headers with it too.

        * CMakeLists.txt:

2012-11-19  Kihong Kwon  <kihong.kwon@samsung.com>

        Add PROXIMITY_EVENTS feature
        https://bugs.webkit.org/show_bug.cgi?id=102658

        Reviewed by Kentaro Hara.

        Add PROXIMITY_EVENTS feature to xcode project for JavaScriptCore.

        * Configurations/FeatureDefines.xcconfig:

2012-11-18  Dan Bernstein  <mitz@apple.com>

        Try to fix the DFG build after r135099.

        * dfg/DFGCommon.h:
        (JSC::DFG::shouldShowDisassembly):

2012-11-18  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, build fix for !ENABLE(DFG_JIT).

        * dfg/DFGCommon.h:
        (JSC::DFG::shouldShowDisassembly):
        (DFG):

2012-11-18  Filip Pizlo  <fpizlo@apple.com>

        JSC should have more logging in structure-related code
        https://bugs.webkit.org/show_bug.cgi?id=102630

        Reviewed by Simon Fraser.

        - JSValue::description() now tells you if something is a structure, and if so,
          what kind of structure it is.
        
        - Jettisoning logic now tells you why things are being jettisoned.
        
        - It's now possible to turn off GC-triggered jettisoning entirely.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::reoptimize):
        (JSC::ProgramCodeBlock::jettison):
        (JSC::EvalCodeBlock::jettison):
        (JSC::FunctionCodeBlock::jettison):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
        * runtime/JSValue.cpp:
        (JSC::JSValue::description):
        * runtime/Options.h:
        (JSC):

2012-11-18  Filip Pizlo  <fpizlo@apple.com>

        DFG constant folding phase should say 'changed = true' whenever it changes the graph
        https://bugs.webkit.org/show_bug.cgi?id=102550

        Rubber stamped by Mark Hahnenberg.

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

2012-11-17  Elliott Sprehn  <esprehn@chromium.org>

        Expose JSObject removeDirect and PrivateName to WebCore
        https://bugs.webkit.org/show_bug.cgi?id=102546

        Reviewed by Geoffrey Garen.

        Export removeDirect for use in WebCore so JSDependentRetained works.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-11-16  Filip Pizlo  <fpizlo@apple.com>

        Given a PutById or GetById with a proven structure, the DFG should be able to emit a PutByOffset or GetByOffset instead
        https://bugs.webkit.org/show_bug.cgi?id=102327

        Reviewed by Mark Hahnenberg.

        If the profiler tells us that a GetById or PutById may be polymorphic but our
        control flow analysis proves that it isn't, we should trust the control flow
        analysis over the profiler. This arises in cases where GetById or PutById were
        inlined: the inlined function may have been called from other places that led
        to polymorphism, but in the current inlined context, there is no polymorphism.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        (JSC):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):
        (GetByIdStatus):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        (JSC):
        * bytecode/PutByIdStatus.h:
        (JSC):
        (JSC::PutByIdStatus::PutByIdStatus):
        (PutByIdStatus):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::bestProvenStructure):
        (AbstractValue):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
        (ConstantFoldingPhase):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToGetByOffset):
        (Node):
        (JSC::DFG::Node::convertToPutByOffset):
        (JSC::DFG::Node::hasStorageResult):
        * runtime/JSGlobalObject.h:
        (JSC::Structure::prototypeChain):
        (JSC):
        (JSC::Structure::isValid):
        * runtime/Operations.h:
        (JSC::isPrototypeChainNormalized):
        (JSC):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::transitionDidInvolveSpecificValue):

2012-11-16  Tony Chang  <tony@chromium.org>

        Remove ENABLE_CSS_HIERARCHIES since it's no longer in use
        https://bugs.webkit.org/show_bug.cgi?id=102554

        Reviewed by Andreas Kling.

        As mentioned in https://bugs.webkit.org/show_bug.cgi?id=79939#c41 ,
        we're going to revist this feature once additional vendor support is
        achieved.

        * Configurations/FeatureDefines.xcconfig:

2012-11-16  Patrick Gansterer  <paroga@webkit.org>

        Build fix for WinCE after r133688.

        Use numeric_limits<uint32_t>::max() instead of UINT32_MAX.

        * runtime/CodeCache.h:
        (JSC::CacheMap::CacheMap):

2012-11-15  Filip Pizlo  <fpizlo@apple.com>

        ClassInfo.h should have correct indentation.

        Rubber stamped by Mark Hahnenberg.

        ClassInfo.h had some true creativity in its use of whitespace. Some things within
        the namespace were indented four spaces and others where not. One #define had its
        contents indented four spaces, while another didn't. I applied the following rule:
        
        - Non-macro things in the namespace should not be indented (that's our current
          accepted practice).
        
        - Macros should never be indented but if they are multi-line then their subsequent
          bodies should be indented four spaces. I believe that is consistent with what we
          do elsewhere.

        * runtime/ClassInfo.h:
        (JSC):
        (MethodTable):
        (ClassInfo):
        (JSC::ClassInfo::propHashTable):
        (JSC::ClassInfo::isSubClassOf):
        (JSC::ClassInfo::hasStaticProperties):

2012-11-15  Filip Pizlo  <fpizlo@apple.com>

        DFG should copy propagate trivially no-op ConvertThis
        https://bugs.webkit.org/show_bug.cgi?id=102445

        Reviewed by Oliver Hunt.

        Copy propagation is always a good thing, since it reveals must-alias relationships
        to the CFA and CSE. This accomplishes copy propagation for ConvertThis by first
        converting it to an Identity node (which is done by the constant folder since it
        has access to CFA results) and then performing substitution of references to
        Identity with references to Identity's child in the CSE.
        
        I'm not aiming for a big speed-up here; I just think that this will be useful for
        the work on https://bugs.webkit.org/show_bug.cgi?id=102327.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * 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):

2012-11-15  Filip Pizlo  <fpizlo@apple.com>

        CallData.h should have correct indentation.

        Rubber stamped by Mark Hahneberg.

        * runtime/CallData.h:
        (JSC):

2012-11-15  Filip Pizlo  <fpizlo@apple.com>

        Remove methodCallDummy since it is not used anymore.

        Rubber stamped by Mark Hahnenberg.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):

2012-11-14  Filip Pizlo  <fpizlo@apple.com>

        Structure should be able to easily tell if the prototype chain might intercept a store
        https://bugs.webkit.org/show_bug.cgi?id=102326

        Reviewed by Geoffrey Garen.

        This improves our ability to reason about the correctness of the more optimized
        prototype chain walk in JSObject::put(), while also making it straight forward to
        check if the prototype chain will do strange things to a property store by just
        looking at the structure.

        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        * runtime/Structure.cpp:
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        (JSC):
        * runtime/Structure.h:
        (Structure):

2012-11-15  Thiago Marcos P. Santos  <thiago.santos@intel.com>

        [CMake] Do not regenerate LLIntAssembly.h on every incremental build
        https://bugs.webkit.org/show_bug.cgi?id=102248

        Reviewed by Kenneth Rohde Christiansen.

        Update LLIntAssembly.h's mtime after running asm.rb to make the build
        system dependency tracking consistent.

        * CMakeLists.txt:

2012-11-15  Thiago Marcos P. Santos  <thiago.santos@intel.com>

        Fix compiler warnings about signed/unsigned comparison on i386
        https://bugs.webkit.org/show_bug.cgi?id=102249

        Reviewed by Kenneth Rohde Christiansen.

        Add casting to unsigned to shut up gcc warnings. Build was broken on
        JSVALUE32_64 ports compiling with -Werror.

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

2012-11-14  Brent Fulgham  <bfulgham@webkit.org>

        [Windows, WinCairo] Unreviewed build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        Missed one of the exports that was part of the WebKit2.def.

2012-11-14  Brent Fulgham  <bfulgham@webkit.org>

        [Windows, WinCairo] Correct build failure.
        https://bugs.webkit.org/show_bug.cgi?id=102302

        WebCore symbols were mistakenly added to the JavaScriptCore
        library definition file.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Remove
        WebCore symbols that were incorrectly added to the export file.

2012-11-14  Mark Lam  <mark.lam@apple.com>

        Change JSEventListener::m_jsFunction to be a weak ref.
        https://bugs.webkit.org/show_bug.cgi?id=101989.

        Reviewed by Geoffrey Garen.

        Added infrastructure for scanning weak ref slots.

        * heap/SlotVisitor.cpp: Added #include "SlotVisitorInlines.h".
        * heap/SlotVisitor.h:
        (SlotVisitor): Added SlotVisitor::appendUnbarrieredWeak().
        * heap/SlotVisitorInlines.h: Added #include "Weak.h".
        (JSC::SlotVisitor::appendUnbarrieredWeak): Added.
        * heap/Weak.h:
        (JSC::operator==): Added operator==() for Weak.
        * runtime/JSCell.h: Removed #include "SlotVisitorInlines.h".
        * runtime/JSObject.h: Added #include "SlotVisitorInlines.h".

2012-11-14  Filip Pizlo  <fpizlo@apple.com>

        Read-only properties created with putDirect() should tell the structure that there are read-only properties
        https://bugs.webkit.org/show_bug.cgi?id=102292

        Reviewed by Gavin Barraclough.

        This mostly affects things like function.length.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):

2012-11-13  Filip Pizlo  <fpizlo@apple.com>

        Don't access Node& after adding nodes to the graph.
        https://bugs.webkit.org/show_bug.cgi?id=102005

        Reviewed by Oliver Hunt.

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

2012-11-14  Valery Ignatyev  <valery.ignatyev@ispras.ru>

        Replace (typeof(x) != <"object", "undefined", ...>) with
        !(typeof(x) == <"object",..>). Later is_object, is_<...>  bytecode operation
        will be used.

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

        Reviewed by Filip Pizlo.

        This eliminates expensive  typeof implementation and
        allows to use DFG optimizations, which doesn't support 'typeof'.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BinaryOpNode::emitBytecode):

2012-11-14  Peter Gal  <galpeter@inf.u-szeged.hu>

        [Qt][ARM]REGRESSION(r133985): It broke the build
        https://bugs.webkit.org/show_bug.cgi?id=101740

        Reviewed by Csaba Osztrogonác.

        Changed the emitGenericContiguousPutByVal to accept the additional IndexingType argument.
        This information was passed as a template parameter.        

        * jit/JIT.h:
        (JSC::JIT::emitInt32PutByVal):
        (JSC::JIT::emitDoublePutByVal):
        (JSC::JIT::emitContiguousPutByVal):
        (JIT):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGenericContiguousPutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGenericContiguousPutByVal):

2012-11-14  Peter Gal  <galpeter@inf.u-szeged.hu>

        Fix the MIPS build after r134332
        https://bugs.webkit.org/show_bug.cgi?id=102227

        Reviewed by Csaba Osztrogonác.

        Added missing methods for the MacroAssemblerMIPS, based on the MacroAssemblerARMv7.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::canJumpReplacePatchableBranchPtrWithPatch):
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::startOfPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerMIPS::revertJumpReplacementToPatchableBranchPtrWithPatch):

2012-11-14  Peter Gal  <galpeter@inf.u-szeged.hu>

        Fix the [-Wreturn-type] warning in JavaScriptCore/assembler/MacroAssemblerARM.h
        https://bugs.webkit.org/show_bug.cgi?id=102206

        Reviewed by Csaba Osztrogonác.

        Add a return value for the function to suppress the warning.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatch):

2012-11-14  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r134599.
        http://trac.webkit.org/changeset/134599
        https://bugs.webkit.org/show_bug.cgi?id=102225

        It broke the 32 bit EFL build (Requested by Ossy on #webkit).

        * jit/JITPropertyAccess.cpp:
        * jit/JITPropertyAccess32_64.cpp:
        (JSC):
        (JSC::JIT::emitGenericContiguousPutByVal):

2012-11-14  Balazs Kilvady  <kilvadyb@homejinni.com>

        [Qt][ARM]REGRESSION(r133985): It broke the build
        https://bugs.webkit.org/show_bug.cgi?id=101740

        Reviewed by Csaba Osztrogonác.

        Template function body moved to fix VALUE_PROFILER disabled case.

        * jit/JITPropertyAccess.cpp:
        (JSC):
        (JSC::JIT::emitGenericContiguousPutByVal):
        * jit/JITPropertyAccess32_64.cpp:

2012-11-13  Filip Pizlo  <fpizlo@apple.com>

        DFG CreateThis should be able to statically account for the structure of the object it creates, if profiling indicates that this structure is always the same
        https://bugs.webkit.org/show_bug.cgi?id=102017

        Reviewed by Geoffrey Garen.

        This adds a watchpoint in JSFunction on the cached inheritor ID. It also changes
        NewObject to take a structure as an operand (previously it implicitly used the owning
        global object's empty object structure). Any GetCallee where the callee is predictable
        is turned into a CheckFunction + WeakJSConstant, and any CreateThis on a WeakJSConstant
        where the inheritor ID watchpoint is still valid is turned into an InheritorIDWatchpoint
        followed by a NewObject. NewObject already accounts for the structure it uses for object
        creation in the CFA.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::checkFunctionElimination):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasFunction):
        (JSC::DFG::Node::function):
        (JSC::DFG::Node::hasStructure):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/Executable.h:
        (JSC::JSFunction::JSFunction):
        * runtime/JSBoundFunction.cpp:
        (JSC):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::JSFunction):
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSFunction.h:
        (JSC::JSFunction::tryGetKnownInheritorID):
        (JSFunction):
        (JSC::JSFunction::addInheritorIDWatchpoint):

2012-11-13  Filip Pizlo  <fpizlo@apple.com>

        JSFunction and its descendants should be destructible
        https://bugs.webkit.org/show_bug.cgi?id=102062

        Reviewed by Mark Hahnenberg.

        This will make it easy to place an InlineWatchpointSet inside JSFunction. In the
        future, we could make JSFunction non-destructible again by making a version of
        WatchpointSet that is entirely GC'd, but this seems like overkill for now.
        
        This is performance-neutral.

        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::destroy):
        (JSC):
        * runtime/JSBoundFunction.h:
        (JSBoundFunction):
        * runtime/JSFunction.cpp:
        (JSC):
        (JSC::JSFunction::destroy):
        * runtime/JSFunction.h:
        (JSFunction):

2012-11-13  Cosmin Truta  <ctruta@rim.com>

        Uninitialized fields in class JSLock
        https://bugs.webkit.org/show_bug.cgi?id=101695

        Reviewed by Mark Hahnenberg.

        Initialize JSLock::m_ownerThread and JSLock::m_lockDropDepth.

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

2012-11-13  Peter Gal  <galpeter@inf.u-szeged.hu>

        Fix the ARM traditional build after r134332
        https://bugs.webkit.org/show_bug.cgi?id=102044

        Reviewed by Zoltan Herczeg.

        Added missing methods for the MacroAssemblerARM, based on the MacroAssemblerARMv7.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::canJumpReplacePatchableBranchPtrWithPatch):
        (MacroAssemblerARM):
        (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerARM::revertJumpReplacementToPatchableBranchPtrWithPatch):

2012-11-12  Filip Pizlo  <fpizlo@apple.com>

        op_get_callee should have value profiling
        https://bugs.webkit.org/show_bug.cgi?id=102047

        Reviewed by Sam Weinig.

        This will allow us to detect if the callee is always the same, which is probably
        the common case for a lot of constructors.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_callee):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_callee):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2012-11-12  Filip Pizlo  <fpizlo@apple.com>

        The act of getting the callee during 'this' construction should be explicit in bytecode
        https://bugs.webkit.org/show_bug.cgi?id=102016

        Reviewed by Michael Saboff.

        This is mostly a rollout of http://trac.webkit.org/changeset/116673, but also includes
        changes to have create_this use the result of get_callee.
        
        No performance or behavioral impact. This is just meant to allow us to profile
        get_callee in the future.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        (JIT):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_callee):
        (JSC):
        (JSC::JIT::emit_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_callee):
        (JSC):
        (JSC::JIT::emit_op_create_this):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2012-11-12  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix ARMv7 build.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranchPtrWithPatch):

2012-11-12  Filip Pizlo  <fpizlo@apple.com>

        Patching of jumps to stubs should use jump replacement rather than branch destination overwrite
        https://bugs.webkit.org/show_bug.cgi?id=101909

        Reviewed by Geoffrey Garen.

        This saves a few instructions in inline cases, on those architectures where it is
        easy to figure out where to put the jump replacement. Sub-1% speed-up across the
        board.

        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::canJumpReplacePatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranchPtrWithPatch):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::canJumpReplacePatchableBranchPtrWithPatch):
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::startOfPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerX86::revertJumpReplacementToPatchableBranchPtrWithPatch):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch):
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::startOfPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch):
        * assembler/RepatchBuffer.h:
        (JSC::RepatchBuffer::startOfPatchableBranchPtrWithPatch):
        (RepatchBuffer):
        (JSC::RepatchBuffer::replaceWithJump):
        (JSC::RepatchBuffer::revertJumpReplacementToPatchableBranchPtrWithPatch):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::revertJumpTo_movq_i64r):
        (JSC::X86Assembler::revertJumpTo_cmpl_im_force32):
        (X86InstructionFormatter):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::replaceWithJump):
        (DFG):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::tryBuildGetByIDProtoList):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::dfgResetGetByID):
        (JSC::DFG::dfgResetPutByID):

2012-11-11  Filip Pizlo  <fpizlo@apple.com>

        DFG ArithMul overflow check elimination is too aggressive
        https://bugs.webkit.org/show_bug.cgi?id=101871

        Reviewed by Oliver Hunt.

        The code was ignoring the fact that ((a * b) | 0) == (((a | 0) * (b | 0)) | 0)
        only holds if a * b < 2^53. So, I changed it to only enable the optimization
        when a < 2^22 and b is an int32 (and vice versa), using a super trivial peephole
        analysis to prove the inequality. I considered writing an epic forward flow
        formulation that tracks the ranges of integer values but then I thought better
        of it.
        
        This also rewires the ArithMul integer speculation logic. Previously, we would
        assume that an ArithMul was only UsedAsNumber if it escaped, and separately we
        would decide whether to speculate integer based on a proof of the <2^22
        inequality. Now, we treat the double rounding behavior of ArithMul as if the
        result was UsedAsNumber even if it did not escape. Then we try to prove that
        double rounding cannot happen by attemping to prove that a < 2^22. This then
        feeds back into the decision of whether or not to speculate integer (if we fail
        to prove a < 2^22 then we're UsedAsNumber, and if we're also MayOverflow then
        that forces double speculation).
        
        No performance impact. It just fixes a bug.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::mulShouldSpeculateInteger):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (PredictionPropagationPhase):
        (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant):
        (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive):
        (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo):
        (JSC::DFG::PredictionPropagationPhase::propagate):

2012-11-11  Filip Pizlo  <fpizlo@apple.com>

        DFG should not emit function checks if we've already proved that the operand is that exact function
        https://bugs.webkit.org/show_bug.cgi?id=101885

        Reviewed by Oliver Hunt.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::filterByValue):
        (AbstractValue):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):

2012-11-12  Kentaro Hara  <haraken@chromium.org>

        [V8][JSC] ScriptProfileNode::callUID needs not to be [Custom]
        https://bugs.webkit.org/show_bug.cgi?id=101892

        Reviewed by Adam Barth.

        Added callUID(), which enables us to kill custom bindings for ScriptProfileNode::callUID.

        * profiler/ProfileNode.h:
        (JSC::ProfileNode::callUID):

2012-11-12  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing header.

2012-11-11  Michael Pruett  <michael@68k.org>

        Fix assertion failure in JSObject::tryGetIndexQuickly()
        https://bugs.webkit.org/show_bug.cgi?id=101869

        Reviewed by Filip Pizlo.

        Currently JSObject::tryGetIndexQuickly() triggers an assertion
        failure when the object has an undecided indexing type. This
        case should be treated the same as a blank indexing type.

        * runtime/JSObject.h:
        (JSC::JSObject::tryGetIndexQuickly):

2012-11-11  Filip Pizlo  <fpizlo@apple.com>

        DFG register allocation should be greedy rather than round-robin
        https://bugs.webkit.org/show_bug.cgi?id=101870

        Reviewed by Geoffrey Garen.

        This simplifies the code, reduces some code duplication, and shows some slight
        performance improvements in a few places, likely due to the fact that lower-numered
        registers also typically have smaller encodings.

        * dfg/DFGRegisterBank.h:
        (JSC::DFG::RegisterBank::RegisterBank):
        (JSC::DFG::RegisterBank::tryAllocate):
        (JSC::DFG::RegisterBank::allocate):
        (JSC::DFG::RegisterBank::allocateInternal):
        (RegisterBank):

2012-11-11  Kenichi Ishibashi  <bashi@chromium.org>

        WTFString::utf8() should have a mode of conversion to use replacement character
        https://bugs.webkit.org/show_bug.cgi?id=101678

        Reviewed by Alexey Proskuryakov.

        Follow the change on String::utf8()

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode): Pass String::StrictConversion instead of true to String::utf8().

2012-11-10  Filip Pizlo  <fpizlo@apple.com>

        DFG should optimize out the NaN check on loads from double arrays if the array prototype chain is having a great time
        https://bugs.webkit.org/show_bug.cgi?id=101718

        Reviewed by Geoffrey Garen.

        If we're reading from a JSArray in double mode, where the array's structure is
        primordial (all aspects of the structure are unchanged except for indexing type),
        and the result of the load is used in arithmetic that is known to not distinguish
        between NaN and undefined, then we should not emit a NaN check. Looks like a 5%
        win on navier-stokes.
        
        Also fixed an OpInfo initialization goof for String ops that was revealed by this
        change.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::arraySpeculationToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::isSaneChain):
        (ArrayMode):
        (JSC::DFG::ArrayMode::isInBounds):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::nodeFlagsAsString):
        * dfg/DFGNodeFlags.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
        (JSC):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):

2012-11-10  Filip Pizlo  <fpizlo@apple.com>

        DFG constant folding and CFG simplification should be smart enough to know that if a logical op's operand is proven to have a non-masquerading structure then it always evaluates to true
        https://bugs.webkit.org/show_bug.cgi?id=101511

        Reviewed by Geoffrey Garen.
        
        This is the second attempt at this patch, which fixes the !"" case.

        To make life easier, this moves BranchDirection into BasicBlock so that after
        running the CFA, we always know, for each block, what direction the CFA
        proved. CFG simplification now both uses and preserves cfaBranchDirection in
        its transformations.
        
        Also made both LogicalNot and Branch check whether the operand is a known cell
        with a known structure, and if so, made them do the appropriate folding.
        
        5% speed-up on V8/raytrace because it makes raytrace's own null checks
        evaporate (i.e. idioms like 'if (!x) throw "unhappiness"') thanks to the fact
        that we were already doing structure check hoisting.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::BasicBlock):
        (BasicBlock):
        * dfg/DFGBranchDirection.h: Added.
        (DFG):
        (JSC::DFG::branchDirectionToString):
        (JSC::DFG::isKnownDirection):
        (JSC::DFG::branchCondition):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):

2012-11-10  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r133971.
        http://trac.webkit.org/changeset/133971
        https://bugs.webkit.org/show_bug.cgi?id=101839

        Causes WebProcess to hang at 100% on www.apple.com (Requested
        by kling on #webkit).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::branchDirectionToString):
        (AbstractState):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::BasicBlock):
        (BasicBlock):
        * dfg/DFGBranchDirection.h: Removed.
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):

2012-11-09  Filip Pizlo  <fpizlo@apple.com>

        If the DFG ArrayMode says that an access is on an OriginalArray, then the checks should always enforce this
        https://bugs.webkit.org/show_bug.cgi?id=101720

        Reviewed by Mark Hahnenberg.

        Previously, "original" arrays was just a hint that we could find the structure
        of the array if we needed to even if the array profile didn't have it due to
        polymorphism. Now, "original" arrays are a property that is actually checked:
        if an array access has ArrayMode::arrayClass() == Array::OriginalArray, then we
        can be sure that the code performing the access is dealing with not just a
        JSArray, but a JSArray that has no named properties, no indexed accessors, and
        the ArrayPrototype as its prototype. This will be useful for optimizations that
        are being done as part of https://bugs.webkit.org/show_bug.cgi?id=101720.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::originalArrayStructure):
        (DFG):
        (JSC::DFG::ArrayMode::alreadyChecked):
        * dfg/DFGArrayMode.h:
        (JSC):
        (DFG):
        (JSC::DFG::ArrayMode::withProfile):
        (ArrayMode):
        (JSC::DFG::ArrayMode::benefitsFromOriginalArray):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):

2012-11-09  Filip Pizlo  <fpizlo@apple.com>

        Fix indentation of BooleanPrototype.h

        Rubber stamped by Mark Hahnenberg.

        * runtime/BooleanPrototype.h:

2012-11-09  Filip Pizlo  <fpizlo@apple.com>

        Fix indentation of BooleanObject.h

        Rubber stamped by Mark Hahnenberg.

        * runtime/BooleanObject.h:

2012-11-09  Filip Pizlo  <fpizlo@apple.com>

        Fix indentation of BooleanConstructor.h

        Rubber stamped by Mark Hahnenberg.

        * runtime/BooleanConstructor.h:

2012-11-09  Filip Pizlo  <fpizlo@apple.com>

        Fix indentation of BatchedTransitionOptimizer.h

        Rubber stamped by Mark Hahnenberg.

        * runtime/BatchedTransitionOptimizer.h:

2012-11-09  Oliver Hunt  <oliver@apple.com>

        So Thingy probably isn't the best name for a class, so
        renamed to CacheMap.

        RS=Geoff

        * runtime/CodeCache.h:
        (JSC::CacheMap::CacheMap):

2012-11-09  Filip Pizlo  <fpizlo@apple.com>

        ArrayPrototype should start out with a blank indexing type
        https://bugs.webkit.org/show_bug.cgi?id=101719

        Reviewed by Mark Hahnenberg.

        This allows us to track if the array prototype ever ends up with indexed
        properties.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::create):
        (JSC::ArrayPrototype::ArrayPrototype):
        * runtime/ArrayPrototype.h:
        (ArrayPrototype):
        (JSC::ArrayPrototype::createStructure):

2012-11-08  Mark Hahnenberg  <mhahnenberg@apple.com>

        MarkStackArray should use the BlockAllocator instead of the MarkStackSegmentAllocator
        https://bugs.webkit.org/show_bug.cgi?id=101642

        Reviewed by Filip Pizlo.

        MarkStackSegmentAllocator is like a miniature version of the BlockAllocator. Now that the BlockAllocator has support 
        for a variety of block sizes, we should get rid of the MarkStackSegmentAllocator in favor of the BlockAllocator.

        * heap/BlockAllocator.h: Add new specializations of regionSetFor for the new MarkStackSegments.
        (JSC):
        (JSC::MarkStackSegment):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        (JSC::GCThreadSharedData::reset):
        * heap/GCThreadSharedData.h:
        (GCThreadSharedData):
        * heap/MarkStack.cpp: 
        (JSC::MarkStackArray::MarkStackArray): We now have a doubly linked list of MarkStackSegments, so we need to refactor 
        all the places that used the old custom tail/previous logic.
        (JSC::MarkStackArray::~MarkStackArray):
        (JSC::MarkStackArray::expand):
        (JSC::MarkStackArray::refill):
        (JSC::MarkStackArray::donateSomeCellsTo): Refactor to use the new linked list.
        (JSC::MarkStackArray::stealSomeCellsFrom): Ditto.
        * heap/MarkStack.h:
        (JSC):
        (MarkStackSegment):
        (JSC::MarkStackSegment::MarkStackSegment):
        (JSC::MarkStackSegment::sizeFromCapacity):
        (MarkStackArray):
        * heap/MarkStackInlines.h:
        (JSC::MarkStackSegment::create):
        (JSC):
        (JSC::MarkStackArray::postIncTop):
        (JSC::MarkStackArray::preDecTop):
        (JSC::MarkStackArray::setTopForFullSegment):
        (JSC::MarkStackArray::setTopForEmptySegment):
        (JSC::MarkStackArray::top):
        (JSC::MarkStackArray::validatePrevious):
        (JSC::MarkStackArray::append):
        (JSC::MarkStackArray::removeLast):
        (JSC::MarkStackArray::isEmpty):
        (JSC::MarkStackArray::size):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):

2012-11-09  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        [Qt] r133953 broke the ARM_TRADITIONAL build
        https://bugs.webkit.org/show_bug.cgi?id=101706

        Reviewed by Csaba Osztrogonác.

        Fix for both hardfp and softfp.

        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):

2012-11-09  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r134051.
        http://trac.webkit.org/changeset/134051
        https://bugs.webkit.org/show_bug.cgi?id=101757

        It didn't fix the build (Requested by Ossy on #webkit).

        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):

2012-11-09  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        [Qt] r133953 broke the ARM_TRADITIONAL build
        https://bugs.webkit.org/show_bug.cgi?id=101706

        Reviewed by Csaba Osztrogonác.

        Fix the ARM_TRADITIONAL build after r133953

        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):

2012-11-09  Csaba Osztrogonác  <ossy@webkit.org>

        [Qt] Fix the LLINT build from ARMv7 platform
        https://bugs.webkit.org/show_bug.cgi?id=101712

        Reviewed by Simon Hausmann.

        Enable generating of LLIntAssembly.h on ARM platforms.

        * DerivedSources.pri:
        * JavaScriptCore.pro:

2012-11-08  Filip Pizlo  <fpizlo@apple.com>

        ArrayPrototype.h should have correct indentation

        Rubber stamped by Sam Weinig.

        * runtime/ArrayPrototype.h:

2012-11-08  Mark Lam  <mark.lam@apple.com>

        Renamed ...InlineMethods.h files to ...Inlines.h.
        https://bugs.webkit.org/show_bug.cgi?id=101145.

        Reviewed by Geoffrey Garen.

        This is only a refactoring effort to rename the files. There are no
        functionality changes.

        * API/JSObjectRef.cpp:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        * dfg/DFGOperations.cpp:
        * heap/ConservativeRoots.cpp:
        * heap/CopiedBlock.h:
        * heap/CopiedSpace.cpp:
        * heap/CopiedSpaceInlineMethods.h: Removed.
        * heap/CopiedSpaceInlines.h: Copied from Source/JavaScriptCore/heap/CopiedSpaceInlineMethods.h.
        * heap/CopyVisitor.cpp:
        * heap/CopyVisitorInlineMethods.h: Removed.
        * heap/CopyVisitorInlines.h: Copied from Source/JavaScriptCore/heap/CopyVisitorInlineMethods.h.
        * heap/GCThread.cpp:
        * heap/GCThreadSharedData.cpp:
        * heap/HandleStack.cpp:
        * heap/Heap.cpp:
        * heap/HeapRootVisitor.h:
        * heap/MarkStack.cpp:
        * heap/MarkStackInlineMethods.h: Removed.
        * heap/MarkStackInlines.h: Copied from Source/JavaScriptCore/heap/MarkStackInlineMethods.h.
        * heap/SlotVisitor.cpp:
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlineMethods.h: Removed.
        * heap/SlotVisitorInlines.h: Copied from Source/JavaScriptCore/heap/SlotVisitorInlineMethods.h.
        * jit/HostCallReturnValue.cpp:
        * jit/JIT.cpp:
        * jit/JITArithmetic.cpp:
        * jit/JITArithmetic32_64.cpp:
        * jit/JITCall.cpp:
        * jit/JITCall32_64.cpp:
        * jit/JITInlineMethods.h: Removed.
        * jit/JITInlines.h: Copied from Source/JavaScriptCore/jit/JITInlineMethods.h.
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITPropertyAccess.cpp:
        * jit/JITPropertyAccess32_64.cpp:
        * jsc.cpp:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayPrototype.cpp:
        * runtime/ButterflyInlineMethods.h: Removed.
        * runtime/ButterflyInlines.h: Copied from Source/JavaScriptCore/runtime/ButterflyInlineMethods.h.
        * runtime/IndexingHeaderInlineMethods.h: Removed.
        * runtime/IndexingHeaderInlines.h: Copied from Source/JavaScriptCore/runtime/IndexingHeaderInlineMethods.h.
        * runtime/JSActivation.h:
        * runtime/JSArray.cpp:
        * runtime/JSArray.h:
        * runtime/JSCell.h:
        * runtime/JSObject.cpp:
        * runtime/JSValueInlineMethods.h: Removed.
        * runtime/JSValueInlines.h: Copied from Source/JavaScriptCore/runtime/JSValueInlineMethods.h.
        * runtime/LiteralParser.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/Operations.h:
        * runtime/RegExpMatchesArray.cpp:
        * runtime/RegExpObject.cpp:
        * runtime/StringPrototype.cpp:

2012-11-08  Filip Pizlo  <fpizlo@apple.com>

        ArrayConstructor.h should have correct indentation

        Rubber stamped by Sam Weinig.

        * runtime/ArrayConstructor.h:

2012-11-08  Filip Pizlo  <fpizlo@apple.com>

        DFG should know that int == null is always false
        https://bugs.webkit.org/show_bug.cgi?id=101665

        Reviewed by Oliver Hunt.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):

2012-11-08  Filip Pizlo  <fpizlo@apple.com>

        Arguments.h should have correct indentation

        Rubber stamped by Sam Weinig.

        * runtime/Arguments.h:

2012-11-08  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to JIT compile get_by_vals and put_by_vals even if the DFG is disabled.

        Reviewed by Oliver Hunt.

        * jit/JITInlineMethods.h:
        (JSC::JIT::chooseArrayMode):

2012-11-08  Filip Pizlo  <fpizlo@apple.com>

        op_call should have LLInt call link info even if the DFG is disabled
        https://bugs.webkit.org/show_bug.cgi?id=101672

        Reviewed by Oliver Hunt.

        Get rid of the evil uses of fall-through.

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

2012-11-08  Oliver Hunt  <oliver@apple.com>

        Improve effectiveness of function-level caching
        https://bugs.webkit.org/show_bug.cgi?id=101667

        Reviewed by Filip Pizlo.

        Added a random-eviction based cache for unlinked functions, and switch
        UnlinkedFunctionExecutable's code references to Weak<>, thereby letting
        us remove the explicit UnlinkedFunctionExecutable::clearCode() calls that
        were being triggered by GC.

        Refactored the random eviction part of the CodeCache into a separate data
        structure so that I didn't have to duplicate the code again, and then used
        that for the new function cache.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::clearCodeForRecompilation):
        (UnlinkedFunctionExecutable):
        * debugger/Debugger.cpp:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getCodeBlock):
        (JSC::CodeCache::generateFunctionCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        (JSC::CodeCache::usedFunctionCode):
        (JSC):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling):
        (JSC::FunctionExecutable::clearCode):
        * runtime/Executable.h:
        (FunctionExecutable):

2012-11-07  Filip Pizlo  <fpizlo@apple.com>

        DFG constant folding and CFG simplification should be smart enough to know that if a logical op's operand is proven to have a non-masquerading structure then it always evaluates to true
        https://bugs.webkit.org/show_bug.cgi?id=101511

        Reviewed by Oliver Hunt.

        To make life easier, this moves BranchDirection into BasicBlock so that after
        running the CFA, we always know, for each block, what direction the CFA
        proved. CFG simplification now both uses and preserves cfaBranchDirection in
        its transformations.
        
        Also made both LogicalNot and Branch check whether the operand is a known cell
        with a known structure, and if so, made them do the appropriate folding.
        
        5% speed-up on V8/raytrace because it makes raytrace's own null checks
        evaporate (i.e. idioms like 'if (!x) throw "unhappiness"') thanks to the fact
        that we were already doing structure check hoisting.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::BasicBlock):
        (BasicBlock):
        * dfg/DFGBranchDirection.h: Added.
        (DFG):
        (JSC::DFG::branchDirectionToString):
        (JSC::DFG::isKnownDirection):
        (JSC::DFG::branchCondition):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):

2012-11-08  Christophe Dumez  <christophe.dumez@intel.com>

        [JSC] HTML extensions to String.prototype should escape " as &quot; in argument values
        https://bugs.webkit.org/show_bug.cgi?id=90667

        Reviewed by Benjamin Poulain.

        Escape quotation mark as &quot; in argument values to:
        - String.prototype.anchor(name)
        - String.prototype.fontcolor(color)
        - String.prototype.fontsize(size)
        - String.prototype.link(href)

        This behavior matches Chromium/V8 and Firefox/Spidermonkey
        implementations and is requited by:
        http://mathias.html5.org/specs/javascript/#escapeattributevalue

        This also fixes a potential security risk (XSS vector).

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncFontcolor):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncAnchor):
        (JSC::stringProtoFuncLink):

2012-11-08  Anders Carlsson  <andersca@apple.com>

        HeapStatistics::s_pauseTimeStarts and s_pauseTimeEnds should be Vectors
        https://bugs.webkit.org/show_bug.cgi?id=101651

        Reviewed by Andreas Kling.

        HeapStatistics uses Deques when Vectors would work just as good.

        * heap/HeapStatistics.cpp:
        * heap/HeapStatistics.h:
        (HeapStatistics):

2012-11-07  Filip Pizlo  <fpizlo@apple.com>

        DFG should not assume that something is a double just because it might be undefined
        https://bugs.webkit.org/show_bug.cgi?id=101438

        Reviewed by Oliver Hunt.

        This changes all non-bitop arithmetic to (a) statically expect that variables are
        defined prior to use in arithmetic and (b) not fall off into double paths just
        because a value may not be a number. This is accomplished with two new notions of
        speculation:
        
        shouldSpeculateIntegerExpectingDefined: Should we speculate that the value is an
        integer if we ignore undefined (i.e. SpecOther) predictions?
        
        shouldSpeculateIntegerForArithmetic: Should we speculate that the value is an
        integer if we ignore non-numeric predictions?
        
        This is a ~2x speed-up on programs that seem to our prediction propagator to have
        paths in which otherwise numeric variables are undefined.

        * bytecode/SpeculatedType.h:
        (JSC::isInt32SpeculationForArithmetic):
        (JSC):
        (JSC::isInt32SpeculationExpectingDefined):
        (JSC::isDoubleSpeculationForArithmetic):
        (JSC::isNumberSpeculationExpectingDefined):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateInteger):
        (JSC::DFG::Graph::mulShouldSpeculateInteger):
        (JSC::DFG::Graph::negateShouldSpeculateInteger):
        (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
        (JSC::DFG::Graph::mulImmediateShouldSpeculateInteger):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateIntegerForArithmetic):
        (Node):
        (JSC::DFG::Node::shouldSpeculateIntegerExpectingDefined):
        (JSC::DFG::Node::shouldSpeculateDoubleForArithmetic):
        (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAdd):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):

2012-11-06  Filip Pizlo  <fpizlo@apple.com>

        JSC should infer when indexed storage contains only integers or doubles
        https://bugs.webkit.org/show_bug.cgi?id=98606

        Reviewed by Oliver Hunt.

        This adds two new indexing types: int32 and double. It also adds array allocation profiling,
        which allows array allocations to converge to allocating arrays using those types to which
        those arrays would have been converted.
        
        20% speed-up on navier-stokes. 40% speed-up on various Kraken DSP tests. Some slow-downs too,
        but a performance win overall on all benchmarks we track.

        * API/JSObjectRef.cpp:
        (JSObjectMakeArray):
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/AbstractMacroAssembler.h:
        (JumpList):
        (JSC::AbstractMacroAssembler::JumpList::JumpList):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::jnp):
        (X86Assembler):
        (JSC::X86Assembler::X86InstructionFormatter::emitRex):
        * bytecode/ArrayAllocationProfile.cpp: Added.
        (JSC):
        (JSC::ArrayAllocationProfile::updateIndexingType):
        * bytecode/ArrayAllocationProfile.h: Added.
        (JSC):
        (ArrayAllocationProfile):
        (JSC::ArrayAllocationProfile::ArrayAllocationProfile):
        (JSC::ArrayAllocationProfile::selectIndexingType):
        (JSC::ArrayAllocationProfile::updateLastAllocation):
        (JSC::ArrayAllocationProfile::selectIndexingTypeFor):
        (JSC::ArrayAllocationProfile::updateLastAllocationFor):
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::updatedObservedArrayModes):
        (JSC):
        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::arrayModesInclude):
        (JSC::shouldUseSlowPutArrayStorage):
        (JSC::shouldUseFastArrayStorage):
        (JSC::shouldUseContiguous):
        (JSC::shouldUseDouble):
        (JSC::shouldUseInt32):
        (ArrayProfile):
        * bytecode/ByValInfo.h:
        (JSC::isOptimizableIndexingType):
        (JSC::jitArrayModeForIndexingType):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC):
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::updateAllArrayPredictions):
        (JSC::CodeBlock::updateAllPredictions):
        (JSC::CodeBlock::shouldOptimizeNow):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::numberOfArrayAllocationProfiles):
        (JSC::CodeBlock::addArrayAllocationProfile):
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::updateAllArrayPredictions):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        * bytecode/Instruction.h:
        (JSC):
        (JSC::Instruction::Instruction):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/SpeculatedType.h:
        (JSC):
        (JSC::isRealNumberSpeculation):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC):
        (JSC::UnlinkedCodeBlock::addArrayAllocationProfile):
        (JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles):
        (UnlinkedCodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::newArrayAllocationProfile):
        (JSC):
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::refine):
        (DFG):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayTypeToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::withType):
        (ArrayMode):
        (JSC::DFG::ArrayMode::withTypeAndConversion):
        (JSC::DFG::ArrayMode::usesButterfly):
        (JSC::DFG::ArrayMode::isSpecific):
        (JSC::DFG::ArrayMode::supportsLength):
        (JSC::DFG::ArrayMode::arrayModesThatPassFiltering):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::generateInternal):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::generateInternal):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGNode.h:
        (NewArrayBufferData):
        (JSC::DFG::Node::hasIndexingType):
        (Node):
        (JSC::DFG::Node::indexingType):
        (JSC::DFG::Node::setIndexingType):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (DFG):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        (SpeculateIntegerOperand):
        (JSC::DFG::SpeculateIntegerOperand::use):
        (SpeculateDoubleOperand):
        (JSC::DFG::SpeculateDoubleOperand::use):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        (JSC::JIT::emitInt32GetByVal):
        (JIT):
        (JSC::JIT::emitInt32PutByVal):
        (JSC::JIT::emitDoublePutByVal):
        (JSC::JIT::emitContiguousPutByVal):
        * jit/JITExceptions.cpp:
        (JSC::genericThrow):
        * jit/JITInlineMethods.h:
        (JSC::arrayProfileSaw):
        (JSC::JIT::chooseArrayMode):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emit_op_new_array_with_size):
        (JSC::JIT::emit_op_new_array_buffer):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitDoubleGetByVal):
        (JSC):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompilePutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitDoubleGetByVal):
        (JSC):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitSlow_op_put_by_val):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:
        (JSC):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/x86.rb:
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/ArrayConstructor.h:
        (JSC):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoFuncFilter):
        (JSC::arrayProtoFuncMap):
        * runtime/Butterfly.h:
        (JSC::Butterfly::contiguousInt32):
        (JSC::Butterfly::contiguousDouble):
        (JSC::Butterfly::fromContiguous):
        * runtime/ButterflyInlineMethods.h:
        (JSC::Butterfly::createUninitializedDuringCollection):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/IndexingHeaderInlineMethods.h:
        (JSC::IndexingHeader::indexingPayloadSizeInBytes):
        * runtime/IndexingType.cpp:
        (JSC::leastUpperBoundOfIndexingTypes):
        (JSC):
        (JSC::leastUpperBoundOfIndexingTypeAndType):
        (JSC::leastUpperBoundOfIndexingTypeAndValue):
        (JSC::indexingTypeToString):
        * runtime/IndexingType.h:
        (JSC):
        (JSC::hasUndecided):
        (JSC::hasInt32):
        (JSC::hasDouble):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::compareNumbersForQSortWithInt32):
        (JSC):
        (JSC::compareNumbersForQSortWithDouble):
        (JSC::JSArray::sortNumericVector):
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sortCompactedVector):
        (JSC::JSArray::sort):
        (JSC::JSArray::sortVector):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSArray):
        (JSC::createContiguousArrayButterfly):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        (JSC::JSGlobalObject::haveABadTime):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::originalArrayStructureForIndexingType):
        (JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation):
        (JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation):
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        (JSC::constructEmptyArray):
        (JSC::constructArray):
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (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::convertDoubleToContiguous):
        (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::ensureArrayStorageSlow):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::countElements):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (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):
        (JSObject):
        (JSC::JSObject::ensureInt32):
        (JSC::JSObject::ensureDouble):
        (JSC::JSObject::ensureLength):
        (JSC::JSObject::indexingData):
        (JSC::JSObject::currentIndexingData):
        (JSC::JSObject::getHolyIndexQuickly):
        (JSC::JSObject::relevantLength):
        (JSC::JSObject::currentRelevantLength):
        * runtime/JSValue.cpp:
        (JSC::JSValue::description):
        * runtime/LiteralParser.cpp:
        (JSC::::parse):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorKeys):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):
        (JSC::stringProtoFuncSplit):
        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):
        * runtime/StructureTransitionTable.h:
        (JSC::newIndexingType):

2012-11-08  Balazs Kilvady  <kilvadyb@homejinni.com>

        ASSERT problem on MIPS
        https://bugs.webkit.org/show_bug.cgi?id=100589

        Reviewed by Oliver Hunt.

        ASSERT fix for MIPS arch.

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

2012-11-08  Michael Saboff  <msaboff@apple.com>

        OpaqueJSClassContextData() should use StringImpl::isolatedCopy() to make string copies
        https://bugs.webkit.org/show_bug.cgi?id=101507

        Reviewed by Andreas Kling.

        Changed to use isolatedCopy() for key Strings.

        * API/JSClassRef.cpp:
        (OpaqueJSClassContextData::OpaqueJSClassContextData):

2012-11-07  Mark Hahnenberg  <mhahnenberg@apple.com>

        WeakBlocks should be HeapBlocks
        https://bugs.webkit.org/show_bug.cgi?id=101411

        Reviewed by Oliver Hunt.

        Currently WeakBlocks use fastMalloc memory. They are very similar to the other HeapBlocks, however, 
        so we should change them to being allocated with the BlockAllocator.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::BlockAllocator):
        * heap/BlockAllocator.h: Added a new RegionSet for WeakBlocks.
        (JSC):
        (BlockAllocator):
        (JSC::WeakBlock):
        * heap/Heap.h: Friended WeakSet to allow access to the BlockAllocator.
        (Heap):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create): Refactored to use HeapBlocks rather than fastMalloc.
        (JSC::WeakBlock::WeakBlock):
        * heap/WeakBlock.h: Changed the WeakBlock size to 4 KB so that it divides evenly into the Region size.
        (JSC):
        (WeakBlock):
        * heap/WeakSet.cpp:
        (JSC::WeakSet::~WeakSet):
        (JSC::WeakSet::addAllocator):

2012-11-07  Filip Pizlo  <fpizlo@apple.com>

        Indentation of ArgList.h is wrong
        https://bugs.webkit.org/show_bug.cgi?id=101441

        Reviewed by Andreas Kling.

        Just unindented by 4 spaces.

        * runtime/ArgList.h:

2012-11-07  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        [Qt][ARM] REGRESSION(r133688): It made all JSC and layout tests crash on ARM traditional platform
        https://bugs.webkit.org/show_bug.cgi?id=101465

        Reviewed by Oliver Hunt.

        Fix failing javascriptcore tests on ARM after r133688

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

2012-11-06  Oliver Hunt  <oliver@apple.com>

        Reduce parser overhead in JSC
        https://bugs.webkit.org/show_bug.cgi?id=101127

        Reviewed by Filip Pizlo.

        An exciting journey into the world of architecture in which our hero
        adds yet another layer to JSC codegeneration.

        This patch adds a marginally more compact form of bytecode that is
        free from any data specific to a given execution context, and that
        does store any data structures necessary for execution.  To actually
        execute this UnlinkedBytecode we still need to instantiate a real
        CodeBlock, but this is a much faster linear time operation than any
        of the earlier parsing or code generation passes.

        As the unlinked code is context free we can then simply use a cache
        from source to unlinked code mapping to completely avoid all of the
        old parser overhead.  The cache is currently very simple and memory
        heavy, using the complete source text as a key (rather than SourceCode
        or equivalent), and a random eviction policy.

        This seems to produce a substantial win when loading identical content
        in different contexts.

        * API/tests/testapi.c:
        (main):
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
            Moved a number of fields, and a bunch of logic to UnlinkedCodeBlock.h/cpp
        * bytecode/Opcode.h:
            Added a global const init no op instruction needed to get correct
            behaviour without any associated semantics.
        * bytecode/UnlinkedCodeBlock.cpp: Added.
        * bytecode/UnlinkedCodeBlock.h: Added.
            A fairly shallow, GC allocated version of the old CodeBlock
            classes with a 32bit instruction size, and just metadata
            size tracking.
        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
            Replace direct access to m_symbolTable with access through
            symbolTable().  ProgramCode no longer has a symbol table at
            all so some previously unconditional (and pointless) uses
            of symbolTable get null checks.
            A few other changes to deal with type changes due to us generating
            unlinked code (eg. pointer free, so profile indices rather than
            pointers).
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCapabilities.h:
            Support global_init_nop        
        * interpreter/Interpreter.cpp:
            Now get the ProgramExecutable to initialise new global properties
            before starting execution.        
        * jit/JIT.cpp:
        * jit/JITDriver.h:
        * jit/JITStubs.cpp:
        * llint/LLIntData.cpp:
        * llint/LLIntSlowPaths.cpp:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
            Adding init_global_const_nop everywhere else
        * parser/Parser.h:
        * parser/ParserModes.h: Added.
        * parser/ParserTokens.h:
            Parser no longer needs a global object or callframe to function        
        * runtime/CodeCache.cpp: Added.
        * runtime/CodeCache.h: Added.
            A simple, random eviction, Source->UnlinkedCode cache        
        * runtime/Executable.cpp:
        * runtime/Executable.h:
            Executables now reference their unlinked counterparts, and
            request code specifically for the target global object.        
        * runtime/JSGlobalData.cpp:
        * runtime/JSGlobalData.h:
            GlobalData now owns a CodeCache and a set of new structures
            for the unlinked code types.  
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
            Utility functions used by executables to perform compilation
 
        * runtime/JSType.h:
          Add new JSTypes for unlinked code

2012-11-06  Michael Saboff  <msaboff@apple.com>

        JSStringCreateWithCFString() Should create an 8 bit String if possible
        https://bugs.webkit.org/show_bug.cgi?id=101104

        Reviewed by Darin Adler.

        Try converting the CFString to an 8 bit string using CFStringGetBytes(...,
        kCFStringEncodingISOLatin1, ...) and return the 8 bit string if successful.
        If not proceed with 16 bit conversion.

        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):

2012-11-06  Oliver Hunt  <oliver@apple.com>

        Reduce direct m_symbolTable usage in CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=101391

        Reviewed by Sam Weinig.

        Simple refactoring.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::dumpStatistics):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isCaptured):

2012-11-06  Michael Saboff  <msaboff@apple.com>

        Lexer::scanRegExp, create 8 bit pattern and flag Identifiers from 16 bit source when possible
        https://bugs.webkit.org/show_bug.cgi?id=101013

        Reviewed by Darin Adler.

        Changed scanRegExp so that it will create 8 bit identifiers from 8 bit sources and from 16 bit sources
        whan all the characters are 8 bit.  Using two templated helpers, the "is all 8 bit" check is only performed
        on 16 bit sources.  The first helper is orCharacter() that will accumulate the or value of all characters
        only for 16 bit sources.  Replaced the helper Lexer::makeIdentifierSameType() with Lexer::makeRightSizedIdentifier().

        * parser/Lexer.cpp:
        (JSC::orCharacter<LChar>): Explicit template that serves as a placeholder.
        (JSC::orCharacter<UChar>): Explicit template that actually or accumulates characters.
        (JSC::Lexer::scanRegExp):
        * parser/Lexer.h:
        (Lexer):
        (JSC::Lexer::makeRightSizedIdentifier<LChar>): New template that always creates an 8 bit Identifier.
        (JSC::Lexer::makeRightSizedIdentifier<UChar>): New template that creates an 8 bit Identifier for 8 bit
        data in a 16 bit source.

2012-11-06  Filip Pizlo  <fpizlo@apple.com>

        Indentation of JSCell.h is wrong
        https://bugs.webkit.org/show_bug.cgi?id=101379

        Rubber stamped by Alexey Proskuryakov.

        Just removed four spaces on a bunch of lines.

        * runtime/JSCell.h:

2012-11-05  Filip Pizlo  <fpizlo@apple.com>

        Indentation of JSObject.h is wrong
        https://bugs.webkit.org/show_bug.cgi?id=101313

        Rubber stamped by Alexey Proskuryakov.

        Just unindented code, since namespace bodies shouldn't be indented.

        * runtime/JSObject.h:

2012-11-05  Filip Pizlo  <fpizlo@apple.com>

        Indentation of JSArray.h is wrong
        https://bugs.webkit.org/show_bug.cgi?id=101314

        Rubber stamped by Alexey Proskuryakov.

        Just removing the indentation inside the namespace body.

        * runtime/JSArray.h:

2012-11-05  Filip Pizlo  <fpizlo@apple.com>

        DFG should not fall down to patchable GetById just because a prototype had things added to it
        https://bugs.webkit.org/show_bug.cgi?id=101299

        Reviewed by Geoffrey Garen.

        This looks like a slight win on V8v7 and SunSpider.

        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-11-05  Filip Pizlo  <fpizlo@apple.com>

        Get rid of method_check
        https://bugs.webkit.org/show_bug.cgi?id=101147

        Reviewed by Geoffrey Garen.

        op_method_check no longer buys us anything, since get_by_id proto caching
        gives just as much profiling information and the DFG inlines monomorphic
        proto accesses anyway.
        
        This also has the potential for a speed-up since it makes parsing of
        profiling data easier. No longer do we have to deal with the confusion of
        the get_by_id portion of a method_check appearing monomorphic even though
        we're really dealing with a bimorphic access (method_check specializes for
        one case and get_by_id for another).

        This looks like a 1% speed-up on both SunSpider and V8v7.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::unlinkCalls):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getCallLinkInfo):
        (JSC::CodeBlock::callLinkInfo):
        (CodeBlock):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/MethodCallLinkInfo.cpp: Removed.
        * bytecode/MethodCallLinkInfo.h: Removed.
        * bytecode/MethodCallLinkStatus.cpp: Removed.
        * bytecode/MethodCallLinkStatus.h: Removed.
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallDotNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::PropertyStubCompilationInfo::copyToStubInfo):
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::PropertyStubCompilationInfo::slowCaseInfo):
        (PropertyStubCompilationInfo):
        (JSC):
        (JIT):
        * jit/JITPropertyAccess.cpp:
        (JSC):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::compileGetByIdSlowCase):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC):
        (JSC::JIT::compileGetByIdSlowCase):
        * jit/JITStubs.cpp:
        (JSC):
        * jit/JITStubs.h:
        * llint/LowLevelInterpreter.asm:

2012-11-05  Yuqiang Xian  <yuqiang.xian@intel.com>

        Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations
        https://bugs.webkit.org/show_bug.cgi?id=100321

        Reviewed by Filip Pizlo.

        We have refactored the MacroAssembler and JIT compilers to distinguish
        the pointer operations from the 64-bit integer operations (see bug #99154).
        Now we want to do the similar work for LLInt, and the goal is same as
        the one mentioned in 99154.

        This is the second part of the modification: in the low level interpreter,
        changing the operations on 64-bit integers to use the "<foo>q" instructions.
        This also removes some unused/meaningless "<foo>p" instructions.

        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/armv7.rb:
        * offlineasm/cloop.rb:
        * offlineasm/instructions.rb:
        * offlineasm/x86.rb:

2012-11-05  Filip Pizlo  <fpizlo@apple.com>

        Prototype chain caching should check that the path from the base object to the slot base involves prototype hops only
        https://bugs.webkit.org/show_bug.cgi?id=101276

        Reviewed by Gavin Barraclough.

        Changed normalizePrototypeChain() to report an invalid prototype chain if any object is a proxy.
        This catches cases where our prototype chain checks would have been insufficient to guard against
        newly introduced properties, despecialized properties, or deleted properties in the chain of
        objects involved in the access.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDProtoList):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::tryBuildPutByIdList):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::tryCachePutByID):
        (JSC::JITThunks::tryCacheGetByID):
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Operations.h:
        (JSC):
        (JSC::normalizePrototypeChain):

2012-11-05  Dima Gorbik  <dgorbik@apple.com>

        Back out controversial changes from Bug 98665.
        https://bugs.webkit.org/show_bug.cgi?id=101244

        Reviewed by David Kilzer.

        Backing out changes from Bug 98665 until further discussions take place on rules for including Platform.h in Assertions.h.

        * API/tests/minidom.c:
        * API/tests/testapi.c:

2012-11-04  Filip Pizlo  <fpizlo@apple.com>

        Reduce the verbosity of referring to QNaN in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=101174

        Reviewed by Geoffrey Garen.

        Introduces a #define QNaN in JSValue.h, and replaces all previous uses of
        std::numeric_limits<double>::quiet_NaN() with QNaN.

        * API/JSValueRef.cpp:
        (JSValueMakeNumber):
        (JSValueToNumber):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        * runtime/CachedTranscendentalFunction.h:
        (JSC::CachedTranscendentalFunction::initialize):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        * runtime/DateInstanceCache.h:
        (JSC::DateInstanceData::DateInstanceData):
        (JSC::DateInstanceCache::reset):
        * runtime/ExceptionHelpers.cpp:
        (JSC::InterruptedExecutionError::defaultValue):
        (JSC::TerminatedExecutionError::defaultValue):
        * runtime/JSCell.h:
        (JSC::JSValue::getPrimitiveNumber):
        * runtime/JSDateMath.cpp:
        (JSC::parseDateFromNullTerminatedCharacters):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::resetDateCache):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::parseInt):
        (JSC::jsStrDecimalLiteral):
        (JSC::toDouble):
        (JSC::jsToNumber):
        (JSC::parseFloat):
        * runtime/JSValue.cpp:
        (JSC::JSValue::toNumberSlowCase):
        * runtime/JSValue.h:
        (JSC):
        * runtime/JSValueInlineMethods.h:
        (JSC::jsNaN):
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncMax):
        (JSC::mathProtoFuncMin):

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

        Baseline JIT should use structure watchpoints whenever possible
        https://bugs.webkit.org/show_bug.cgi?id=101146

        Reviewed by Sam Weinig.

        No speed-up yet except on toy programs. I think that it will start to show
        speed-ups with https://bugs.webkit.org/show_bug.cgi?id=101147, which this is
        a step towards.

        * jit/JIT.h:
        (JIT):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        (JSC::JIT::addStructureTransitionCheck):
        (JSC):
        (JSC::JIT::testPrototype):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):

2012-11-04  Csaba Osztrogonác  <ossy@webkit.org>

        [Qt] udis86_itab.c is always regenerated
        https://bugs.webkit.org/show_bug.cgi?id=100756

        Reviewed by Simon Hausmann.

        * DerivedSources.pri: Generate sources to the generated directory.
        * disassembler/udis86/differences.txt:
        * disassembler/udis86/itab.py: Add --outputDir option.
        (UdItabGenerator.__init__):
        (genItabH):
        (genItabC):
        (main):

2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        LLInt 32-bit put_by_val ArrayStorage case should use the right register (t3, not t2) for the index in the publicLength updating path
        https://bugs.webkit.org/show_bug.cgi?id=101118

        Reviewed by Gavin Barraclough.

        * llint/LowLevelInterpreter32_64.asm:

2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        DFG::Node::converToStructureTransitionWatchpoint should take kindly to ArrayifyToStructure
        https://bugs.webkit.org/show_bug.cgi?id=101117

        Reviewed by Gavin Barraclough.

        We have logic to convert ArrayifyToStructure to StructureTransitionWatchpoint, which is awesome, except
        that previously convertToStructureTransitionWatchpoint was (a) asserting that it never saw an
        ArrayifyToStructure and (b) would incorrectly create a ForwardStructureTransitionWatchpoint if it did.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToStructureTransitionWatchpoint):

2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        DFG::SpeculativeJIT::typedArrayDescriptor should use the Float64Array descriptor for Float64Arrays
        https://bugs.webkit.org/show_bug.cgi?id=101114

        Reviewed by Gavin Barraclough.

        As in https://bugs.webkit.org/show_bug.cgi?id=101112, this was only wrong when Float64Array descriptors
        hadn't been initialized yet. That happens rarely, but when it does happen, we would crash.
        
        This would also become much more wrong if we ever put type size info (num bytes, etc) in the descriptor
        and used that directly. So it's good to fix it.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::typedArrayDescriptor):

2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        JIT::privateCompileGetByVal should use the uint8ClampedArrayDescriptor for compiling accesses to Uint8ClampedArrays
        https://bugs.webkit.org/show_bug.cgi?id=101112

        Reviewed by Gavin Barraclough.

        The only reason why the code was wrong to use uint8ArrayDescriptor instead is that if we're just using
        Uint8ClampedArrays then the descriptor for Uint8Array may not have been initialized.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):

2012-11-02  Mark Hahnenberg  <mhahnenberg@apple.com>

        MarkedBlocks should use something other than the mark bits to indicate liveness for newly allocated objects
        https://bugs.webkit.org/show_bug.cgi?id=100877

        Reviewed by Filip Pizlo.

        Currently when we canonicalize cell liveness data in MarkedBlocks, we set the mark bit for every cell in the 
        block except for those in the free list. This allows us to consider objects that were allocated since the 
        previous collection to be considered live until they have a chance to be properly marked by the collector.

        If we want to use the mark bits to signify other types of information, e.g. using sticky mark bits for generational 
        collection, we will have to keep track of newly allocated objects in a different fashion when we canonicalize cell liveness.

        One method would be to allocate a separate set of bits while canonicalizing liveness data. These bits would 
        track the newly allocated objects in the block separately from those objects who had already been marked. We would 
        then check these bits, along with the mark bits, when determining liveness. 

        * heap/Heap.h:
        (Heap):
        (JSC::Heap::isLive): We now check for the presence of the newlyAllocated Bitmap.
        (JSC):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::specializedSweep): We clear the newlyAllocated Bitmap if we're creating a free list. This 
        will happen if we canonicalize liveness data for some other reason than collection (e.g. forEachCell) and 
        then start allocating again.
        (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor): 
        (SetNewlyAllocatedFunctor):
        (JSC::SetNewlyAllocatedFunctor::operator()): We set the newlyAllocated bits for all the objects 
        that aren't already marked. We undo the bits for the objects in the free list later in canonicalizeCellLivenessData.
        (JSC::MarkedBlock::canonicalizeCellLivenessData): We should never have a FreeListed block with a newlyAllocated Bitmap.
        We allocate the new Bitmap, set the bits for all the objects that aren't already marked, and then unset all of the 
        bits for the items currently in the FreeList.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::clearMarks): We clear the newlyAllocated bitmap if it exists because at this point we don't need it
        any more.
        (JSC::MarkedBlock::isEmpty): If we have some objects that are newlyAllocated, we are not empty.
        (JSC::MarkedBlock::isNewlyAllocated): 
        (JSC):
        (JSC::MarkedBlock::setNewlyAllocated):
        (JSC::MarkedBlock::clearNewlyAllocated):
        (JSC::MarkedBlock::isLive): We now check the newlyAllocated Bitmap, if it exists, when determining liveness of a cell in 
        a block that is Marked.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit): We need to make sure we don't finalize objects that are in the newlyAllocated Bitmap.
        (JSC::WeakBlock::reap): Ditto.

2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        JIT::privateCompileGetByVal should use MacroAssemblerCodePtr::createFromExecutableAddress like JIT::privateCompilePutByVal
        https://bugs.webkit.org/show_bug.cgi?id=101109

        Reviewed by Gavin Barraclough.

        This fixes crashes on ARMv7 resulting from the return address already being tagged with the THUMB2 bit.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):

2012-11-02  Simon Fraser  <simon.fraser@apple.com>

        Enable SUBPIXEL_LAYOUT on Mac
        https://bugs.webkit.org/show_bug.cgi?id=101076

        Reviewed by Dave Hyatt.

        Define ENABLE_SUBPIXEL_LAYOUT and include it in FEATURE_DEFINES.

        * Configurations/FeatureDefines.xcconfig:

2012-11-02  Michael Saboff  <msaboff@apple.com>

        RegExp.prototype.toString Should Produce an 8 bit JSString if possible.
        https://bugs.webkit.org/show_bug.cgi?id=101003

        Reviewed by Geoffrey Garen.

        Took the logic of regExpObjectSource() and created two templated helpers that uses the
        source character type when appending to the StringBuilder.

        * runtime/RegExpObject.cpp:
        (JSC::appendLineTerminatorEscape): Checks line terminate type to come up with escaped version.
        (JSC::regExpObjectSourceInternal): Templated version of original.
        (JSC::regExpObjectSource): Wrapper function.

2012-11-02  Adam Barth  <abarth@webkit.org>

        ENABLE(UNDO_MANAGER) is disabled everywhere and is not under active development
        https://bugs.webkit.org/show_bug.cgi?id=100711

        Reviewed by Eric Seidel.

        * Configurations/FeatureDefines.xcconfig:

2012-11-02  Simon Hausmann  <simon.hausmann@digia.com>

        [Qt] Fix build on Windows when Qt is configured with -release
        https://bugs.webkit.org/show_bug.cgi?id=101041

        Reviewed by Jocelyn Turcotte.

        When Qt is configured with -debug or -release, the release/debug build of for example
        QtCore is not available by default. For LLIntExtractor we always need to build debug
        _and_ release versions, but we do not actually need any Qt libraries nor qtmain(d).lib.
        Therefore we can disable all these features but need to keep $$QT.core.includes in the
        INCLUDEPATH for some defines from qglobal.h.

        * LLIntOffsetsExtractor.pro:

2012-11-01  Mark Lam  <mark.lam@apple.com>

        A llint workaround for a toolchain issue.
        https://bugs.webkit.org/show_bug.cgi?id=101012.

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter.asm:
          - use a local label to workaround the toolchain issue with undeclared
            global labels.

2012-11-01  Oliver Hunt  <oliver@apple.com>

        Remove GlobalObject constant register that is typically unused
        https://bugs.webkit.org/show_bug.cgi?id=101005

        Reviewed by Geoffrey Garen.

        The GlobalObject constant register is frequently allocated even when it
        is not used, it is also getting in the way of some other optimisations.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseResolveOperations):

2012-10-31  Filip Pizlo  <fpizlo@apple.com>

        DFG optimized string access code should be enabled
        https://bugs.webkit.org/show_bug.cgi?id=100825

        Reviewed by Oliver Hunt.

        - Removes prediction checks from the parser.
        
        - Fixes the handling of array mode refinement for strings. I.e. we don't do
          any refinement - we already know it's going to be a string. We could
          revisit this in the future, but for now the DFG lacks the ability to
          handle any array modes other than Array::String for string intrinsics, so
          this is as good as it gets.
        
        - Removes uses of isBlahSpeculation for checking if a mode is already
          checked. isBlahSpeculation implicitly checks if the SpeculatedType is not
          BOTTOM ("empty"), which breaks for checking if a mode is already checked
          since a mode may already be "checked" in the sense that we've proven that
          the code is unreachable.
        
        ~1% speed-up on V8v7, mostly from a speed-up on crypto, which uses string
        intrinsics in one of the hot functions.

        * bytecode/SpeculatedType.h:
        (JSC::speculationChecked):
        (JSC):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::alreadyChecked):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):

2012-10-31  Filip Pizlo  <fpizlo@apple.com>

        Sparse array size threshold should be increased to 100000
        https://bugs.webkit.org/show_bug.cgi?id=100827

        Reviewed by Oliver Hunt.

        This enables the use of contiguous arrays in programs that previously
        couldn't use them. And I so far can't see any examples of this being
        a downside. To the extent that there is a downside, it ought to be
        addressed by GC: https://bugs.webkit.org/show_bug.cgi?id=100828

        * runtime/ArrayConventions.h:
        (JSC):

2012-10-31  Mark Lam  <mark.lam@apple.com>

        C++ llint 64-bit backend needs to zero extend results of int32 operations.
        https://bugs.webkit.org/show_bug.cgi?id=100899.

        Reviewed by Filip Pizlo.

        llint asm instructions ending in "i" for a 64-bit machine expects the
        high 32-bit of registers to be zero'ed out when a 32-bit instruction
        writes into a register. Fixed the C++ llint to honor this.

        Fixed the index register used in BaseIndex addressing to be of size
        intptr_t as expected.

        Updated CLoopRegister to handle different endiannesss configurations.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoopRegister::clearHighWord):
          - new method to clear the high 32-bit of a 64-bit register.
            It's a no-op for the 32-bit build. 
        (CLoopRegister):
          - CLoopRegister now takes care of packing and byte endianness order.
        (JSC::CLoop::execute): - Added an assert.
        * offlineasm/cloop.rb:
          - Add calls to clearHighWord() wherever needed.

2012-10-31  Mark Lam  <mark.lam@apple.com>

        A JSC printf (support for %J+s and %b).
        https://bugs.webkit.org/show_bug.cgi?id=100566.

        Reviewed by Michael Saboff.

        Added VMInspector::printf(), fprintf(), sprintf(), and snprintf().
        - %b prints ints as boolean TRUE (non-zero) or FALSE (zero).
        - %Js prints a WTF::String* like a %s prints a char*.
          Also works for 16bit WTF::Strings (prints wchar_t* using %S).
        - '+' is a modifier meaning 'use verbose mode', and %J+s is an example
          of its use.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/VMInspector.cpp:
        (FormatPrinter):
        (JSC::FormatPrinter::~FormatPrinter):
        (JSC::FormatPrinter::print):
        (JSC::FormatPrinter::printArg):
        (JSC::FormatPrinter::printWTFString):
        (JSC::FileFormatPrinter::FileFormatPrinter):
        (JSC::FileFormatPrinter::printArg):
        (JSC::StringFormatPrinter::StringFormatPrinter):
        (JSC::StringFormatPrinter::printArg):
        (JSC::StringNFormatPrinter::StringNFormatPrinter):
        (JSC::StringNFormatPrinter::printArg):
        (JSC::VMInspector::fprintf):
        (JSC::VMInspector::printf):
        (JSC::VMInspector::sprintf):
        (JSC::VMInspector::snprintf):
        * interpreter/VMInspector.h:
        (VMInspector):

2012-10-31  Mark Lam  <mark.lam@apple.com>

        64-bit llint PC offset can be negative: using an unsigned shift is a bug.
        https://bugs.webkit.org/show_bug.cgi?id=100896.

        Reviewed by Filip Pizlo.

        Fixed the PC offset divisions in the 64-bit llint asm to use rshift instead of urshift.

        * llint/LowLevelInterpreter64.asm:

2012-10-30  Yuqiang Xian  <yuqiang.xian@intel.com>

        glsl-function-atan.html WebGL conformance test fails after https://bugs.webkit.org/show_bug.cgi?id=99154
        https://bugs.webkit.org/show_bug.cgi?id=100789

        Reviewed by Filip Pizlo.

        We accidently missed a bitwise double to int64 conversion.

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

2012-10-30  Joseph Pecoraro  <pecoraro@apple.com>

        [Mac] Sync up FeatureDefine Configuration Files
        https://bugs.webkit.org/show_bug.cgi?id=100171

        Reviewed by David Kilzer.

        Follow up to better coordinate with iOS feature defines. Make:

          - ENABLE_FILTERS always on
          - ENABLE_INPUT_* iphonesimulator values point to the iphoneos values

        * Configurations/FeatureDefines.xcconfig:

2012-10-30  Joseph Pecoraro  <pecoraro@apple.com>

        [Mac] Sync up FeatureDefine Configuration Files
        https://bugs.webkit.org/show_bug.cgi?id=100171

        Reviewed by David Kilzer.

        Ensure an identical FeatureDefine files across all projects. Changes:

          - ENABLE_CSS_BOX_DECORATION_BREAK should be in all
          - ENABLE_PDFKIT_PLUGIN should be in all
          - ENABLE_RESOLUTION_MEDIA_QUERY should be in all
          - ENABLE_ENCRYPTED_MEDIA should be in all
          - ENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING with corrected value
          - Some alphabetical ordering cleanup

        * Configurations/FeatureDefines.xcconfig:

2012-10-30  Mark Hahnenberg  <mhahnenberg@apple.com>

        Arrays can change IndexingType in the middle of sorting
        https://bugs.webkit.org/show_bug.cgi?id=100773

        Reviewed by Filip Pizlo.

        Instead of giving up, we just fetch the appropriate vector based on the current 
        IndexingType of the array.

        * runtime/JSArray.cpp:
        (JSC::JSArray::sortVector):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::currentIndexingData):
        (JSC::JSObject::currentRelevantLength):

2012-10-29  Anders Carlsson  <andersca@apple.com>

        Build WebKit as C++11 on Mac
        https://bugs.webkit.org/show_bug.cgi?id=100720

        Reviewed by Daniel Bates.

        * Configurations/Base.xcconfig:
        Add CLANG_CXX_LANGUAGE_STANDARD=gnu++0x.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::pushFinallyContext):
        (JSC::BytecodeGenerator::beginSwitch):
        * llint/LLIntOffsetsExtractor.cpp:
        * runtime/Identifier.cpp:
        (JSC::Identifier::add8):
        * runtime/Identifier.h:
        (JSC::Identifier::add):
        * runtime/JSONObject.cpp:
        (JSC::appendStringToStringBuilder):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingStringSearch):
        Add static_casts to prevent implicit type conversions in non-constant initializer lists.

2012-10-28  Mark Rowe  <mrowe@apple.com>

        Simplify Xcode configuration settings that used to vary between OS versions.

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:

2012-10-28  Mark Rowe  <mrowe@apple.com>

        Remove references to unsupported OS and Xcode versions.

        Reviewed by Anders Carlsson.

        * Configurations/Base.xcconfig:
        * Configurations/CompilerVersion.xcconfig: Removed.
        * Configurations/DebugRelease.xcconfig:
        * Configurations/Version.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2012-10-29  Michael Saboff  <msaboff@apple.com>

        Non-special escape character sequences cause JSC::Lexer::parseString to create 16 bit strings
        https://bugs.webkit.org/show_bug.cgi?id=100576

        Reviewed by Darin Adler.

        Changed singleEscape() processing to be based on a lookup of a static table.  The table
        covers ASCII characters SPACE through DEL.  If a character can be a single character escape,
        then the table provides the non-zero result of that escape.  Updated the result of
        singleEscape to be an LChar to make the table as small as possible.
        Added a new test fast/js/normal-character-escapes-in-string-literals.html to validated
        the behavior.

        * parser/Lexer.cpp:
        (JSC::singleEscape):
        (JSC::Lexer::parseString):
        (JSC::Lexer::parseStringSlowCase):

2012-10-29  Enrica Casucci  <enrica@apple.com>

        Add ENABLE_USERSELECT_ALL feature flag.
        https://bugs.webkit.org/show_bug.cgi?id=100559

        Reviewed by Eric Seidel.

        * Configurations/FeatureDefines.xcconfig:

2012-10-28  Filip Pizlo  <fpizlo@apple.com>

        DFG should be able to emit effectful structure checks
        https://bugs.webkit.org/show_bug.cgi?id=99260

        Reviewed by Oliver Hunt.

        This change allows us to find out if an array access that has gone polymorphic
        is operating over known structures - i.e. the primordial array structures of the
        global object that the code block containing the array access belongs to. We
        term this state "OriginalArray" for short. The fact that the access has gone
        polymorphic means that the array profile will not be able to report the set of
        structures it had seen - but if it can tell us that all of the structures were
        primordial then it just so happens that we can deduce what the structure set
        would have been by just querying the code block's global object. This allows us
        to emit an ArrayifyToStructure instead of an Arrayify if we find that we need to
        do conversions. The fast path of an ArrayifyToStructure is exactly like the fast
        path of a CheckStructure and is mostly subject to the same optimizations. It
        also burns one fewer registers.
        
        Essentially the notion of OriginalArray is a super cheap way of getting the
        array profile to tell us a structure set instead of a singleton structure.
        Currently, the array profile can only tell us the structure seen at an array
        access if there was exactly one structure. If there were multiple structures, it
        won't tell us anything other than the array modes and other auxiliary profiling
        data (whether there were stores to holes, for example). With OriginalArray, we
        cheaply get a structure set if all of the structures were primordial for the
        code block's global object, since in that case the array mode set (ArrayModes)
        can directly tell us the structure set. In the future, we might consider adding
        complete structure sets to the array profiles, but I suspect that we would hit
        diminishing returns if we did so - it would only help if we have array accesses
        that are both polymorphic and are cross-global-object accesses (rare) or if the
        arrays had named properties or other structure transitions that are unrelated to
        indexing type (also rare).
        
        This also does away with Arrayify (and the new ArrayifyToStructure) returning
        the butterfly pointer. This turns out to be faster and easier to CSE.
        
        And, this also changes constant folding to be able to eliminate CheckStructure,
        ForwardCheckStructure, and ArrayifyToStructure in addition to being able to
        transform them into structure transition watchpoints. This is great for
        ArrayifyToStructure because then CSE and CFA know that there is no side effect.
        Converting CheckStructure and ForwardCheckStructure to also behave this way is
        just a matter of elegance.
        
        This has no performance impact right now. It's intended to alleviate some of the
        regressions seen in the early implementation of
        https://bugs.webkit.org/show_bug.cgi?id=98606.

        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::ArrayProfile::ArrayProfile):
        (ArrayProfile):
        (JSC::ArrayProfile::usesOriginalArrayStructures):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayClassToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::withProfile):
        (JSC::DFG::ArrayMode::isJSArray):
        (ArrayMode):
        (JSC::DFG::ArrayMode::isJSArrayWithOriginalStructure):
        (JSC::DFG::ArrayMode::supportsLength):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShape):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::checkStructureElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::checkArrayElimination):
        (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasStructure):
        (JSC::DFG::Node::hasArrayMode):
        (JSC::DFG::Node::arrayMode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):

2012-10-28  Filip Pizlo  <fpizlo@apple.com>

        There should not be blind spots in array length array profiling
        https://bugs.webkit.org/show_bug.cgi?id=100620

        Reviewed by Oliver Hunt.

        I don't think this has any performance impact. But it's good to not have random
        programs occasionally emit a GetById for array length accesses.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::privateCompilePatchGetArrayLength):

2012-10-28  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, make always-true enum-to-int comparisons use casts.

        * dfg/DFGFPRInfo.h:
        (JSC::DFG::FPRInfo::debugName):
        * dfg/DFGGPRInfo.h:
        (JSC::DFG::JSValueSource::tagGPR):
        (JSC::DFG::GPRInfo::toIndex):
        (JSC::DFG::GPRInfo::debugName):
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::TypeInfo):

2012-10-27  Filip Pizlo  <fpizlo@apple.com>

        OSR exit compilation should defend against argument recoveries from code blocks that are no longer on the inline stack
        https://bugs.webkit.org/show_bug.cgi?id=100601

        Reviewed by Oliver Hunt.

        This happened to me while I was fixing bugs for https://bugs.webkit.org/show_bug.cgi?id=100599.
        I'm not sure how to reproduce this.

        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::baselineCodeBlockFor):
        (AssemblyHelpers):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):

2012-10-27  Filip Pizlo  <fpizlo@apple.com>

        DFG::Array::Mode needs to be cleaned up
        https://bugs.webkit.org/show_bug.cgi?id=100599

        Reviewed by Oliver Hunt.

        Turn the previous massive Array::Mode enum into a class that contains four
        fields, the type, whether it's a JSArray, the level of speculation, and the
        kind of conversion to perform.
        
        No performance or behavioral change.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayTypeToString):
        (JSC::DFG::arrayClassToString):
        (DFG):
        (JSC::DFG::arraySpeculationToString):
        (JSC::DFG::arrayConversionToString):
        (JSC::DFG::ArrayMode::toString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (ArrayMode):
        (JSC::DFG::ArrayMode::ArrayMode):
        (JSC::DFG::ArrayMode::type):
        (JSC::DFG::ArrayMode::arrayClass):
        (JSC::DFG::ArrayMode::speculation):
        (JSC::DFG::ArrayMode::conversion):
        (JSC::DFG::ArrayMode::asWord):
        (JSC::DFG::ArrayMode::fromWord):
        (JSC::DFG::ArrayMode::withSpeculation):
        (JSC::DFG::ArrayMode::usesButterfly):
        (JSC::DFG::ArrayMode::isJSArray):
        (JSC::DFG::ArrayMode::isInBounds):
        (JSC::DFG::ArrayMode::mayStoreToHole):
        (JSC::DFG::ArrayMode::isOutOfBounds):
        (JSC::DFG::ArrayMode::isSlowPut):
        (JSC::DFG::ArrayMode::canCSEStorage):
        (JSC::DFG::ArrayMode::lengthNeedsStorage):
        (JSC::DFG::ArrayMode::modeForPut):
        (JSC::DFG::ArrayMode::isSpecific):
        (JSC::DFG::ArrayMode::supportsLength):
        (JSC::DFG::ArrayMode::benefitsFromStructureCheck):
        (JSC::DFG::ArrayMode::doesConversion):
        (JSC::DFG::ArrayMode::arrayModesThatPassFiltering):
        (JSC::DFG::ArrayMode::operator==):
        (JSC::DFG::ArrayMode::operator!=):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShape):
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::lengthNeedsStorage):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getArrayLengthElimination):
        (JSC::DFG::CSEPhase::checkArrayElimination):
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arrayMode):
        (JSC::DFG::Node::setArrayMode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::typedArrayDescriptor):
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-27  Dan Bernstein  <mitz@apple.com>

        REAL_PLATFORM_NAME build setting is no longer needed
        https://bugs.webkit.org/show_bug.cgi?id=100587

        Reviewed by Mark Rowe.

        Removed the definition of REAL_PLATFORM_NAME and replaced references to it with references
        to PLATFORM_NAME.

        * Configurations/Base.xcconfig:
        * Configurations/CompilerVersion.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/JSC.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:
        * Configurations/ToolExecutable.xcconfig:

2012-10-25  Filip Pizlo  <fpizlo@apple.com>

        Forward OSR calculation is wrong in the presence of multiple SetLocals, or a mix of SetLocals and Phantoms
        https://bugs.webkit.org/show_bug.cgi?id=100461

        Reviewed by Oliver Hunt and Gavin Barraclough.

        This does a couple of things. First, it removes the part of the change in r131822 that made the forward
        OSR exit calculator capable of handling multiple SetLocals. That change was wrong, because it would
        blindly assume that all SetLocals had the same ValueRecovery, and would ignore the possibility that if
        there is no value recovery then a ForwardCheckStructure on the first SetLocal would not know how to
        recover the state associated with the second SetLocal. Then, it introduces the invariant that any bytecode
        op that decomposes into multiple SetLocals must first emit dead SetLocals as hints and then emit a second
        set of SetLocals to actually do the setting of the locals. This means that if a ForwardCheckStructure (or
        any other hoisted forward speculation) is inserted, it will always be inserted on the second set of
        SetLocals (since hoisting only touches the live ones), at which point OSR will already know about the
        mov hints implied by the first set of (dead) SetLocals. This gives us the behavior we wanted, namely, that
        a ForwardCheckStructure applied to a variant set by a resolve_with_base-like operation can correctly do a
        forward exit while also ensuring that prior to exiting we set the appropriate locals.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):

2012-10-26  Simon Hausmann  <simon.hausmann@digia.com>

        [Qt] Fix the LLInt build on Windows
        https://bugs.webkit.org/show_bug.cgi?id=97648

        Reviewed by Tor Arne Vestbø.

        The main change for the port on Windows is changing the way offsets are extracted
        and the LLIntAssembly.h is generated to accomodate release and debug configurations.

        Firstly the LLIntOffsetsExtractor binary is now built as-is (no DESTDIR set) and
        placed into debug\LLIntOffsetsExtractor.exe and release\LLIntOffsetsExtractor.exe
        on Windows debug_and_release builds. On other patforms it remainds in the regular
        out directory.

        Secondly the LLIntAssembly.h files must be different for different build types,
        so the LLIntAssembly.h generator in DerivedSources.pri operates no on the extractor
        binary files as input. Using a simple exists() check we verify the presence of either
        a regular, a debug\LLIntOffsetsExtractor and a release\LLIntOffsetsExtractor binary
        and process all of them. The resulting assembly files consequently end up in
        generated\debug\LLIntAssembly.h and generated\release\LLIntAssembly.h.

        In Target.pri we have to also make sure that those directories are in the include
        path according to the release or debug configuration.

        Lastly a small tweak - swapping WTF.pri and JSC.pri inclusions - in the
        LLIntOffsetsExtractor build was needed to make sure that we include
        JavaScriptCore/config.h instead of WTF/config.h, required to fix the
        build issues originally pasted in bug #97648.

        * DerivedSources.pri:
        * JavaScriptCore.pro:
        * LLIntOffsetsExtractor.pro:
        * Target.pri:

2012-10-26  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        [Qt] Enable JSC's disassembler on x86, x86_64 Linux
        https://bugs.webkit.org/show_bug.cgi?id=100386

        Reviewed by Simon Hausmann.

        It works fine on Linux x86, x86_64 just needs to be enabled in the
        QtWebKit build system.

        * DerivedSources.pri:
        * JavaScriptCore.pri:
        * Target.pri:

2012-10-26  Thiago Marcos P. Santos  <thiago.santos@intel.com>

        Add feature flags for CSS Device Adaptation
        https://bugs.webkit.org/show_bug.cgi?id=95960

        Reviewed by Kenneth Rohde Christiansen.

        * Configurations/FeatureDefines.xcconfig:

2012-10-26  Simon Hausmann  <simon.hausmann@digia.com>

        [WIN] Make LLInt offsets extractor work on Windows
        https://bugs.webkit.org/show_bug.cgi?id=100369

        Reviewed by Kenneth Rohde Christiansen.

        Open the input file explicitly in binary mode to prevent ruby/Windows from thinking that
        it's a text mode file that needs even new line conversions. The binary mode parameter is
        ignored on other platforms.

        * offlineasm/offsets.rb:

2012-10-25  Michael Saboff  <msaboff@apple.com>

        SymbolTableIndexHashTraits::needsDestruction should be set to true
        https://bugs.webkit.org/show_bug.cgi?id=100437

        Reviewed by Mark Hahnenberg.

        For correctness, set SymbolTableIndexHashTraits::needsDestruction to true since SymbolTableEntry's do
        need to have their destructor called due to the possibility of rare data.

        * runtime/SymbolTable.h:
        (SymbolTableIndexHashTraits):

2012-10-25  Filip Pizlo  <fpizlo@apple.com>

        DFG Arrayify elimination should replace it with GetButterfly rather than Phantom
        https://bugs.webkit.org/show_bug.cgi?id=100441

        Reviewed by Oliver Hunt and Gavin Barraclough.

        Made array profiler's to-string helper behave correctly.
        
        Made Arrayify elimination do the right thing (convert to GetButterfly).
        
        Made CFA's interference analysis track clobbered array modes correctly, mostly by
        simplifying the machinery.

        * bytecode/ArrayProfile.cpp:
        (JSC::arrayModesToString):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::clobberArrayModes):
        (AbstractValue):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):

2012-10-25  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r131793-r131826): Crash going to wikifonia.org
        https://bugs.webkit.org/show_bug.cgi?id=100281

        Reviewed by Oliver Hunt.

        Restore something that got lost in the resolve refactoring: the ability to give up on life if
        we see a resolve of 'arguments'.

        * runtime/JSScope.cpp:
        (JSC::JSScope::resolveContainingScopeInternal):

2012-10-25  Dominik Röttsches  <dominik.rottsches@intel.com>

        Conditionalize XHR timeout support
        https://bugs.webkit.org/show_bug.cgi?id=100356

        Reviewed by Adam Barth.

        Adding XHR_TIMEOUT feature to conditionalize this on ports without network backend support.

        * Configurations/FeatureDefines.xcconfig:

2012-10-25  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r131836): failures in list styles tests on EFL, GTK
        https://bugs.webkit.org/show_bug.cgi?id=99824

        Reviewed by Oliver Hunt.

        Saved start of string since it is modified by call convertUTF8ToUTF16().

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString):

2012-10-24  Filip Pizlo  <fpizlo@apple.com>

        DFG NewArrayBuffer node should keep its data in a structure on the side to free up one of the opInfos
        https://bugs.webkit.org/show_bug.cgi?id=100328

        Reviewed by Oliver Hunt.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGNode.h:
        (NewArrayBufferData):
        (DFG):
        (JSC::DFG::Node::newArrayBufferData):
        (Node):
        (JSC::DFG::Node::startConstant):
        (JSC::DFG::Node::numConstants):

2012-10-25  Mark Lam  <mark.lam@apple.com>

        Update the C++ llint to work with the latest op_resolve... changes.
        https://bugs.webkit.org/show_bug.cgi?id=100345.

        Reviewed by Oliver Hunt.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        - emit opcode name as label when not using COMPUTED_GOTOs. The new op_resolve
          opcodes have jumps to these labels.
        - declare all opcode labels as UNUSED_LABEL()s to keep the compiler happy
          for opcodes that are not referenced by anyone.
        * offlineasm/asm.rb:
        - strip llint_ prefix from opcode names used as labels.

2012-10-24  Yuqiang Xian  <yuqiang.xian@intel.com>

        Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations
        https://bugs.webkit.org/show_bug.cgi?id=100321

        Reviewed by Filip Pizlo.

        We have refactored the MacroAssembler and JIT compilers to distinguish
        the pointer operations from the 64-bit integer operations (see bug #99154).
        Now we want to do the similar work for LLInt, and the goal is same as
        the one mentioned in 99154.

        This is the first part of the modification: in the offline assembler,
        adding the support of the "<foo>q" instructions which will be used for
        64-bit integer operations.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * offlineasm/cloop.rb:
        * offlineasm/instructions.rb:
        * offlineasm/x86.rb:

2012-10-24  Filip Pizlo  <fpizlo@apple.com>

        DFG compileBlahBlahByVal methods for Contiguous and ArrayStorage have only one caller and should be removed
        https://bugs.webkit.org/show_bug.cgi?id=100311

        Reviewed by Mark Hahnenberg.

        Just trying to simplify things before I make them more complicated again.

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

2012-10-23  Andreas Kling  <kling@webkit.org>

        CodeBlock: Give m_putToBaseOperations an inline capacity.
        <http://webkit.org/b/100190>
        <rdar://problem/12562466>

        Reviewed by Oliver Hunt.

        Since the CodeBlock constructor always inserts a single PutToBaseOperation, but there's no
        guarantee that more will follow, give the m_putToBaseOperations vector an inline capacity of 1.
        There are 4009 of these Vectors on Membuster3, and only 126 of them have more than a single entry.

        This change yields a 1.90MB reduction in memory usage.

        * bytecode/CodeBlock.h:
        (CodeBlock):

2012-10-23  Christophe Dumez  <christophe.dumez@intel.com>

        Regression(r132143): Assertion hit in JSC::Interpreter::StackPolicy::StackPolicy(JSC::Interpreter&, const WTF::StackBounds&)
        https://bugs.webkit.org/show_bug.cgi?id=100109

        Reviewed by Oliver Hunt.

        Fix possible integer overflow in StackPolicy constructor by
        using size_t type instead of int for stack sizes. The value
        returned by StackBounds::size() is of type size_t but was
        assigned to an int, which may overflow.

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

2012-10-23  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing header file.

2012-10-23  Mark Lam  <mark.lam@apple.com>

        Make topCallFrame reliable.
        https://bugs.webkit.org/show_bug.cgi?id=98928.

        Reviewed by Geoffrey Garen.

        - VM entry points and the GC now uses topCallFrame.
        - The callerFrame value in CallFrames are now always the previous
          frame on the stack, except for the first frame which has a
          callerFrame of 0 (not counting the HostCallFrameFlag).
          Hence, we can now traverse every frame on the stack all the way
          back to the first frame.
        - GlobalExec's will no longer be used as the callerFrame values in
          call frames.
        - Added fences and traps for debugging the JSStack in debug builds.

        * bytecode/SamplingTool.h:
        (SamplingTool):
        (JSC::SamplingTool::CallRecord::CallRecord):
        * dfg/DFGOperations.cpp:
        - Fixed 2 DFG helper functions to flush topCallFrame as expected.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::prepareForExternalCall):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrameNoFlags):
        (ExecState):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::getArgumentUnsafe):
        * interpreter/CallFrameClosure.h:
        (CallFrameClosure):
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::eval):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::endRepeatCall):
        * interpreter/Interpreter.h:
        (JSC):
        (Interpreter):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::gatherConservativeRoots):
        (JSC::JSStack::disableErrorStackReserve):
        * interpreter/JSStack.h:
        (JSC):
        (JSStack):
        (JSC::JSStack::installFence):
        (JSC::JSStack::validateFence):
        (JSC::JSStack::installTrapsAfterFrame):
        * interpreter/JSStackInlines.h: Added.
        (JSC):
        (JSC::JSStack::getTopOfFrame):
        (JSC::JSStack::getTopOfStack):
        (JSC::JSStack::getStartOfFrame):
        (JSC::JSStack::pushFrame):
        (JSC::JSStack::popFrame):
        (JSC::JSStack::generateFenceValue):
        (JSC::JSStack::installFence):
        (JSC::JSStack::validateFence):
        (JSC::JSStack::installTrapsAfterFrame):
        * jit/JITStubs.cpp:
        (JSC::jitCompileFor):
        (JSC::lazyLinkFor):
        - Set frame->codeBlock to 0 for both the above because they are called
          with partially intitialized frames (cb uninitialized), but may
          trigger a GC.
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):

2012-10-22  Filip Pizlo  <fpizlo@apple.com>

        DFG::Array::Undecided should be called DFG::Array::SelectUsingPredictions
        https://bugs.webkit.org/show_bug.cgi?id=100052

        Reviewed by Oliver Hunt.

        No functional change, just renaming. It's a clearer name that more accurately
        reflects the meaning, and it eliminates the namespace confusion that will happen
        with the Undecided indexing type in https://bugs.webkit.org/show_bug.cgi?id=98606

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::refineArrayMode):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::modeIsSpecific):
        (JSC::DFG::modeSupportsLength):
        (JSC::DFG::benefitsFromStructureCheck):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-22  Mark Lam  <mark.lam@apple.com>

        Change stack recursion checks to be based on stack availability.
        https://bugs.webkit.org/show_bug.cgi?id=99872.

        Reviewed by Filip Pizlo and Geoffrey Garen.

        - Remove m_reentryDepth, ThreadStackType which are now obsolete.
        - Replaced the reentryDepth checks with a StackBounds check.
        - Added the Interpreter::StackPolicy class to compute a reasonable
          stack capacity requirement given the native stack that the
          interpreter is executing on at that time.
        - Reserved an amount of JSStack space for the use of error handling
          and enable its use (using Interpreter::ErrorHandlingMode) when
          we're about to throw or report an exception.
        - Interpreter::StackPolicy also allows more native stack space
          to be used when in ErrorHandlingMode. This is needed in the case
          of native stack overflows.
        - Fixed the parser so that it throws a StackOverflowError instead of
          a SyntaxError when it encounters a stack overflow.

        * API/JSContextRef.cpp:
        (JSContextGroupCreate):
        (JSGlobalContextCreateInGroup):
        * JavaScriptCore.order:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::ErrorHandlingMode::ErrorHandlingMode):
        (JSC):
        (JSC::Interpreter::ErrorHandlingMode::~ErrorHandlingMode):
        (JSC::Interpreter::StackPolicy::StackPolicy):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/Interpreter.h:
        (JSC):
        (Interpreter):
        (ErrorHandlingMode):
        (StackPolicy):
        (JSC::Interpreter::StackPolicy::requiredCapacity):
        * interpreter/JSStack.cpp:
        (JSC):
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::enableErrorStackReserve):
        (JSC::JSStack::disableErrorStackReserve):
        * interpreter/JSStack.h:
        (JSStack):
        (JSC::JSStack::reservationEnd):
        (JSC):
        * jsc.cpp:
        (jscmain):
        * parser/Parser.cpp:
        (JSC::::Parser):
        * parser/Parser.h:
        (Parser):
        (JSC::::parse):
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwStackOverflowError):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::createContextGroup):
        (JSC::JSGlobalData::create):
        (JSC::JSGlobalData::createLeaked):
        (JSC::JSGlobalData::sharedInstance):
        * runtime/JSGlobalData.h:
        (JSC):
        (JSGlobalData):
        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        * testRegExp.cpp:
        (realMain):

2012-10-20  Martin Robinson  <mrobinson@igalia.com>

        Fix 'make dist' for the GTK+ port

        * GNUmakefile.list.am: Add missing files to the source list.

2012-10-21  Raphael Kubo da Costa  <raphael.kubo.da.costa@intel.com>

        [CMake][JSC] Depend on risc.rb to decide when to run the LLInt scripts.
        https://bugs.webkit.org/show_bug.cgi?id=99917

        Reviewed by Geoffrey Garen.

        Depend on the newly-added risc.rb to make sure we always run the
        LLInt scripts when one of them changes.

        * CMakeLists.txt:

2012-10-20  Filip Pizlo  <fpizlo@apple.com>

        LLInt backends of non-ARM RISC platforms should be able to share code with the existing ARMv7 backend
        https://bugs.webkit.org/show_bug.cgi?id=99745

        Reviewed by Geoffrey Garen.

        This moves all of the things in armv7.rb that I thought are generally useful out
        into risc.rb. It also separates some phases (branch ops is separated into one
        phase that does sensible things, and another that does things that are painfully
        ARM-specific), and removes ARM assumptions from others by using a callback to
        drive exactly what lowering must happen. The goal here is to minimize the future
        maintenance burden of LLInt by ensuring that the various platforms share as much
        lowering code as possible.

        * offlineasm/armv7.rb:
        * offlineasm/risc.rb: Added.

2012-10-19  Filip Pizlo  <fpizlo@apple.com>

        DFG should have some facility for recognizing redundant CheckArrays and Arrayifies
        https://bugs.webkit.org/show_bug.cgi?id=99287

        Reviewed by Mark Hahnenberg.

        Adds reasoning about indexing type sets (i.e. ArrayModes) to AbstractValue, which
        then enables us to fold away CheckArray's and Arrayify's that are redundant.

        * bytecode/ArrayProfile.cpp:
        (JSC::arrayModesToString):
        (JSC):
        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::mergeArrayModes):
        (JSC::arrayModesAlreadyChecked):
        * bytecode/StructureSet.h:
        (JSC::StructureSet::arrayModesFromStructures):
        (StructureSet):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):
        (JSC::DFG::AbstractValue::clear):
        (JSC::DFG::AbstractValue::isClear):
        (JSC::DFG::AbstractValue::makeTop):
        (JSC::DFG::AbstractValue::clobberStructures):
        (AbstractValue):
        (JSC::DFG::AbstractValue::setMostSpecific):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::operator==):
        (JSC::DFG::AbstractValue::merge):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::filterArrayModes):
        (JSC::DFG::AbstractValue::validate):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::dump):
        (JSC::DFG::AbstractValue::clobberArrayModes):
        (JSC::DFG::AbstractValue::clobberArrayModesSlow):
        (JSC::DFG::AbstractValue::setFuturePossibleStructure):
        (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::modeAlreadyChecked):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::arrayModesFor):
        (DFG):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::arrayify):

2012-10-19  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should not inline array allocations, to make them easier to instrument
        https://bugs.webkit.org/show_bug.cgi?id=99905

        Reviewed by Mark Hahnenberg.

        This will make it easier to instrument array allocations for the purposes of profiling.
        It also allows us to kill off a bunch of code. And, this doesn't appear to hurt
        performance at all. That's expected because these days any hot allocation will end up
        in the DFG JIT, which does inline these allocations.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array):

2012-10-19  Oliver Hunt  <oliver@apple.com>

        Fix some of the regression cause by the non-local variable reworking
        https://bugs.webkit.org/show_bug.cgi?id=99896

        Reviewed by Filip Pizlo.

        The non0local variable reworking led to some of the optimisations performed by
        the bytecode generator being dropped.  This in turn put more pressure on the DFG
        optimisations.  This exposed a short coming in our double speculation propogation.
        Now we try to distinguish between places where we should SpecDoubleReal vs generic
        SpecDouble.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (PredictionPropagationPhase):
        (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction):
        (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPredictions):
        (JSC::DFG::PredictionPropagationPhase::propagate):

2012-10-19  Michael Saboff  <msaboff@apple.com>

        Lexer should create 8 bit Identifiers for RegularExpressions and ASCII identifiers
        https://bugs.webkit.org/show_bug.cgi?id=99855

        Reviewed by Filip Pizlo.

        Added makeIdentifier helpers that will always make an 8 bit Identifier or make an
        Identifier that is the same size as the template parameter.  Used the first in the fast
        path when looking for a JS identifier and the second when scanning regular expressions.

        * parser/Lexer.cpp:
        (JSC::::scanRegExp):
        * parser/Lexer.h:
        (Lexer):
        (JSC::::makeIdentifierSameType):
        (JSC::::makeLCharIdentifier):
        (JSC::::lexExpectIdentifier):

2012-10-19  Mark Lam  <mark.lam@apple.com>

        Added WTF::StackStats mechanism.
        https://bugs.webkit.org/show_bug.cgi?id=99805.

        Reviewed by Geoffrey Garen.

        Added StackStats checkpoints and probes.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNode):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::append):
        (JSC::visitChildren):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::mergeOpaqueRoots):
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::harvestWeakReferences):
        (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * parser/Parser.h:
        (JSC::Parser::canRecurse):
        * runtime/StringRecursionChecker.h:
        (StringRecursionChecker):

2012-10-19  Oliver Hunt  <oliver@apple.com>

        REGRESSION(r131822): It made 500+ tests crash on 32 bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=99814

        Reviewed by Filip Pizlo.

        Call the correct macro in 32bit. 

        * llint/LowLevelInterpreter.asm:

2012-10-19  Dongwoo Joshua Im  <dw.im@samsung.com>

        Rename ENABLE_CSS3_TEXT_DECORATION to ENABLE_CSS3_TEXT
        https://bugs.webkit.org/show_bug.cgi?id=99804

        Reviewed by Julien Chaffraix.

        CSS3 text related properties will be implemented under this flag,
        including text decoration, text-align-last, and text-justify.

        * Configurations/FeatureDefines.xcconfig:

2012-10-18  Anders Carlsson  <andersca@apple.com>

        Clean up RegExpKey
        https://bugs.webkit.org/show_bug.cgi?id=99798

        Reviewed by Darin Adler.

        RegExpHash doesn't need to be a class template specialization when the class template is specialized
        for JSC::RegExpKey only. Make it a nested class of RegExp instead. Also, make operator== a friend function
        so Hash::equal can see it.

        * runtime/RegExpKey.h:
        (JSC::RegExpKey::RegExpKey):
        (JSC::RegExpKey::operator==):
        (RegExpKey):
        (JSC::RegExpKey::Hash::hash):
        (JSC::RegExpKey::Hash::equal):
        (Hash):

2012-10-19  Mark Lam  <mark.lam@apple.com>

        Bot greening: Follow up to r131877 to fix the Windows build.
        https://bugs.webkit.org/show_bug.cgi?id=99739.

        Not reviewed.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-10-19  Mark Lam  <mark.lam@apple.com>

        Bot greening: Attempt to fix broken Window build after r131836.
        https://bugs.webkit.org/show_bug.cgi?id=99739.

        Not reviewed.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-10-19  Yuqiang Xian  <yuqiang.xian@intel.com>

        Unreviewed fix after r131868.

        On JSVALUE64 platforms, JSValue constants can be Imm64 instead of ImmPtr for JIT compilers.

        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):

2012-10-18  Filip Pizlo  <fpizlo@apple.com>

        Baseline array profiling should be less accurate, and DFG OSR exit should update array profiles on CheckArray and CheckStructure failure
        https://bugs.webkit.org/show_bug.cgi?id=99261

        Reviewed by Oliver Hunt.

        This makes array profiling stochastic, like value profiling. The point is to avoid
        noticing one-off indexing types that we'll never see again, but instead to:
        
        Notice the big ones: We want the DFG to compile based on the things that happen with
        high probability. So, this change makes array profiling do like value profiling and
        only notice a random subsampling of indexing types that flowed through an array
        access. Prior to this patch array profiles noticed all indexing types and weighted
        them identically.
        
        Bias the recent: Often an array access will see awkward indexing types during the
        first handful of executions because of artifacts of program startup. So, we want to
        bias towards the indexing types that we saw most recently. With this change, array
        profiling does like value profiling and usually tells use a random sampling that
        is biased to what happened recently.
        
        Have a backup plan: The above two things don't work by themselves because our
        randomness is not that random (nor do we care enough to make it more random), and
        because some procedures will have a <1/10 probability event that we must handle
        without bailing because it dominates a hot loop. So, like value profiling, this
        patch makes array profiling use OSR exits to tell us why we are bailing out, so
        that we don't make the same mistake again in the future.
        
        This change also makes the way that the 32-bit OSR exit compiler snatches scratch
        registers more uniform. We don't need a scratch buffer when we can push and pop.

        * bytecode/DFGExitProfile.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitArrayProfilingSite):
        * llint/LowLevelInterpreter.asm:

2012-10-18  Yuqiang Xian  <yuqiang.xian@intel.com>

        [Qt] REGRESSION(r131858): It broke the ARM build
        https://bugs.webkit.org/show_bug.cgi?id=99809

        Reviewed by Csaba Osztrogonác.

        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):

2012-10-18  Yuqiang Xian  <yuqiang.xian@intel.com>

        Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands
        https://bugs.webkit.org/show_bug.cgi?id=99154

        Reviewed by Gavin Barraclough.

        In current JavaScriptCore implementation for JSVALUE64 platform (i.e.,
        the X64 platform), we assume that the JSValue size is same to the
        pointer size, and thus EncodedJSValue is simply type defined as a
        "void*". In the JIT compiler, we also take this assumption and invoke
        the same macro assembler interfaces for both JSValue and pointer
        operands. We need to differentiate the operations on pointers from the
        operations on JSValues, and let them invoking different macro
        assembler interfaces. For example, we now use the interface of
        "loadPtr" to load either a pointer or a JSValue, and we need to switch
        to using "loadPtr" to load a pointer and some new "load64" interface
        to load a JSValue. This would help us supporting other JSVALUE64
        platforms where pointer size is not necessarily 64-bits, for example
        x32 (bug #99153).

        The major modification I made is to introduce the "*64" interfaces in
        the MacroAssembler for those operations on JSValues, keep the "*Ptr"
        interfaces for those operations on real pointers, and go through all
        the JIT compiler code to correct the usage.

        This is the second part of the work, i.e, to correct the usage of the
        new MacroAssembler interfaces in the JIT compilers, which also means
        that now EncodedJSValue is defined as a 64-bit integer, and the "*64"
        interfaces are used for it.

        * assembler/MacroAssembler.h: JSValue immediates should be in Imm64 instead of ImmPtr.
        (MacroAssembler):
        (JSC::MacroAssembler::shouldBlind):
        * dfg/DFGAssemblyHelpers.cpp: Correct the JIT compilers usage of the new interfaces.
        (JSC::DFG::AssemblyHelpers::jitAssertIsInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble):
        (JSC::DFG::AssemblyHelpers::jitAssertIsCell):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::DFG::AssemblyHelpers::branchIfNotCell):
        (JSC::DFG::AssemblyHelpers::debugCall):
        (JSC::DFG::AssemblyHelpers::boxDouble):
        (JSC::DFG::AssemblyHelpers::unboxDouble):
        (JSC::DFG::AssemblyHelpers::emitExceptionCheck):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGScratchRegisterAllocator.h:
        (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
        (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
        * dfg/DFGSilentRegisterSavePlan.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
        (JSC::DFG::SpeculativeJIT::silentSpill):
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::valueOfJSConstantAsImm64):
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::branch64):
        * 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::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (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::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        (JSC::DFG::SpeculativeJIT::convertToDouble):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileDoubleCompare):
        (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal):
        (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal):
        (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
        (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        (JSC::DFG::throwExceptionFromCallSlowPathGenerator):
        (JSC::DFG::slowPathFor):
        (JSC::DFG::virtualForThunkGenerator):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JIT):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emit_op_div):
        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITInlineMethods.h: Have some clean-up work as well.
        (JSC):
        (JSC::JIT::emitPutCellToCallFrameHeader):
        (JSC::JIT::emitPutIntToCallFrameHeader):
        (JSC::JIT::emitPutToCallFrameHeader):
        (JSC::JIT::emitGetFromCallFrameHeader32):
        (JSC::JIT::emitGetFromCallFrameHeader64):
        (JSC::JIT::emitAllocateJSArray):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::emitGetJITStubArg):
        (JSC::JIT::emitGetVirtualRegister):
        (JSC::JIT::emitPutVirtualRegister):
        (JSC::JIT::emitInitRegister):
        (JSC::JIT::emitJumpIfJSCell):
        (JSC::JIT::emitJumpIfBothJSCells):
        (JSC::JIT::emitJumpIfNotJSCell):
        (JSC::JIT::emitLoadInt32ToDouble):
        (JSC::JIT::emitJumpIfImmediateInteger):
        (JSC::JIT::emitJumpIfNotImmediateInteger):
        (JSC::JIT::emitJumpIfNotImmediateIntegers):
        (JSC::JIT::emitFastArithReTagImmediate):
        (JSC::JIT::emitFastArithIntToImmNoCheck):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_tear_off_activation):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emit_op_get_pnames):
        (JSC::JIT::emit_op_next_pname):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_throw_static_error):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_create_activation):
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emit_op_init_lazy_reg):
        (JSC::JIT::emitSlow_op_convert_this):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emit_op_get_argument_by_val):
        (JSC::JIT::emit_op_put_to_base):
        (JSC::JIT::emit_resolve_operations):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::compileGetDirectOffset):
        (JSC::JIT::emit_op_get_by_pname):
        (JSC::JIT::emitContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/JITStubCall.h:
        (JITStubCall):
        (JSC::JITStubCall::JITStubCall):
        (JSC::JITStubCall::addArgument):
        (JSC::JITStubCall::call):
        (JSC::JITStubCall::callWithValueProfiling):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber):
        (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber):
        (JSC::JSInterfaceJIT::emitLoadJSCell):
        (JSC::JSInterfaceJIT::emitLoadInt32):
        (JSC::JSInterfaceJIT::emitLoadDouble):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::returnDouble):
        (JSC::SpecializedThunkJIT::tagReturnAsInt32):
        * runtime/JSValue.cpp:
        (JSC::JSValue::description):
        * runtime/JSValue.h: Define JSVALUE64 EncodedJSValue as int64_t, which is also unified with JSVALUE32_64.
        (JSC):
        * runtime/JSValueInlineMethods.h: New implementation of some JSValue methods to make them more conformant
        with the new rule that "JSValue is a 64-bit integer rather than a pointer" for JSVALUE64 platforms.
        (JSC):
        (JSC::JSValue::JSValue):
        (JSC::JSValue::operator bool):
        (JSC::JSValue::operator==):
        (JSC::JSValue::operator!=):
        (JSC::reinterpretDoubleToInt64):
        (JSC::reinterpretInt64ToDouble):
        (JSC::JSValue::asDouble):

2012-10-18  Michael Saboff  <msaboff@apple.com>

        convertUTF8ToUTF16() Should Check for ASCII Input
        ihttps://bugs.webkit.org/show_bug.cgi?id=99739

        Reviewed by Geoffrey Garen.

        Using the updated convertUTF8ToUTF16() , we can determine if is makes more sense to 
        create a string using the 8 bit source.  Added a new OpaqueJSString::create(LChar*, unsigned).
        Had to add a cast n JSStringCreateWithCFString to differentiate which create() to call.

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString):
        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):
        * API/OpaqueJSString.h:
        (OpaqueJSString::create):
        (OpaqueJSString):
        (OpaqueJSString::OpaqueJSString):

2012-10-18  Oliver Hunt  <oliver@apple.com>

        Unbreak jsc tests.  Last minute "clever"-ness is clearly just not
        a good plan.

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

2012-10-18  Oliver Hunt  <oliver@apple.com>

        Bytecode should not have responsibility for determining how to perform non-local resolves
        https://bugs.webkit.org/show_bug.cgi?id=99349

        Reviewed by Gavin Barraclough.

        This patch removes lexical analysis from the bytecode generation.  This allows
        us to delay lookup of a non-local variables until the lookup is actually necessary,
        and simplifies a lot of the resolve logic in BytecodeGenerator.

        Once a lookup is performed we cache the lookup information in a set of out-of-line
        buffers in CodeBlock.  This allows subsequent lookups to avoid unnecessary hashing,
        etc, and allows the respective JITs to recreated optimal lookup code.

        This is currently still a performance regression in LLInt, but most of the remaining
        regression is caused by a lot of indirection that I'll remove in future work, as well
        as some work necessary to allow LLInt to perform in line instruction repatching.
        We will also want to improve the behaviour of the baseline JIT for some of the lookup
        operations, however this patch was getting quite large already so I'm landing it now
        that we've reached the bar of "performance-neutral".

        Basic browsing seems to work.

        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printStructures):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitStructures):
        (JSC):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addResolve):
        (JSC::CodeBlock::addPutToBase):
        (CodeBlock):
        (JSC::CodeBlock::resolveOperations):
        (JSC::CodeBlock::putToBaseOperation):
        (JSC::CodeBlock::numberOfResolveOperations):
        (JSC::CodeBlock::numberOfPutToBaseOperations):
        (JSC::CodeBlock::addPropertyAccessInstruction):
        (JSC::CodeBlock::globalObjectConstant):
        (JSC::CodeBlock::setGlobalObjectConstant):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h:
        (JSC):
        (ResolveGlobalStatus):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::shouldAvoidResolveGlobal):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveBase):
        (JSC::BytecodeGenerator::emitResolveBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetLocalVar):
        (JSC::BytecodeGenerator::emitInitGlobalConst):
        (JSC::BytecodeGenerator::emitPutToBase):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ResolveResult::registerResolve):
        (JSC::ResolveResult::dynamicResolve):
        (ResolveResult):
        (JSC::ResolveResult::ResolveResult):
        (JSC):
        (NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::~NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::resolved):
        (JSC::NonlocalResolveInfo::put):
        (BytecodeGenerator):
        (JSC::BytecodeGenerator::getResolveOperations):
        (JSC::BytecodeGenerator::getResolveWithThisOperations):
        (JSC::BytecodeGenerator::getResolveBaseOperations):
        (JSC::BytecodeGenerator::getResolveBaseForPutOperations):
        (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations):
        (JSC::BytecodeGenerator::getPutToBaseOperation):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::ForInNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (DFG):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canInlineResolveOperations):
        (DFG):
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGGraph.h:
        (ResolveGlobalData):
        (ResolveOperationData):
        (DFG):
        (PutToBaseOperationData):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::resolveOperationsDataIndex):
        (Node):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::resolveOperations):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::putToBaseOperation):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_put_to_base):
        (JSC):
        (JSC::JIT::emit_resolve_operations):
        (JSC::JIT::emitSlow_link_resolve_operations):
        (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):
        (JSC):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSScope.cpp:
        (JSC::LookupResult::base):
        (JSC::LookupResult::value):
        (JSC::LookupResult::setBase):
        (JSC::LookupResult::setValue):
        (LookupResult):
        (JSC):
        (JSC::setPutPropertyAccessOffset):
        (JSC::executeResolveOperations):
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolveContainingScope):
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis):
        (JSC::JSScope::resolvePut):
        (JSC::JSScope::resolveGlobal):
        * runtime/JSScope.h:
        (JSScope):
        * runtime/JSVariableObject.cpp:
        (JSC):
        * runtime/JSVariableObject.h:
        (JSVariableObject):
        * runtime/Structure.h:
        (JSC::Structure::propertyAccessesAreCacheable):
        (Structure):

2012-10-18  Mark Hahnenberg  <mhahnenberg@apple.com>

        Live oversize copied blocks should count toward overall heap fragmentation
        https://bugs.webkit.org/show_bug.cgi?id=99548

        Reviewed by Filip Pizlo.

        The CopiedSpace uses overall heap fragmentation to determine whether or not it should do any copying. 
        Currently it doesn't include live oversize CopiedBlocks in the calculation, but it should. We should 
        treat them as 100% utilized, since running a copying phase won't be able to free/compact any of their 
        memory. We can also free any dead oversize CopiedBlocks while we're iterating over them, rather than 
        iterating over them again at the end of the copying phase.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::doneFillingBlock):
        (JSC::CopiedSpace::startedCopying):
        (JSC::CopiedSpace::doneCopying): Also removed a branch when iterating over from-space at the end of 
        copying. Since we eagerly recycle blocks as soon as they're fully evacuated, we should see no
        unpinned blocks in from-space at the end of copying.
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::recycleBorrowedBlock):
        * heap/CopyVisitorInlineMethods.h:
        (JSC::CopyVisitor::checkIfShouldCopy):

2012-10-18  Roger Fong  <roger_fong@apple.com>

        Unreviewed. Build fix after r131701 and r131777.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-10-18  Mark Hahnenberg  <mhahnenberg@apple.com>

        Race condition between GCThread and main thread during copying phase
        https://bugs.webkit.org/show_bug.cgi?id=99641

        Reviewed by Filip Pizlo.

        When a GCThread returns from copyFromShared(), it then calls doneCopying(), which returns 
        its borrowed CopiedBlock to the CopiedSpace. This final block allows the CopiedSpace to 
        continue and finish the cleanup of the copying phase. However, the GCThread can loop back 
        around, see that m_currentPhase is still "Copy", and try to go through the copying phase again. 
        This can cause all sorts of issues. To fix this, we should add a cyclic barrier to GCThread::waitForNextPhase().

        * heap/GCThread.cpp:
        (JSC::GCThread::waitForNextPhase): All GCThreads will wait when they finish one iteration until the main thread 
        notifies them to move down to the second while loop, where they wait for the next GCPhase to start. They also 
        decrement the m_numberOfActiveGCThreads counter as they begin to wait for the next phase and increment it as 
        they enter the next phase. This allows the main thread to wait in endCurrentPhase() until all the threads have 
        finished the current phase and are waiting on the next phase to begin. Without the counter, there would be 
        no way to ensure that every thread was available for each GCPhase.
        (JSC::GCThread::gcThreadMain): We now use the m_phaseLock to synchronize with the main thread when we're being created.
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData): As we create each GCThread, we increment the m_numberOfActiveGCThreads
        counter. When we are done creating the threads, we wait until they're all waiting for the next GCPhase. This prevents 
        us from leaving some GCThreads behind during the first GCPhase, which could hurt us on our very short-running 
        benchmarks (e.g. SunSpider).
        (JSC::GCThreadSharedData::~GCThreadSharedData):
        (JSC::GCThreadSharedData::startNextPhase): We atomically swap the two flags, m_gcThreadsShouldWait and m_currentPhase, 
        so that if the threads finish very quickly, they will wait until the main thread is ready to end the current phase.
        (JSC::GCThreadSharedData::endCurrentPhase): Here atomically we swap the two flags again to allow the threads to 
        advance to waiting on the next GCPhase. We wait until all of the GCThreads have settled into the second wait loop
        before allowing the main thread to continue. This prevents us from leaving one of the GCThreads stuck in the first 
        wait loop if we were to call startNextPhase() before it had time to wake up and move on to the second wait loop.
        (JSC):
        (JSC::GCThreadSharedData::didStartMarking): We now use startNextPhase() to properly swap the flags.
        (JSC::GCThreadSharedData::didFinishMarking): Ditto for endCurrentPhase().
        (JSC::GCThreadSharedData::didStartCopying): Ditto.
        (JSC::GCThreadSharedData::didFinishCopying): Ditto.
        * heap/GCThreadSharedData.h:
        (GCThreadSharedData):
        * heap/Heap.cpp: 
        (JSC::Heap::copyBackingStores): No reason to use the extra reference.

2012-10-18  Pablo Flouret  <pablof@motorola.com>

        Implement css3-conditional's @supports rule
        https://bugs.webkit.org/show_bug.cgi?id=86146

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:
            Add an ENABLE_CSS3_CONDITIONAL_RULES flag.

2012-10-18  Michael Saboff  <msaboff@apple.com>

        Make conversion between JSStringRef and WKStringRef work without character size conversions
        https://bugs.webkit.org/show_bug.cgi?id=99727

        Reviewed by Anders Carlsson.

        Export the string() method for use in WebKit.

        * API/OpaqueJSString.h:
        (OpaqueJSString::string):

2012-10-18  Raphael Kubo da Costa  <raphael.kubo.da.costa@intel.com>

        [CMake] Avoid unnecessarily running the LLInt generation commands.
        https://bugs.webkit.org/show_bug.cgi?id=99708

        Reviewed by Rob Buis.

        As described in the comments in the change itself, in some cases
        the Ruby generation scripts used when LLInt is on would each be
        run twice in every build even if nothing had changed.

        Fix that by not setting the OBJECT_DEPENDS property of some source
        files to depend on the generated headers; instead, they are now
        just part of the final binaries/libraries which use them.

        * CMakeLists.txt:

2012-10-17  Zoltan Horvath  <zoltan@webkit.org>

        Remove the JSHeap memory measurement of the PageLoad performacetests since it creates bogus JSGlobalDatas
        https://bugs.webkit.org/show_bug.cgi?id=99609 

        Reviewed by Ryosuke Niwa.

        Remove the implementation since it creates bogus JSGlobalDatas in the layout tests.

        * heap/HeapStatistics.cpp:
        (JSC):
        * heap/HeapStatistics.h:
        (HeapStatistics):

2012-10-17  Sam Weinig  <sam@webkit.org>

        Attempt to fix the build.

        * bytecode/GlobalResolveInfo.h: Copied from bytecode/GlobalResolveInfo.h.

2012-10-17  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r130826 or r130828): Twitter top bar is dysfunctional
        https://bugs.webkit.org/show_bug.cgi?id=99577
        <rdar://problem/12518883>

        Reviewed by Mark Hahnenberg.

        It turns out that it's a good idea to maintain the invariants of your object model, such as that
        elements past publicLength should have the hole value.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-17  Anders Carlsson  <andersca@apple.com>

        Clean up Vector.h
        https://bugs.webkit.org/show_bug.cgi?id=99622

        Reviewed by Benjamin Poulain.

        Fix fallout from removing std::max and std::min using declarations.

        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::stringProtoFuncIndexOf):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):

2012-10-17  Oliver Hunt  <oliver@apple.com>

        Committing new files is so overrated.

        * bytecode/ResolveOperation.h: Added.
        (JSC):
        (JSC::ResolveOperation::getAndReturnScopedVar):
        (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope):
        (ResolveOperation):
        (JSC::ResolveOperation::getAndReturnGlobalVar):
        (JSC::ResolveOperation::getAndReturnGlobalProperty):
        (JSC::ResolveOperation::resolveFail):
        (JSC::ResolveOperation::skipTopScopeNode):
        (JSC::ResolveOperation::skipScopes):
        (JSC::ResolveOperation::returnGlobalObjectAsBase):
        (JSC::ResolveOperation::setBaseToGlobal):
        (JSC::ResolveOperation::setBaseToUndefined):
        (JSC::ResolveOperation::setBaseToScope):
        (JSC::ResolveOperation::returnScopeAsBase):
        (JSC::PutToBaseOperation::PutToBaseOperation):

2012-10-17  Michael Saboff  <msaboff@apple.com>

        StringPrototype::jsSpliceSubstringsWithSeparators() doesn't optimally handle 8 bit strings
        https://bugs.webkit.org/show_bug.cgi?id=99230

        Reviewed by Geoffrey Garen.

        Added code to select characters8() or characters16() on the not all 8 bit path for both the 
        processing of the source and the separators.

        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstringsWithSeparators):

2012-10-17  Filip Pizlo  <fpizlo@apple.com>

        Array and object allocations via 'new Object' or 'new Array' should be inlined in bytecode to allow allocation site profiling
        https://bugs.webkit.org/show_bug.cgi?id=99557

        Reviewed by Geoffrey Garen.

        Removed an inaccurate and misleading comment as per Geoff's review. (I forgot
        to make this change as part of http://trac.webkit.org/changeset/131644).

        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallResolveNode::emitBytecode):

2012-10-17  Oliver Hunt  <oliver@apple.com>

        Bytecode should not have responsibility for determining how to perform non-local resolves
        https://bugs.webkit.org/show_bug.cgi?id=99349

        Reviewed by Gavin Barraclough.

        This patch removes lexical analysis from the bytecode generation.  This allows
        us to delay lookup of a non-local variables until the lookup is actually necessary,
        and simplifies a lot of the resolve logic in BytecodeGenerator.

        Once a lookup is performed we cache the lookup information in a set of out-of-line
        buffers in CodeBlock.  This allows subsequent lookups to avoid unnecessary hashing,
        etc, and allows the respective JITs to recreated optimal lookup code.

        This is currently still a performance regression in LLInt, but most of the remaining
        regression is caused by a lot of indirection that I'll remove in future work, as well
        as some work necessary to allow LLInt to perform in line instruction repatching.
        We will also want to improve the behaviour of the baseline JIT for some of the lookup
        operations, however this patch was getting quite large already so I'm landing it now
        that we've reached the bar of "performance-neutral".

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printStructures):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitStructures):
        (JSC):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addResolve):
        (JSC::CodeBlock::addPutToBase):
        (CodeBlock):
        (JSC::CodeBlock::resolveOperations):
        (JSC::CodeBlock::putToBaseOperation):
        (JSC::CodeBlock::numberOfResolveOperations):
        (JSC::CodeBlock::numberOfPutToBaseOperations):
        (JSC::CodeBlock::addPropertyAccessInstruction):
        (JSC::CodeBlock::globalObjectConstant):
        (JSC::CodeBlock::setGlobalObjectConstant):
        * bytecode/GlobalResolveInfo.h: Removed.
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h:
        (JSC):
        (ResolveGlobalStatus):
        * bytecode/ResolveOperation.h: Added.
          The new types and logic we use to perform the cached lookups.
        (JSC):
        (ResolveOperation):
        (JSC::ResolveOperation::getAndReturnScopedVar):
        (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope):
        (JSC::ResolveOperation::getAndReturnGlobalVar):
        (JSC::ResolveOperation::getAndReturnGlobalProperty):
        (JSC::ResolveOperation::resolveFail):
        (JSC::ResolveOperation::skipTopScopeNode):
        (JSC::ResolveOperation::skipScopes):
        (JSC::ResolveOperation::returnGlobalObjectAsBase):
        (JSC::ResolveOperation::setBaseToGlobal):
        (JSC::ResolveOperation::setBaseToUndefined):
        (JSC::ResolveOperation::setBaseToScope):
        (JSC::ResolveOperation::returnScopeAsBase):
        (JSC::PutToBaseOperation::PutToBaseOperation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::shouldAvoidResolveGlobal):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveBase):
        (JSC::BytecodeGenerator::emitResolveBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetLocalVar):
        (JSC::BytecodeGenerator::emitInitGlobalConst):
        (JSC::BytecodeGenerator::emitPutToBase):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ResolveResult::registerResolve):
        (JSC::ResolveResult::dynamicResolve):
        (ResolveResult):
        (JSC::ResolveResult::ResolveResult):
        (JSC):
        (NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::~NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::resolved):
        (JSC::NonlocalResolveInfo::put):
        (BytecodeGenerator):
        (JSC::BytecodeGenerator::getResolveOperations):
        (JSC::BytecodeGenerator::getResolveWithThisOperations):
        (JSC::BytecodeGenerator::getResolveBaseOperations):
        (JSC::BytecodeGenerator::getResolveBaseForPutOperations):
        (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations):
        (JSC::BytecodeGenerator::getPutToBaseOperation):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::ForInNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (DFG):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileResolveOperations):
        (DFG):
        (JSC::DFG::canCompilePutToBaseOperation):
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGGraph.h:
        (ResolveGlobalData):
        (ResolveOperationData):
        (DFG):
        (PutToBaseOperationData):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::resolveOperationsDataIndex):
        (Node):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::resolveOperations):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::putToBaseOperation):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_put_to_base):
        (JSC):
        (JSC::JIT::emit_resolve_operations):
        (JSC::JIT::emitSlow_link_resolve_operations):
        (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):
        (JSC):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSScope.cpp:
        (JSC::LookupResult::base):
        (JSC::LookupResult::value):
        (JSC::LookupResult::setBase):
        (JSC::LookupResult::setValue):
        (LookupResult):
        (JSC):
        (JSC::setPutPropertyAccessOffset):
        (JSC::executeResolveOperations):
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolveContainingScope):
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis):
        (JSC::JSScope::resolvePut):
        (JSC::JSScope::resolveGlobal):
        * runtime/JSScope.h:
        (JSScope):
        * runtime/JSVariableObject.cpp:
        (JSC):
        * runtime/JSVariableObject.h:
        (JSVariableObject):
        * runtime/Structure.h:
        (JSC::Structure::propertyAccessesAreCacheable):
        (Structure):

2012-10-17  Filip Pizlo  <fpizlo@apple.com>

        Array and object allocations via 'new Object' or 'new Array' should be inlined in bytecode to allow allocation site profiling
        https://bugs.webkit.org/show_bug.cgi?id=99557

        Reviewed by Geoffrey Garen.

        This uses the old jneq_ptr trick to allow for the bytecode to "see" that the
        operation in question is what we almost certainly know it to be.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/SpecialPointer.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::NewExprNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        (JIT):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array_with_size):
        (JSC):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (LLInt):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        (JSC):
        * runtime/ArrayConstructor.h:
        (JSC):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):

2012-10-17  Filip Pizlo  <fpizlo@apple.com>

        JIT op_get_by_pname should call cti_get_by_val_generic and not cti_get_by_val
        https://bugs.webkit.org/show_bug.cgi?id=99631
        <rdar://problem/12483221>

        Reviewed by Mark Hahnenberg.

        cti_get_by_val assumes that the return address has patching metadata associated with it, which won't
        be true for op_get_by_pname. cti_get_by_val_generic makes no such assumptions.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_get_by_pname):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_get_by_pname):

2012-10-17  Mark Hahnenberg  <mhahnenberg@apple.com>

        Block freeing thread should sleep indefinitely when there's no work to do
        https://bugs.webkit.org/show_bug.cgi?id=98084

        Reviewed by Geoffrey Garen.

        r130212 didn't fully fix the problem.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::blockFreeingThreadMain): We would just continue to the next iteration if 
        we found that we had zero blocks to copy. We should move the indefinite wait up to where that 
        check is done so that we properly detect the "no more blocks to copy, wait for more" condition.

2012-10-16  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed, rolling out r131516 and r131550.
        http://trac.webkit.org/changeset/131516
        http://trac.webkit.org/changeset/131550
        https://bugs.webkit.org/show_bug.cgi?id=99349

        It caused zillion different problem on different platforms

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::isGlobalResolve):
        (JSC::instructionOffsetForNth):
        (JSC::printGlobalResolveInfo):
        (JSC::CodeBlock::printStructures):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitStructures):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::hasGlobalResolveInfoAtBytecodeOffset):
        (JSC::CodeBlock::globalResolveInfoForBytecodeOffset):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::addGlobalResolveInstruction):
        (JSC::CodeBlock::addGlobalResolveInfo):
        (JSC::CodeBlock::globalResolveInfo):
        (JSC::CodeBlock::numberOfGlobalResolveInfos):
        (JSC::CodeBlock::globalResolveInfoCount):
        * bytecode/GlobalResolveInfo.h: Copied from Source/JavaScriptCore/bytecode/ResolveGlobalStatus.cpp.
        (JSC):
        (JSC::GlobalResolveInfo::GlobalResolveInfo):
        (GlobalResolveInfo):
        (JSC::getGlobalResolveInfoBytecodeOffset):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC):
        (JSC::computeForStructure):
        (JSC::computeForLLInt):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h:
        (JSC):
        (ResolveGlobalStatus):
        * bytecode/ResolveOperation.h: Removed.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC::ResolveResult::registerPointer):
        (JSC):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::shouldAvoidResolveGlobal):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveBase):
        (JSC::BytecodeGenerator::emitResolveBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithBase):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetStaticVar):
        (JSC::BytecodeGenerator::emitInitGlobalConst):
        (JSC::BytecodeGenerator::emitPutStaticVar):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ResolveResult::registerResolve):
        (JSC::ResolveResult::dynamicResolve):
        (JSC::ResolveResult::lexicalResolve):
        (JSC::ResolveResult::indexedGlobalResolve):
        (JSC::ResolveResult::dynamicIndexedGlobalResolve):
        (JSC::ResolveResult::globalResolve):
        (JSC::ResolveResult::dynamicGlobalResolve):
        (JSC::ResolveResult::type):
        (JSC::ResolveResult::index):
        (JSC::ResolveResult::depth):
        (JSC::ResolveResult::globalObject):
        (ResolveResult):
        (JSC::ResolveResult::isStatic):
        (JSC::ResolveResult::isIndexed):
        (JSC::ResolveResult::isScoped):
        (JSC::ResolveResult::isGlobal):
        (JSC::ResolveResult::ResolveResult):
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::ForInNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGGraph.h:
        (ResolveGlobalData):
        (DFG):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        (JSC):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        (JSC::JIT::emit_op_get_global_var_watchable):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_resolve):
        (JSC):
        (JSC::JIT::emit_op_resolve_base):
        (JSC::JIT::emit_op_resolve_skip):
        (JSC::JIT::emit_op_resolve_global):
        (JSC::JIT::emitSlow_op_resolve_global):
        (JSC::JIT::emit_op_resolve_with_base):
        (JSC::JIT::emit_op_resolve_with_this):
        (JSC::JIT::emit_op_resolve_global_dynamic):
        (JSC::JIT::emitSlow_op_resolve_global_dynamic):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_resolve):
        (JSC):
        (JSC::JIT::emit_op_resolve_base):
        (JSC::JIT::emit_op_resolve_skip):
        (JSC::JIT::emit_op_resolve_global):
        (JSC::JIT::emitSlow_op_resolve_global):
        (JSC::JIT::emit_op_resolve_with_base):
        (JSC::JIT::emit_op_resolve_with_this):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_scoped_var):
        (JSC):
        (JSC::JIT::emit_op_put_scoped_var):
        (JSC::JIT::emit_op_get_global_var):
        (JSC::JIT::emit_op_put_global_var):
        (JSC::JIT::emit_op_put_global_var_check):
        (JSC::JIT::emitSlow_op_put_global_var_check):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_scoped_var):
        (JSC):
        (JSC::JIT::emit_op_put_scoped_var):
        (JSC::JIT::emit_op_get_global_var):
        (JSC::JIT::emit_op_put_global_var):
        (JSC::JIT::emit_op_put_global_var_check):
        (JSC::JIT::emitSlow_op_put_global_var_check):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveSkip):
        (JSC::JSScope::resolveGlobal):
        (JSC::JSScope::resolveGlobalDynamic):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis):
        * runtime/JSScope.h:
        (JSScope):
        * runtime/JSVariableObject.cpp:
        * runtime/JSVariableObject.h:
        * runtime/Structure.h:

2012-10-16  Dongwoo Joshua Im  <dw.im@samsung.com>

        [GTK] Fix build break - ResolveOperations.h is not in WebKit.
        https://bugs.webkit.org/show_bug.cgi?id=99538

        Unreviewed build fix.

        There are some files including ResolveOperations.h which is not exist at all.

        * GNUmakefile.list.am: s/ResolveOperations.h/ResolveOperation.h/
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: s/ResolveOperations.h/ResolveOperation.h/

2012-10-16  Jian Li  <jianli@chromium.org>

        Rename feature define ENABLE_WIDGET_REGION to ENABLE_DRAGGBALE_REGION
        https://bugs.webkit.org/show_bug.cgi?id=98975

        Reviewed by Adam Barth.

        Renaming is needed to better match with the draggable region code. 

        * Configurations/FeatureDefines.xcconfig:

2012-10-15  Oliver Hunt  <oliver@apple.com>

        Bytecode should not have responsibility for determining how to perform non-local resolves
        https://bugs.webkit.org/show_bug.cgi?id=99349

        Reviewed by Gavin Barraclough.

        This patch removes lexical analysis from the bytecode generation.  This allows
        us to delay lookup of a non-local variables until the lookup is actually necessary,
        and simplifies a lot of the resolve logic in BytecodeGenerator.

        Once a lookup is performed we cache the lookup information in a set of out-of-line
        buffers in CodeBlock.  This allows subsequent lookups to avoid unnecessary hashing,
        etc, and allows the respective JITs to recreated optimal lookup code.

        This is currently still a performance regression in LLInt, but most of the remaining
        regression is caused by a lot of indirection that I'll remove in future work, as well
        as some work necessary to allow LLInt to perform in line instruction repatching.
        We will also want to improve the behaviour of the baseline JIT for some of the lookup
        operations, however this patch was getting quite large already so I'm landing it now
        that we've reached the bar of "performance-neutral".

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printStructures):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitStructures):
        (JSC):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addResolve):
        (JSC::CodeBlock::addPutToBase):
        (CodeBlock):
        (JSC::CodeBlock::resolveOperations):
        (JSC::CodeBlock::putToBaseOperation):
        (JSC::CodeBlock::numberOfResolveOperations):
        (JSC::CodeBlock::numberOfPutToBaseOperations):
        (JSC::CodeBlock::addPropertyAccessInstruction):
        (JSC::CodeBlock::globalObjectConstant):
        (JSC::CodeBlock::setGlobalObjectConstant):
        * bytecode/GlobalResolveInfo.h: Removed.
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h:
        (JSC):
        (ResolveGlobalStatus):
        * bytecode/ResolveOperation.h: Added.
          The new types and logic we use to perform the cached lookups.
        (JSC):
        (ResolveOperation):
        (JSC::ResolveOperation::getAndReturnScopedVar):
        (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope):
        (JSC::ResolveOperation::getAndReturnGlobalVar):
        (JSC::ResolveOperation::getAndReturnGlobalProperty):
        (JSC::ResolveOperation::resolveFail):
        (JSC::ResolveOperation::skipTopScopeNode):
        (JSC::ResolveOperation::skipScopes):
        (JSC::ResolveOperation::returnGlobalObjectAsBase):
        (JSC::ResolveOperation::setBaseToGlobal):
        (JSC::ResolveOperation::setBaseToUndefined):
        (JSC::ResolveOperation::setBaseToScope):
        (JSC::ResolveOperation::returnScopeAsBase):
        (JSC::PutToBaseOperation::PutToBaseOperation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::shouldAvoidResolveGlobal):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveBase):
        (JSC::BytecodeGenerator::emitResolveBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetLocalVar):
        (JSC::BytecodeGenerator::emitInitGlobalConst):
        (JSC::BytecodeGenerator::emitPutToBase):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ResolveResult::registerResolve):
        (JSC::ResolveResult::dynamicResolve):
        (ResolveResult):
        (JSC::ResolveResult::ResolveResult):
        (JSC):
        (NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::~NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::resolved):
        (JSC::NonlocalResolveInfo::put):
        (BytecodeGenerator):
        (JSC::BytecodeGenerator::getResolveOperations):
        (JSC::BytecodeGenerator::getResolveWithThisOperations):
        (JSC::BytecodeGenerator::getResolveBaseOperations):
        (JSC::BytecodeGenerator::getResolveBaseForPutOperations):
        (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations):
        (JSC::BytecodeGenerator::getPutToBaseOperation):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::ForInNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (DFG):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileResolveOperations):
        (DFG):
        (JSC::DFG::canCompilePutToBaseOperation):
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGGraph.h:
        (ResolveGlobalData):
        (ResolveOperationData):
        (DFG):
        (PutToBaseOperationData):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::resolveOperationsDataIndex):
        (Node):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::resolveOperations):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::putToBaseOperation):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_put_to_base):
        (JSC):
        (JSC::JIT::emit_resolve_operations):
        (JSC::JIT::emitSlow_link_resolve_operations):
        (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):
        (JSC):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSScope.cpp:
        (JSC::LookupResult::base):
        (JSC::LookupResult::value):
        (JSC::LookupResult::setBase):
        (JSC::LookupResult::setValue):
        (LookupResult):
        (JSC):
        (JSC::setPutPropertyAccessOffset):
        (JSC::executeResolveOperations):
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolveContainingScope):
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis):
        (JSC::JSScope::resolvePut):
        (JSC::JSScope::resolveGlobal):
        * runtime/JSScope.h:
        (JSScope):
        * runtime/JSVariableObject.cpp:
        (JSC):
        * runtime/JSVariableObject.h:
        (JSVariableObject):
        * runtime/Structure.h:
        (JSC::Structure::propertyAccessesAreCacheable):
        (Structure):

2012-10-16  Filip Pizlo  <fpizlo@apple.com>

        Accidental switch fall-through in DFG::FixupPhase
        https://bugs.webkit.org/show_bug.cgi?id=96956
        <rdar://problem/12313242>

        Reviewed by Mark Hahnenberg.

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

2012-10-16  Filip Pizlo  <fpizlo@apple.com>

        GetScopedVar CSE matches dead GetScopedVar's leading to IR corruption
        https://bugs.webkit.org/show_bug.cgi?id=99470
        <rdar://problem/12363698>

        Reviewed by Mark Hahnenberg.

        All it takes is to follow the "if (!shouldGenerate) continue" idiom and everything will be OK.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::globalVarLoadElimination):
        (JSC::DFG::CSEPhase::scopedVarLoadElimination):
        (JSC::DFG::CSEPhase::globalVarWatchpointElimination):
        (JSC::DFG::CSEPhase::getByValLoadElimination):
        (JSC::DFG::CSEPhase::checkStructureElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::getByOffsetLoadElimination):

2012-10-16  Dima Gorbik  <dgorbik@apple.com>

        Remove Platform.h include from the header files.
        https://bugs.webkit.org/show_bug.cgi?id=98665

        Reviewed by Eric Seidel.

        We don't want other clients that include WebKit headers to know about Platform.h.

        * API/tests/minidom.c:
        * API/tests/testapi.c:

2012-10-16  Balazs Kilvady  <kilvadyb@homejinni.com>

        Add missing MIPS functions to assembler.
        https://bugs.webkit.org/show_bug.cgi?id=98856

        Reviewed by Oliver Hunt.

        Implement missing functions in MacroAssemblerMIPS and MIPSAssembler.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::lb):
        (MIPSAssembler):
        (JSC::MIPSAssembler::lh):
        (JSC::MIPSAssembler::cvtds):
        (JSC::MIPSAssembler::cvtsd):
        (JSC::MIPSAssembler::vmov):
        * assembler/MacroAssemblerMIPS.h:
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::load8Signed):
        (JSC::MacroAssemblerMIPS::load16Signed):
        (JSC::MacroAssemblerMIPS::moveDoubleToInts):
        (JSC::MacroAssemblerMIPS::moveIntsToDouble):
        (JSC::MacroAssemblerMIPS::loadFloat):
        (JSC::MacroAssemblerMIPS::loadDouble):
        (JSC::MacroAssemblerMIPS::storeFloat):
        (JSC::MacroAssemblerMIPS::storeDouble):
        (JSC::MacroAssemblerMIPS::addDouble):
        (JSC::MacroAssemblerMIPS::convertFloatToDouble):
        (JSC::MacroAssemblerMIPS::convertDoubleToFloat):

2012-10-16  Balazs Kilvady  <kilvadyb@homejinni.com>

        MIPS assembler coding-style fix.
        https://bugs.webkit.org/show_bug.cgi?id=99359

        Reviewed by Oliver Hunt.

        Coding style fix of existing MIPS assembler header files.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::addiu):
        (JSC::MIPSAssembler::addu):
        (JSC::MIPSAssembler::subu):
        (JSC::MIPSAssembler::mul):
        (JSC::MIPSAssembler::andInsn):
        (JSC::MIPSAssembler::andi):
        (JSC::MIPSAssembler::nor):
        (JSC::MIPSAssembler::orInsn):
        (JSC::MIPSAssembler::ori):
        (JSC::MIPSAssembler::xorInsn):
        (JSC::MIPSAssembler::xori):
        (JSC::MIPSAssembler::slt):
        (JSC::MIPSAssembler::sltu):
        (JSC::MIPSAssembler::sltiu):
        (JSC::MIPSAssembler::sll):
        (JSC::MIPSAssembler::sllv):
        (JSC::MIPSAssembler::sra):
        (JSC::MIPSAssembler::srav):
        (JSC::MIPSAssembler::srl):
        (JSC::MIPSAssembler::srlv):
        (JSC::MIPSAssembler::lbu):
        (JSC::MIPSAssembler::lw):
        (JSC::MIPSAssembler::lwl):
        (JSC::MIPSAssembler::lwr):
        (JSC::MIPSAssembler::lhu):
        (JSC::MIPSAssembler::sb):
        (JSC::MIPSAssembler::sh):
        (JSC::MIPSAssembler::sw):
        (JSC::MIPSAssembler::addd):
        (JSC::MIPSAssembler::subd):
        (JSC::MIPSAssembler::muld):
        (JSC::MIPSAssembler::divd):
        (JSC::MIPSAssembler::lwc1):
        (JSC::MIPSAssembler::ldc1):
        (JSC::MIPSAssembler::swc1):
        (JSC::MIPSAssembler::sdc1):
        (MIPSAssembler):
        (JSC::MIPSAssembler::relocateJumps):
        (JSC::MIPSAssembler::linkWithOffset):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::add32):
        (JSC::MacroAssemblerMIPS::and32):
        (JSC::MacroAssemblerMIPS::sub32):
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::load8):
        (JSC::MacroAssemblerMIPS::load32):
        (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords):
        (JSC::MacroAssemblerMIPS::load16):
        (JSC::MacroAssemblerMIPS::store8):
        (JSC::MacroAssemblerMIPS::store16):
        (JSC::MacroAssemblerMIPS::store32):
        (JSC::MacroAssemblerMIPS::nearCall):
        (JSC::MacroAssemblerMIPS::test8):
        (JSC::MacroAssemblerMIPS::test32):

2012-10-16  Yuqiang Xian  <yuqiang.xian@intel.com>

        Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands
        https://bugs.webkit.org/show_bug.cgi?id=99154

        Reviewed by Gavin Barraclough.

        In current JavaScriptCore implementation for JSVALUE64 platform (i.e.,
        the X64 platform), we assume that the JSValue size is same to the
        pointer size, and thus EncodedJSValue is simply type defined as a
        "void*". In the JIT compiler, we also take this assumption and invoke
        the same macro assembler interfaces for both JSValue and pointer
        operands. We need to differentiate the operations on pointers from the
        operations on JSValues, and let them invoking different macro
        assembler interfaces. For example, we now use the interface of
        "loadPtr" to load either a pointer or a JSValue, and we need to switch
        to using "loadPtr" to load a pointer and some new "load64" interface
        to load a JSValue. This would help us supporting other JSVALUE64
        platforms where pointer size is not necessarily 64-bits, for example
        x32 (bug #99153).

        The major modification I made is to introduce the "*64" interfaces in
        the MacroAssembler for those operations on JSValues, keep the "*Ptr"
        interfaces for those operations on real pointers, and go through all
        the JIT compiler code to correct the usage.

        This is the first part of the work, i.e, to add the *64 interfaces to
        the MacroAssembler.

        * assembler/AbstractMacroAssembler.h: Add the Imm64 interfaces.
        (AbstractMacroAssembler):
        (JSC::AbstractMacroAssembler::TrustedImm64::TrustedImm64):
        (TrustedImm64):
        (JSC::AbstractMacroAssembler::Imm64::Imm64):
        (Imm64):
        (JSC::AbstractMacroAssembler::Imm64::asTrustedImm64):
        * assembler/MacroAssembler.h: map <foo>Ptr methods to <foo>64 for X86_64.
        (MacroAssembler):
        (JSC::MacroAssembler::peek64):
        (JSC::MacroAssembler::poke):
        (JSC::MacroAssembler::poke64):
        (JSC::MacroAssembler::addPtr):
        (JSC::MacroAssembler::andPtr):
        (JSC::MacroAssembler::negPtr):
        (JSC::MacroAssembler::orPtr):
        (JSC::MacroAssembler::rotateRightPtr):
        (JSC::MacroAssembler::subPtr):
        (JSC::MacroAssembler::xorPtr):
        (JSC::MacroAssembler::loadPtr):
        (JSC::MacroAssembler::loadPtrWithAddressOffsetPatch):
        (JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch):
        (JSC::MacroAssembler::storePtr):
        (JSC::MacroAssembler::storePtrWithAddressOffsetPatch):
        (JSC::MacroAssembler::movePtrToDouble):
        (JSC::MacroAssembler::moveDoubleToPtr):
        (JSC::MacroAssembler::comparePtr):
        (JSC::MacroAssembler::testPtr):
        (JSC::MacroAssembler::branchPtr):
        (JSC::MacroAssembler::branchTestPtr):
        (JSC::MacroAssembler::branchAddPtr):
        (JSC::MacroAssembler::branchSubPtr):
        (JSC::MacroAssembler::shouldBlindDouble):
        (JSC::MacroAssembler::shouldBlind):
        (JSC::MacroAssembler::RotatedImm64::RotatedImm64):
        (RotatedImm64):
        (JSC::MacroAssembler::rotationBlindConstant):
        (JSC::MacroAssembler::loadRotationBlindedConstant):
        (JSC::MacroAssembler::move):
        (JSC::MacroAssembler::and64):
        (JSC::MacroAssembler::store64):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::shouldBlindForSpecificArch):
        (MacroAssemblerX86Common):
        (JSC::MacroAssemblerX86Common::move):
        * assembler/MacroAssemblerX86_64.h: Add the <foo>64 methods for X86_64.
        (JSC::MacroAssemblerX86_64::branchAdd32):
        (JSC::MacroAssemblerX86_64::add64):
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::and64):
        (JSC::MacroAssemblerX86_64::neg64):
        (JSC::MacroAssemblerX86_64::or64):
        (JSC::MacroAssemblerX86_64::rotateRight64):
        (JSC::MacroAssemblerX86_64::sub64):
        (JSC::MacroAssemblerX86_64::xor64):
        (JSC::MacroAssemblerX86_64::load64):
        (JSC::MacroAssemblerX86_64::load64WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::load64WithCompactAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::store64):
        (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::move64ToDouble):
        (JSC::MacroAssemblerX86_64::moveDoubleTo64):
        (JSC::MacroAssemblerX86_64::compare64):
        (JSC::MacroAssemblerX86_64::branch64):
        (JSC::MacroAssemblerX86_64::branchTest64):
        (JSC::MacroAssemblerX86_64::test64):
        (JSC::MacroAssemblerX86_64::branchAdd64):
        (JSC::MacroAssemblerX86_64::branchSub64):
        (JSC::MacroAssemblerX86_64::branchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::storePtrWithPatch):

2012-10-15  Mark Hahnenberg  <mhahnenberg@apple.com>

        Make CopiedSpace and MarkedSpace regions independent
        https://bugs.webkit.org/show_bug.cgi?id=99222

        Reviewed by Filip Pizlo.

        Right now CopiedSpace and MarkedSpace have the same block size and share the same regions, 
        but there's no reason that they can't have different block sizes while still sharing the 
        same underlying regions. We should factor the two "used" lists of regions apart so that 
        MarkedBlocks and CopiedBlocks can be different sizes. Regions will still be a uniform size 
        so that when they become empty they may be shared between the CopiedSpace and the MarkedSpace, 
        since benchmarks indicate that sharing is a boon for performance.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::BlockAllocator):
        * heap/BlockAllocator.h:
        (JSC):
        (Region):
        (JSC::Region::create): We now have a fixed size for Regions so that empty regions can continue to 
        be shared between the MarkedSpace and CopiedSpace. Once they are used for a specific type of block,
        however, they can only be used for that type of block until they become empty again.
        (JSC::Region::createCustomSize):
        (JSC::Region::Region):
        (JSC::Region::~Region):
        (JSC::Region::reset):
        (BlockAllocator):
        (JSC::BlockAllocator::RegionSet::RegionSet):
        (RegionSet):
        (JSC::BlockAllocator::tryAllocateFromRegion): We change this function so that it correctly 
        moves blocks between empty, partial, and full lists.
        (JSC::BlockAllocator::allocate):
        (JSC::BlockAllocator::allocateCustomSize):
        (JSC::BlockAllocator::deallocate): Ditto.
        (JSC::CopiedBlock):
        (JSC::MarkedBlock):
        (JSC::BlockAllocator::regionSetFor): We use this so that we can use the same allocate/deallocate
        functions with different RegionSets. We specialize the function for each type of block that we 
        want to allocate.
        * heap/CopiedBlock.h:
        (CopiedBlock):
        * heap/CopiedSpace.h:
        (CopiedSpace):
        * heap/HeapBlock.h:
        (HeapBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock): For oversize MarkedBlocks, if the block size gets too big we can 
        underflow the endAtom, which will cause us to segfault when we try to sweep a block. If we're a 
        custom size MarkedBlock we need to calculate endAtom so it doesn't underflow.

2012-10-14  Filip Pizlo  <fpizlo@apple.com>

        JIT::JIT fails to initialize all of its fields
        https://bugs.webkit.org/show_bug.cgi?id=99283

        Reviewed by Andreas Kling.

        There were two groups of such fields, all of which are eventually initialized
        prior to use inside of privateCompile(). But it's safer to make sure that they
        are initialized in the constructor as well, since we may use the JIT to do a
        stub compile without calling into privateCompile().
        
        Unsigned index fields for dynamic repatching meta-data: this change
        initializes them to UINT_MAX, so we should crash if we try to use those
        indices without initializing them.
        
        Boolean flags for value profiling: this change initializes them to false, so
        we at worst turn off value profiling.

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

2012-10-15  Mark Hahnenberg  <mhahnenberg@apple.com>

        We should avoid weakCompareAndSwap when parallel GC is disabled
        https://bugs.webkit.org/show_bug.cgi?id=99331

        Reviewed by Filip Pizlo.

        CopiedBlock::reportLiveBytes and didEvacuateBytes uses weakCompareAndSwap, which some platforms 
        don't support. For platforms that don't have parallel GC enabled, we should just use a normal store.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::reportLiveBytes):
        (JSC::CopiedBlock::didEvacuateBytes):

2012-10-15  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing header file.

2012-10-14  Filip Pizlo  <fpizlo@apple.com>

        DFG should handle polymorphic array modes by eagerly transforming arrays into the most general applicable form
        https://bugs.webkit.org/show_bug.cgi?id=99269

        Reviewed by Geoffrey Garen.

        This kills off a bunch of code for "polymorphic" array modes in the DFG. It should
        also be a performance win for code that uses a lot of array storage arrays.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::modeUsesButterfly):
        (JSC::DFG::modeIsJSArray):
        (JSC::DFG::mayStoreToTail):
        (JSC::DFG::mayStoreToHole):
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::modeSupportsLength):
        (JSC::DFG::benefitsFromStructureCheck):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-14  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(126886): Fat binary builds don't know how to handle architecture variants to which the LLInt is agnostic
        https://bugs.webkit.org/show_bug.cgi?id=99270

        Reviewed by Geoffrey Garen.

        The fix is to hash cons the offsets based on configuration index, not the offsets
        themselves.

        * offlineasm/offsets.rb:

2012-10-13  Filip Pizlo  <fpizlo@apple.com>

        IndexingType should not have a bit for each type
        https://bugs.webkit.org/show_bug.cgi?id=98997

        Reviewed by Oliver Hunt.

        Somewhat incidentally, the introduction of butterflies led to each indexing
        type being represented by a unique bit. This is superficially nice since it
        allows you to test if a structure corresponds to a particular indexing type
        by saying !!(structure->indexingType() & TheType). But the downside is that
        given the 8 bits we have for the m_indexingType field, that leaves only a
        small number of possible indexing types if we have one per bit.
        
        This changeset changes the indexing type to be:
        
        Bit #1: Tells you if you're an array.
        
        Bits #2 - #5: 16 possible indexing types, including the blank type for
            objects that don't have indexed properties.
        
        Bits #6-8: Auxiliary bits that we could use for other things. Currently we
            just use one of those bits, for MayHaveIndexedAccessors.
        
        This is performance-neutral, and is primarily intended to give us more
        breathing room for introducing new inferred array modes.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::jumps):
        * assembler/MacroAssembler.h:
        (MacroAssembler):
        (JSC::MacroAssembler::patchableBranch32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::patchableBranch32):
        (MacroAssemblerARMv7):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::modeAlreadyChecked):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculationCheck):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (DFG):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateJSArray):
        (JSC::JIT::chooseArrayMode):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/IndexingType.h:
        (JSC):
        (JSC::hasIndexedProperties):
        (JSC::hasContiguous):
        (JSC::hasFastArrayStorage):
        (JSC::hasArrayStorage):
        (JSC::shouldUseSlowPut):
        * runtime/JSGlobalObject.cpp:
        (JSC):
        * runtime/StructureTransitionTable.h:
        (JSC::newIndexingType):

2012-10-14  Filip Pizlo  <fpizlo@apple.com>

        DFG structure check hoisting should attempt to ignore side effects and make transformations that are sound even in their presence
        https://bugs.webkit.org/show_bug.cgi?id=99262

        Reviewed by Oliver Hunt.

        This hugely simplifies the structure check hoisting phase. It will no longer be necessary
        to modify it when the effectfulness of operations changes. This also enables the hoister
        to hoist effectful things in the future.
        
        The downside is that the hoister may end up adding strictly more checks than were present
        in the original code, if the code truly has a lot of side-effects. I don't see evidence
        of this happening. This patch does have some speed-ups and some slow-downs, but is
        neutral in the average, and the slow-downs do not appear to have more structure checks
        than ToT.

        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (StructureCheckHoistingPhase):
        (CheckData):
        (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData):

2012-10-14  Filip Pizlo  <fpizlo@apple.com>

        Fix the build of universal binary with ARMv7s of JavaScriptCore

        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:

2012-10-13  Filip Pizlo  <fpizlo@apple.com>

        Array length array profiling is broken in the baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=99258

        Reviewed by Oliver Hunt.

        The code generator for array length stubs calls into
        emitArrayProfilingSiteForBytecodeIndex(), which emits profiling only if
        canBeOptimized() returns true. But m_canBeOptimized is only initialized during
        full method compiles, so in a stub compile it may (or may not) be false, meaning
        that we may, or may not, get meaningful profiling info.
        
        This appeared to not affect too many programs since the LLInt has good array
        length array profiling.

        * jit/JIT.h:
        (JSC::JIT::compilePatchGetArrayLength):

2012-10-14  Patrick Gansterer  <paroga@webkit.org>

        Build fix for WinCE after r131089.

        WinCE does not support getenv().

        * runtime/Options.cpp:
        (JSC::overrideOptionWithHeuristic):

2012-10-12  Kangil Han  <kangil.han@samsung.com>

        Fix build error on DFGSpeculativeJIT32_64.cpp
        https://bugs.webkit.org/show_bug.cgi?id=99234

        Reviewed by Anders Carlsson.

        Seems BUG 98608 causes build error on 32bit machine so fix it.

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

2012-10-12  Filip Pizlo  <fpizlo@apple.com>

        Contiguous array allocation should always be inlined
        https://bugs.webkit.org/show_bug.cgi?id=98608

        Reviewed by Oliver Hunt and Mark Hahnenberg.

        This inlines contiguous array allocation in the most obvious way possible.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::branchSubPtr):
        (MacroAssembler):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchSubPtr):
        (MacroAssemblerX86_64):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: Added.
        (DFG):
        (CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::generateInternal):
        (CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::generateInternal):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage):
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-12  Mark Hahnenberg  <mhahnenberg@apple.com>

        Race condition during CopyingPhase can lead to deadlock
        https://bugs.webkit.org/show_bug.cgi?id=99226

        Reviewed by Filip Pizlo.

        The main thread calls startCopying() for each of the GCThreads at the beginning of the copy phase. 
        It then proceeds to start copying. If copying completes before one of the GCThreads wakes up, the 
        main thread will set m_currentPhase back to NoPhase, the GCThread will wake up, see that there's 
        nothing to do, and then it will go back to sleep without ever calling CopyVisitor::doneCopying() 
        to return its borrowed block to the CopiedSpace. CopiedSpace::doneCopying() will then sleep forever 
        waiting on the block.

        The fix for this is to make sure we call CopiedSpace::doneCopying() on the main thread before we 
        call GCThreadSharedData::didFinishCopying(), which sets the m_currentPhase flag to NoPhase. This 
        way we will wait until all threads have woken up and given back their borrowed blocks before 
        clearing the flag.

        * heap/Heap.cpp:
        (JSC::Heap::copyBackingStores):

2012-10-12  Anders Carlsson  <andersca@apple.com>

        Move macros from Parser.h to Parser.cpp
        https://bugs.webkit.org/show_bug.cgi?id=99217

        Reviewed by Andreas Kling.

        There are a bunch of macros in Parser.h that are only used in Parser.cpp. Move them to Parser.cpp
        so they won't pollute the global namespace.
        * parser/Parser.cpp:
        * parser/Parser.h:
        (JSC):

2012-10-12  Mark Hahnenberg  <mhahnenberg@apple.com>

        Another build fix after r131213

        Added some symbol magic to placate the linker on some platforms.

        * JavaScriptCore.order:

2012-10-12  Mark Hahnenberg  <mhahnenberg@apple.com>

        Build fix after r131213

        Removed an unused variable that was making compilers unhappy.

        * heap/GCThread.cpp:
        (JSC::GCThread::GCThread):
        * heap/GCThread.h:
        (GCThread):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):

2012-10-09  Mark Hahnenberg  <mhahnenberg@apple.com>

        Copying collection shouldn't require O(live bytes) memory overhead
        https://bugs.webkit.org/show_bug.cgi?id=98792

        Reviewed by Filip Pizlo.

        Currently our copying collection occurs simultaneously with the marking phase. We'd like 
        to be able to reuse CopiedBlocks as soon as they become fully evacuated, but this is not 
        currently possible because we don't know the liveness statistics of each old CopiedBlock 
        until marking/copying has already finished. Instead, we have to allocate additional memory 
        from the OS to use as our working set of CopiedBlocks while copying. We then return the 
        fully evacuated old CopiedBlocks back to the block allocator, thus giving our copying phase 
        an O(live bytes) overhead.

        To fix this, we should instead split the copying phase apart from the marking phase. This 
        way we have full liveness data for each CopiedBlock during the copying phase so that we 
        can reuse them the instant they become fully evacuated. With the additional liveness data 
        that each CopiedBlock accumulates, we can add some additional heuristics to the collector. 
        For example, we can calculate our global Heap fragmentation and only choose to do a copying 
        phase if that fragmentation exceeds some limit. As another example, we can skip copying 
        blocks that are already above a particular fragmentation limit, which allows older objects 
        to coalesce into blocks that are rarely copied.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopiedBlock.h:
        (CopiedBlock):
        (JSC::CopiedBlock::CopiedBlock): Added support for tracking live bytes in a CopiedBlock in a 
        thread-safe fashion.
        (JSC::CopiedBlock::reportLiveBytes): Adds a number of live bytes to the block in a thread-safe 
        fashion using compare and swap.
        (JSC):
        (JSC::CopiedBlock::didSurviveGC): Called when a block survives a single GC without being 
        evacuated. This could be called for a couple reasons: (a) the block was pinned or (b) we 
        decided not to do any copying. A block can become pinned for a few reasons: (1) a pointer into 
        the block was found during the conservative scan. (2) the block was deemed full enough to 
        not warrant any copying. (3) The block is oversize and was found to be live. 
        (JSC::CopiedBlock::didEvacuateBytes): Called when some number of bytes are copied from this 
        block. If the number of live bytes ever hits zero, the block will return itself to the 
        BlockAllocator to be recycled.
        (JSC::CopiedBlock::canBeRecycled): Indicates that a block has no live bytes and can be 
        immediately recycled. This is used for blocks that are found to have zero live bytes at the 
        beginning of the copying phase.
        (JSC::CopiedBlock::shouldEvacuate): This function returns true if the current fragmentation 
        of the block is above our fragmentation threshold, and false otherwise.
        (JSC::CopiedBlock::isPinned): Added an accessor for the pinned flag
        (JSC::CopiedBlock::liveBytes): 
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::CopiedSpace):
        (JSC::CopiedSpace::doneFillingBlock): Changed so that we can exchange our filled block for a 
        fresh block. This avoids the situation where a thread returns its borrowed block, it's the last 
        borrowed block, so CopiedSpace thinks that copying has completed, and it starts doing all of the 
        copying phase cleanup. In actuality, the thread wanted another block after returning the current 
        block. So we allow the thread to atomically exchange its block for another block.
        (JSC::CopiedSpace::startedCopying): Added the calculation of global Heap fragmentation to 
        determine if the copying phase should commence. We include the MarkedSpace in our fragmentation 
        calculation by assuming that the MarkedSpace is 0% fragmented since we can reuse any currently 
        free memory in it (i.e. we ignore any internal fragmentation in the MarkedSpace). While we're 
        calculating the fragmentation of CopiedSpace, we also return any free blocks we find along the 
        way (meaning liveBytes() == 0).
        (JSC):
        (JSC::CopiedSpace::doneCopying): We still have to iterate over all the blocks, regardless of
        whether the copying phase took place or not so that we can reset all of the live bytes counters 
        and un-pin any pinned blocks.
        * heap/CopiedSpace.h:
        (CopiedSpace):
        (JSC::CopiedSpace::shouldDoCopyPhase):
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::recycleEvacuatedBlock): This function is distinct from recycling a borrowed block 
        because a borrowed block hasn't been added to the CopiedSpace yet, but an evacuated block is still
        currently in CopiedSpace, so we have to make sure we properly remove all traces of the block from 
        CopiedSpace before returning it to BlockAllocator.
        (JSC::CopiedSpace::recycleBorrowedBlock): Renamed to indicate the distinction mentioned above.
        * heap/CopyVisitor.cpp: Added.
        (JSC):
        (JSC::CopyVisitor::CopyVisitor):
        (JSC::CopyVisitor::copyFromShared): Main function for any thread participating in the copying phase.
        Grabs chunks of MarkedBlocks from the shared list and copies the backing store of anybody who needs
        it until there are no more chunks to copy.
        * heap/CopyVisitor.h: Added.
        (JSC):
        (CopyVisitor):
        * heap/CopyVisitorInlineMethods.h: Added.
        (JSC):
        (GCCopyPhaseFunctor):
        (JSC::GCCopyPhaseFunctor::GCCopyPhaseFunctor):
        (JSC::GCCopyPhaseFunctor::operator()):
        (JSC::CopyVisitor::checkIfShouldCopy): We don't have to check shouldEvacuate() because all of those 
        checks are done during the marking phase.
        (JSC::CopyVisitor::allocateNewSpace): 
        (JSC::CopyVisitor::allocateNewSpaceSlow):
        (JSC::CopyVisitor::startCopying): Initialization function for a thread that is about to start copying.
        (JSC::CopyVisitor::doneCopying):
        (JSC::CopyVisitor::didCopy): This callback is called by an object that has just successfully copied its
        backing store. It indicates to the CopiedBlock that somebody has just finished evacuating some number of 
        bytes from it, and, if the CopiedBlock now has no more live bytes, can be recycled immediately.
        * heap/GCThread.cpp: Added.
        (JSC):
        (JSC::GCThread::GCThread): This is a new class that encapsulates a single thread responsible for participating 
        in a specific set of GC phases. Currently, that set of phases includes Mark, Copy, and Exit. Each thread 
        monitors a shared variable in its associated GCThreadSharedData. The main thread updates this m_currentPhase
        variable as collection progresses through the various phases. Parallel marking still works exactly like it 
        has. In other words, the "run loop" for each of the GC threads sits above any individual phase, thus keeping 
        the separate phases of the collector orthogonal.
        (JSC::GCThread::threadID):
        (JSC::GCThread::initializeThreadID):
        (JSC::GCThread::slotVisitor):
        (JSC::GCThread::copyVisitor):
        (JSC::GCThread::waitForNextPhase):
        (JSC::GCThread::gcThreadMain):
        (JSC::GCThread::gcThreadStartFunc):
        * heap/GCThread.h: Added.
        (JSC):
        (GCThread):
        * heap/GCThreadSharedData.cpp: The GCThreadSharedData now has a list of GCThread objects rather than raw 
        ThreadIdentifiers.
        (JSC::GCThreadSharedData::resetChildren):
        (JSC::GCThreadSharedData::childVisitCount):
        (JSC::GCThreadSharedData::GCThreadSharedData):
        (JSC::GCThreadSharedData::~GCThreadSharedData):
        (JSC::GCThreadSharedData::reset):
        (JSC::GCThreadSharedData::didStartMarking): Callback to let the GCThreadSharedData know that marking has 
        started and updates the m_currentPhase variable and notifies the GCThreads accordingly.
        (JSC::GCThreadSharedData::didFinishMarking): Ditto for finishing marking. 
        (JSC::GCThreadSharedData::didStartCopying): Ditto for starting the copying phase.
        (JSC::GCThreadSharedData::didFinishCopying): Ditto for finishing copying. 
        * heap/GCThreadSharedData.h:
        (JSC):
        (GCThreadSharedData):
        (JSC::GCThreadSharedData::getNextBlocksToCopy): Atomically gets the next chunk of work for a copying thread.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markRoots):
        (JSC):
        (JSC::Heap::copyBackingStores): Responsible for setting up the copying phase, notifying the copying threads, 
        and doing any copying work if necessary.
        (JSC::Heap::collect):
        * heap/Heap.h:
        (Heap):
        (JSC):
        (JSC::CopyFunctor::CopyFunctor):
        (CopyFunctor):
        (JSC::CopyFunctor::operator()):
        * heap/IncrementalSweeper.cpp: Changed the incremental sweeper to have a reference to the list of MarkedBlocks 
        that need sweeping, since this now resides in the Heap so that it can be easily shared by the GCThreads.
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::startSweeping):
        * heap/IncrementalSweeper.h:
        (JSC):
        (IncrementalSweeper):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::setup):
        (JSC::SlotVisitor::drainFromShared): We no longer do any copying-related work here.
        (JSC):
        * heap/SlotVisitor.h:
        (SlotVisitor):
        * heap/SlotVisitorInlineMethods.h:
        (JSC):
        (JSC::SlotVisitor::copyLater): Notifies the CopiedBlock that there are some live bytes that may need 
        to be copied.
        * runtime/Butterfly.h:
        (JSC):
        (Butterfly):
        * runtime/ButterflyInlineMethods.h:
        (JSC::Butterfly::createUninitializedDuringCollection): Uses the new CopyVisitor.
        * runtime/ClassInfo.h:
        (MethodTable): Added new "virtual" function copyBackingStore to method table.
        (JSC):
        * runtime/JSCell.cpp:
        (JSC::JSCell::copyBackingStore): Default implementation that does nothing.
        (JSC):
        * runtime/JSCell.h:
        (JSC):
        (JSCell):
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly): Does the actual copying of the butterfly.
        (JSC):
        (JSC::JSObject::visitButterfly): Calls copyLater for the butterfly.
        (JSC::JSObject::copyBackingStore): 
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSCell::methodTable):
        (JSC::JSCell::inherits):
        * runtime/Options.h: Added two new constants, minHeapUtilization and minCopiedBlockUtilization, 
        to govern the amount of fragmentation we allow before doing copying.
        (JSC):

2012-10-12  Filip Pizlo  <fpizlo@apple.com>

        DFG array allocation calls should not return an encoded JSValue
        https://bugs.webkit.org/show_bug.cgi?id=99196

        Reviewed by Mark Hahnenberg.

        The array allocation operations now return a pointer instead. This makes it
        easier to share code between 32-bit and 64-bit.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-01  Jer Noble  <jer.noble@apple.com>

        Enable ENCRYPTED_MEDIA support on Mac.
        https://bugs.webkit.org/show_bug.cgi?id=98044

        Reviewed by Anders Carlsson.

        Enable the ENCRYPTED_MEDIA flag.

        * Configurations/FeatureDefines.xcconfig:

2012-10-12  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed. It should be possible to build JSC on ARMv7.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::patchableBranchPtr):

2012-10-11  Mark Hahnenberg  <mhahnenberg@apple.com>

        BlockAllocator should use regions as its VM allocation abstraction
        https://bugs.webkit.org/show_bug.cgi?id=99107

        Reviewed by Geoffrey Garen.

        Currently the BlockAllocator allocates a single block at a time directly from the OS. Our block 
        allocations are on the large-ish side (64 KB) to amortize across many allocations the expense of 
        mapping new virtual memory from the OS. These large blocks are then shared between the MarkedSpace 
        and the CopiedSpace. This design makes it difficult to vary the size of the blocks in different 
        parts of the Heap while still allowing us to amortize the VM allocation costs.

        We should redesign the BlockAllocator so that it has a layer of indirection between blocks that are 
        used by the allocator/collector and our primary unit of VM allocation from the OS. In particular, 
        the BlockAllocator should allocate Regions of virtual memory from the OS, which are then subdivided 
        into one or more Blocks to be used in our custom allocators. This design has the following nice properties:

        1) We can remove the knowledge of PageAllocationAligned from HeapBlocks. Each HeapBlock will now 
           only know what Region it belongs to. The Region maintains all the metadata for how to allocate 
           and deallocate virtual memory from the OS.

        2) We can easily allocate in larger chunks than we need to satisfy a particular request for a Block. 
           We can then continue to amortize our VM allocation costs while allowing for smaller block sizes, 
           which should increase locality in the mutator when allocating, lazy sweeping, etc.

        3) By encapsulating the logic of where our memory comes from inside of the Region class, we can more 
           easily transition over to allocating VM from a specific range of pre-reserved address space. This 
           will be a necessary step along the way to 32-bit pointers.

        This particular patch will not change the size of MarkedBlocks or CopiedBlocks, nor will it change how 
        much VM we allocate per failed Block request. It only sets up the data structures that we need to make 
        these changes in future patches.

        Most of the changes in this patch relate to the addition of the Region class to be used by the 
        BlockAllocator and the threading of changes made to BlockAllocator's interface through to the call sites.

        * heap/BlockAllocator.cpp: The BlockAllocator now has three lists that track the three disjoint sets of
        Regions that it cares about: empty regions, partially full regions, and completely full regions. 
        Empty regions have no blocks currently in use and can be freed immediately if the freeing thread 
        determines they should be. Partial regions have some blocks used, but aren't completely in use yet. 
        These regions are preferred for recycling before empty regions to mitigate fragmentation within regions.
        Completely full regions are no longer able to be used for allocations. Regions move between these 
        three lists as they are created and their constituent blocks are allocated and deallocated.
        (JSC::BlockAllocator::BlockAllocator):
        (JSC::BlockAllocator::~BlockAllocator):
        (JSC::BlockAllocator::releaseFreeRegions):
        (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock):
        (JSC::BlockAllocator::waitForRelativeTime):
        (JSC::BlockAllocator::blockFreeingThreadMain):
        * heap/BlockAllocator.h:
        (JSC):
        (DeadBlock):
        (JSC::DeadBlock::DeadBlock):
        (Region):
        (JSC::Region::blockSize):
        (JSC::Region::isFull):
        (JSC::Region::isEmpty):
        (JSC::Region::create): This function is responsible for doing the actual VM allocation. This should be the 
        only function in the entire JSC object runtime that calls out the OS for virtual memory allocation.
        (JSC::Region::Region):
        (JSC::Region::~Region):
        (JSC::Region::allocate):
        (JSC::Region::deallocate):
        (BlockAllocator):
        (JSC::BlockAllocator::tryAllocateFromRegion): Helper function that encapsulates checking a particular list 
        of regions for a free block.
        (JSC::BlockAllocator::allocate):
        (JSC::BlockAllocator::allocateCustomSize): This function is responsible for allocating one-off custom size 
        regions for use in oversize allocations in both the MarkedSpace and the CopiedSpace. These regions are not 
        tracked by the BlockAllocator. The only pointer to them is in the HeapBlock that is returned. These regions 
        contain exactly one block.
        (JSC::BlockAllocator::deallocate):
        (JSC::BlockAllocator::deallocateCustomSize): This function is responsible for deallocating one-off custom size
        regions. The regions are deallocated back to the OS eagerly.
        * heap/CopiedBlock.h: Re-worked CopiedBlocks to use Regions instead of PageAllocationAligned.
        (CopiedBlock):
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::payloadEnd):
        (JSC::CopiedBlock::capacity):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        (JSC::CopiedSpace::doneCopying):
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::allocateBlockForCopyingPhase):
        (JSC::CopiedSpace::allocateBlock):
        * heap/HeapBlock.h:
        (JSC::HeapBlock::destroy):
        (JSC::HeapBlock::HeapBlock):
        (JSC::HeapBlock::region):
        (HeapBlock):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::capacity):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::freeBlock):

2012-10-11  Filip Pizlo  <fpizlo@apple.com>

        UInt32ToNumber and OSR exit should be aware of copy propagation and correctly recover both versions of a variable that was subject to a UInt32ToNumber cast
        https://bugs.webkit.org/show_bug.cgi?id=99100
        <rdar://problem/12480955>

        Reviewed by Michael Saboff and Mark Hahnenberg.

        Fixed by forcing UInt32ToNumber to use a different register. This "undoes" the copy propagation that we
        would have been doing, since it has no performance effect in this case and has the benefit of making the
        OSR exit compiler a lot simpler.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):

2012-10-11  Geoffrey Garen  <ggaren@apple.com>

        Removed some more static assumptions about inline object capacity
        https://bugs.webkit.org/show_bug.cgi?id=98603

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Use JSObject::allocationSize()
        for a little more flexibility. We still pass it a constant inline capacity
        because the JIT doesn't have a strategy for selecting a size class based
        on non-constant capacity yet. "INLINE_STORAGE_CAPACITY" is a marker for
        code that makes static assumptions about object size.

        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm: Ditto for the rest of our many execution engines.

        * runtime/JSObject.h:
        (JSC::JSObject::allocationSize):
        (JSC::JSFinalObject::finishCreation):
        (JSC::JSFinalObject::create): New helper function for computing object
        size dynamically, since we plan to have objects of different sizes.

        (JSC::JSFinalObject::JSFinalObject): Note that our m_inlineStorage used
        to auto-generate an implicit C++ constructor with default null initialization.
        This memory is not observed in its uninitialized state, and our LLInt and
        JIT allocators do not initialize it, so I did not add any explicit code
        to do so, now that the implicit code is gone.

        (JSC::JSObject::offsetOfInlineStorage): Changed the math here to match
        inlineStorageUnsafe(), since we can rely on an explicit data member anymore.

2012-10-11  Geoffrey Garen  <ggaren@apple.com>

        Enable RUNTIME_HEURISTICS all the time, for easier testing
        https://bugs.webkit.org/show_bug.cgi?id=99090

        Reviewed by Filip Pizlo.

        I find myself using this a lot, and there doesn't seem to be an obvious
        reason to compile it out, since it only runs once at startup.

        * runtime/Options.cpp:
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::initialize):
        * runtime/Options.h: Removed the #ifdef.

2012-10-11  Geoffrey Garen  <ggaren@apple.com>

        Removed ASSERT_CLASS_FITS_IN_CELL
        https://bugs.webkit.org/show_bug.cgi?id=97634

        Reviewed by Mark Hahnenberg.

        Our collector now supports arbitrarily sized objects, so the ASSERT is not needed.

        * API/JSCallbackFunction.cpp:
        * API/JSCallbackObject.cpp:
        * heap/MarkedSpace.h:
        * jsc.cpp:
        * runtime/Arguments.cpp:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayPrototype.cpp:
        * runtime/BooleanConstructor.cpp:
        * runtime/BooleanObject.cpp:
        * runtime/BooleanPrototype.cpp:
        * runtime/DateConstructor.cpp:
        * runtime/DatePrototype.cpp:
        * runtime/Error.cpp:
        * runtime/ErrorConstructor.cpp:
        * runtime/ErrorPrototype.cpp:
        * runtime/FunctionConstructor.cpp:
        * runtime/FunctionPrototype.cpp:
        * runtime/InternalFunction.cpp:
        * runtime/JSActivation.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSBoundFunction.cpp:
        * runtime/JSFunction.cpp:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalThis.cpp:
        * runtime/JSNameScope.cpp:
        * runtime/JSNotAnObject.cpp:
        * runtime/JSONObject.cpp:
        * runtime/JSObject.cpp:
        * runtime/JSPropertyNameIterator.cpp:
        * runtime/JSScope.cpp:
        * runtime/JSWithScope.cpp:
        * runtime/JSWrapperObject.cpp:
        * runtime/MathObject.cpp:
        * runtime/NameConstructor.cpp:
        * runtime/NamePrototype.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NativeErrorPrototype.cpp:
        * runtime/NumberConstructor.cpp:
        * runtime/NumberObject.cpp:
        * runtime/NumberPrototype.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectPrototype.cpp:
        * runtime/RegExpConstructor.cpp:
        * runtime/RegExpMatchesArray.cpp:
        * runtime/RegExpObject.cpp:
        * runtime/RegExpPrototype.cpp:
        * runtime/StringConstructor.cpp:
        * runtime/StringObject.cpp:
        * runtime/StringPrototype.cpp:
        * testRegExp.cpp: Removed the ASSERT.

2012-10-11  Filip Pizlo  <fpizlo@apple.com>

        DFG should inline code blocks that use new_array_buffer
        https://bugs.webkit.org/show_bug.cgi?id=98996

        Reviewed by Geoffrey Garen.

        This adds plumbing to drop in constant buffers from the inlinees to the inliner.
        It's smart about not duplicating buffers needlessly but doesn't try to completely
        hash-cons them, either.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfConstantBuffers):
        (JSC::CodeBlock::addConstantBuffer):
        (JSC::CodeBlock::constantBufferAsVector):
        (JSC::CodeBlock::constantBuffer):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (ConstantBufferKey):
        (JSC::DFG::ConstantBufferKey::ConstantBufferKey):
        (JSC::DFG::ConstantBufferKey::operator==):
        (JSC::DFG::ConstantBufferKey::hash):
        (JSC::DFG::ConstantBufferKey::isHashTableDeletedValue):
        (JSC::DFG::ConstantBufferKey::codeBlock):
        (JSC::DFG::ConstantBufferKey::index):
        (DFG):
        (JSC::DFG::ConstantBufferKeyHash::hash):
        (JSC::DFG::ConstantBufferKeyHash::equal):
        (ConstantBufferKeyHash):
        (WTF):
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-10-10  Zoltan Horvath  <zoltan@webkit.org>

        Pageload tests should measure memory usage
        https://bugs.webkit.org/show_bug.cgi?id=93958

        Reviewed by Ryosuke Niwa.

        Add JS Heap and Heap memory measurement to PageLoad tests.

        * heap/HeapStatistics.cpp:
        (JSC::HeapStatistics::usedJSHeap): Add new private function to expose the used JS Heap size.
        (JSC):
        * heap/HeapStatistics.h:
        (HeapStatistics): Add new private function to expose the used JS Heap size.

2012-10-10  Balazs Kilvady  <kilvadyb@homejinni.com>

        RegisterFile to JSStack rename fix for a struct member.

        Compilation problem in debug build on MIPS
        https://bugs.webkit.org/show_bug.cgi?id=98808

        Reviewed by Alexey Proskuryakov.

        In ASSERT conditions structure field name "registerFile" was replaced
        with type name "JSStack" and it should be "stack".

        * jit/JITStubs.cpp:
        (JSC::JITThunks::JITThunks): structure member name fix.

2012-10-10  Michael Saboff  <msaboff@apple.com>

        After r130344, OpaqueJSString::string() shouldn't directly return the wrapped String
        https://bugs.webkit.org/show_bug.cgi?id=98801

        Reviewed by Geoffrey Garen.

        Return a copy of the wrapped String so that the wrapped string cannot be turned into 
        an Identifier.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::string):
        * API/OpaqueJSString.h:
        (OpaqueJSString):

2012-10-10  Peter Gal  <galpeter@inf.u-szeged.hu>

        Add moveDoubleToInts and moveIntsToDouble to MacroAssemblerARM
        https://bugs.webkit.org/show_bug.cgi?id=98855

        Reviewed by Filip Pizlo.

        Implement the missing moveDoubleToInts and moveIntsToDouble
        methods in the MacroAssemblerARM after r130839.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::moveDoubleToInts):
        (MacroAssemblerARM):
        (JSC::MacroAssemblerARM::moveIntsToDouble):

2012-10-09  Filip Pizlo  <fpizlo@apple.com>

        Typed arrays should not be 20x slower in the baseline JIT than in the DFG JIT
        https://bugs.webkit.org/show_bug.cgi?id=98605

        Reviewed by Oliver Hunt and Gavin Barraclough.

        This adds typed array get_by_val/put_by_val patching to the baseline JIT. It's
        a big (~40%) win on benchmarks that have trouble staying in the DFG JIT. Even
        if we fix those benchmarks, this functionality gives us the insurance that we
        typically desire with all speculative optimizations: even if we bail to
        baseline, we're still reasonably performant.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/MacroAssembler.cpp: Added.
        (JSC):
        * assembler/MacroAssembler.h:
        (MacroAssembler):
        (JSC::MacroAssembler::patchableBranchPtr):
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::moveDoubleToInts):
        (JSC::MacroAssemblerARMv7::moveIntsToDouble):
        (JSC::MacroAssemblerARMv7::patchableBranchPtr):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::moveDoubleToInts):
        (JSC::MacroAssemblerX86::moveIntsToDouble):
        * bytecode/ByValInfo.h:
        (JSC::hasOptimizableIndexingForClassInfo):
        (JSC):
        (JSC::hasOptimizableIndexing):
        (JSC::jitArrayModeForClassInfo):
        (JSC::jitArrayModeForStructure):
        (JSC::ByValInfo::ByValInfo):
        (ByValInfo):
        * dfg/DFGAssemblyHelpers.cpp:
        (DFG):
        * dfg/DFGAssemblyHelpers.h:
        (AssemblyHelpers):
        (JSC::DFG::AssemblyHelpers::boxDouble):
        (JSC::DFG::AssemblyHelpers::unboxDouble):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * jit/JIT.h:
        (JIT):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompilePutByVal):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/JSCell.h:
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        (JSC::JSGlobalData::typedArrayDescriptor):
        * runtime/TypedArrayDescriptor.h: Added.
        (JSC):
        (JSC::TypedArrayDescriptor::TypedArrayDescriptor):
        (TypedArrayDescriptor):

2012-10-09  Michael Saboff  <msaboff@apple.com>

        Add tests to testapi for null OpaqueJSStrings
        https://bugs.webkit.org/show_bug.cgi?id=98805

        Reviewed by Geoffrey Garen.

        Added tests that check that OpaqueJSString, which is wrapped via JSStringRef, properly returns
        null strings and that a null string in a JSStringRef will return a NULL JSChar* and 0 length
        via the JSStringGetCharactersPtr() and JSStringGetLength() APIs respectively. Added a check that 
        JSValueMakeFromJSONString() properly handles a null string as well.

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

2012-10-09  Jian Li  <jianli@chromium.org>

        Update the CSS property used to support draggable regions.
        https://bugs.webkit.org/show_bug.cgi?id=97156

        Reviewed by Adam Barth.

        The CSS property to support draggable regions, guarded under
        WIDGET_REGION is now disabled from Mac WebKit, in order not to cause
        confusion with DASHBOARD_SUPPORT feature.

        * Configurations/FeatureDefines.xcconfig: Disable WIDGET_REGION feature.

2012-10-09  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, adding forgotten files.

        * bytecode/ByValInfo.h: Added.
        (JSC):
        (JSC::isOptimizableIndexingType):
        (JSC::jitArrayModeForIndexingType):
        (JSC::ByValInfo::ByValInfo):
        (ByValInfo):
        (JSC::getByValInfoBytecodeIndex):
        * runtime/IndexingType.cpp: Added.
        (JSC):
        (JSC::indexingTypeToString):

2012-10-08  Filip Pizlo  <fpizlo@apple.com>

        JSC should infer when indexed storage is contiguous, and optimize for it
        https://bugs.webkit.org/show_bug.cgi?id=97288

        Reviewed by Mark Hahnenberg.

        This introduces a new kind of indexed property storage called Contiguous,
        which has the following properties:
        
        - No header bits beyond IndexedHeader. This results in a 16 byte reduction
          in memory usage per array versus an ArrayStorage array. It also means
          that the total memory usage for an empty array is now just 3 * 8 on both
          32-bit and 64-bit. Of that, only 8 bytes are array-specific; the rest is
          our standard object header overhead.
        
        - No need for hole checks on store. This results in a ~4% speed-up on
          Kraken and a ~1% speed-up on V8v7.
        
        - publicLength <= vectorLength. This means that doing new Array(blah)
          immediately allocates room for blah elements.
        
        - No sparse map or index bias.
        
        If you ever do things to an array that would require publicLength >
        vectorLength, a sparse map, or index bias, then we switch to ArrayStorage
        mode. This seems to never happen in any benchmark we track, and is unlikely
        to happen very frequently on any website.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::JumpList::append):
        * assembler/MacroAssembler.h:
        (MacroAssembler):
        (JSC::MacroAssembler::patchableBranchTest32):
        * bytecode/ByValInfo.h: Added.
        (JSC):
        (JSC::isOptimizableIndexingType):
        (JSC::jitArrayModeForIndexingType):
        (JSC::ByValInfo::ByValInfo):
        (ByValInfo):
        (JSC::getByValInfoBytecodeIndex):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::getByValInfo):
        (JSC::CodeBlock::setNumberOfByValInfos):
        (JSC::CodeBlock::numberOfByValInfos):
        (JSC::CodeBlock::byValInfo):
        * bytecode/SamplingTool.h:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::modeUsesButterfly):
        (JSC::DFG::modeIsJSArray):
        (JSC::DFG::isInBoundsAccess):
        (JSC::DFG::mayStoreToTail):
        (JSC::DFG::mayStoreToHole):
        (JSC::DFG::modeIsPolymorphic):
        (JSC::DFG::polymorphicIncludesContiguous):
        (JSC::DFG::polymorphicIncludesArrayStorage):
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::modeSupportsLength):
        (JSC::DFG::benefitsFromStructureCheck):
        (JSC::DFG::isEffectful):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getArrayLengthElimination):
        (JSC::DFG::CSEPhase::getByValLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
        (DFG):
        * dfg/DFGSpeculativeJIT.h:
        (DFG):
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister):
        (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal):
        (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
        (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal):
        (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
        (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal):
        (JSC::DFG::SpeculativeJIT::compile):
        * interpreter/Interpreter.cpp:
        (SamplingScope):
        (JSC::SamplingScope::SamplingScope):
        (JSC::SamplingScope::~SamplingScope):
        (JSC):
        (JSC::Interpreter::execute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::ByValCompilationInfo::ByValCompilationInfo):
        (ByValCompilationInfo):
        (JSC):
        (JIT):
        (JSC::JIT::compileGetByVal):
        (JSC::JIT::compilePutByVal):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateJSArray):
        (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase):
        (JSC):
        (JSC::arrayProfileSaw):
        (JSC::JIT::chooseArrayMode):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emitSlow_op_new_array):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompilePutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitSlow_op_put_by_val):
        * jit/JITStubs.cpp:
        (JSC::getByVal):
        (JSC):
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::putByVal):
        * jit/JITStubs.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConventions.h:
        (JSC::isDenseEnoughForVector):
        * runtime/ArrayPrototype.cpp:
        (JSC):
        (JSC::shift):
        (JSC::unshift):
        (JSC::arrayProtoFuncPush):
        (JSC::arrayProtoFuncShift):
        (JSC::arrayProtoFuncSplice):
        (JSC::arrayProtoFuncUnShift):
        * runtime/Butterfly.h:
        (Butterfly):
        (JSC::Butterfly::fromPointer):
        (JSC::Butterfly::pointer):
        (JSC::Butterfly::publicLength):
        (JSC::Butterfly::vectorLength):
        (JSC::Butterfly::setPublicLength):
        (JSC::Butterfly::setVectorLength):
        (JSC::Butterfly::contiguous):
        (JSC::Butterfly::fromContiguous):
        * runtime/ButterflyInlineMethods.h:
        (JSC::Butterfly::unshift):
        (JSC::Butterfly::shift):
        * runtime/IndexingHeaderInlineMethods.h:
        (JSC::IndexingHeader::indexingPayloadSizeInBytes):
        * runtime/IndexingType.cpp: Added.
        (JSC):
        (JSC::indexingTypeToString):
        * runtime/IndexingType.h:
        (JSC):
        (JSC::hasContiguous):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::setLength):
        (JSC):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithArrayStorage):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::sortNumericVector):
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sortCompactedVector):
        (JSC::JSArray::sort):
        (JSC::JSArray::sortVector):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSC::JSArray::shiftCountForShift):
        (JSC::JSArray::shiftCountForSplice):
        (JSArray):
        (JSC::JSArray::shiftCount):
        (JSC::JSArray::unshiftCountForShift):
        (JSC::JSArray::unshiftCountForSplice):
        (JSC::JSArray::unshiftCount):
        (JSC::JSArray::isLengthWritable):
        (JSC::createContiguousArrayButterfly):
        (JSC):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        (JSC::JSGlobalObject::haveABadTime):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::arrayStructureWithArrayStorage):
        (JSC::JSGlobalObject::addressOfArrayStructureWithArrayStorage):
        (JSC::constructEmptyArray):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::createInitialContiguous):
        (JSC):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC::JSObject::ensureIndexedStorageSlow):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthContiguousWithoutAttributes):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::countElementsInContiguous):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureContiguousLengthSlow):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (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):
        (JSObject):
        (JSC::JSObject::ensureContiguous):
        (JSC::JSObject::ensureIndexedStorage):
        (JSC::JSObject::ensureContiguousLength):
        (JSC::JSObject::indexingData):
        (JSC::JSObject::relevantLength):
        * runtime/JSValue.cpp:
        (JSC::JSValue::description):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Structure.cpp:
        (JSC::Structure::needsSlowPutIndexing):
        (JSC):
        (JSC::Structure::suggestedArrayStorageTransition):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureTransitionTable.h:
        (JSC::newIndexingType):

2012-10-09  Michael Saboff  <msaboff@apple.com>

        After r130344, OpaqueJSString::identifier() adds wrapped String to identifier table
        https://bugs.webkit.org/show_bug.cgi?id=98693
        REGRESSION (r130344): Install failed in Install Environment
        <rdar://problem/12450118>

        Reviewed by Mark Rowe.

        Use Identifier(LChar*, length) or Identifier(UChar*, length) constructors so that we don't
        add the String instance in the OpaqueJSString to any identifier tables.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::identifier):

2012-10-08  Mark Lam  <mark.lam@apple.com>

        Renamed RegisterFile to JSStack, and removed prototype of the
        previously deleted Interpreter::privateExecute().
        https://bugs.webkit.org/show_bug.cgi?id=98717.

        Reviewed by Filip Pizlo.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.order:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/BytecodeConventions.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::alreadyInJSStack):
        (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt32):
        (JSC::ValueRecovery::alreadyInJSStackAsUnboxedCell):
        (JSC::ValueRecovery::alreadyInJSStackAsUnboxedBoolean):
        (JSC::ValueRecovery::alreadyInJSStackAsUnboxedDouble):
        (JSC::ValueRecovery::displacedInJSStack):
        (JSC::ValueRecovery::isAlreadyInJSStack):
        (JSC::ValueRecovery::virtualRegister):
        (JSC::ValueRecovery::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::resolveCallee):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::registerFor):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
        (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::DFG::AssemblyHelpers::emitPutImmediateToCallFrameHeader):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getDirect):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGGenerationInfo.h:
        (GenerationInfo):
        (JSC::DFG::GenerationInfo::needsSpill):
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::beginCall):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryBuildGetByIDList):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::spill):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInteger):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::throwExceptionFromCallSlowPathGenerator):
        (JSC::DFG::slowPathFor):
        (JSC::DFG::virtualForThunkGenerator):
        * dfg/DFGValueSource.cpp:
        (JSC::DFG::ValueSource::dump):
        * dfg/DFGValueSource.h:
        (JSC::DFG::dataFormatToValueSourceKind):
        (JSC::DFG::valueSourceKindToDataFormat):
        (JSC::DFG::isInJSStack):
        (JSC::DFG::ValueSource::forSpeculation):
        (JSC::DFG::ValueSource::isInJSStack):
        (JSC::DFG::ValueSource::valueRecovery):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * heap/Heap.cpp:
        (JSC::Heap::stack):
        (JSC::Heap::getConservativeRegisterRoots):
        (JSC::Heap::markRoots):
        * heap/Heap.h:
        (JSC):
        (Heap):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::stack):
        * interpreter/CallFrame.h:
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::scope):
        (JSC::ExecState::callerFrame):
        (JSC::ExecState::returnPC):
        (JSC::ExecState::hasReturnPC):
        (JSC::ExecState::clearReturnPC):
        (JSC::ExecState::bytecodeOffsetForNonDFGCode):
        (JSC::ExecState::setBytecodeOffsetForNonDFGCode):
        (JSC::ExecState::inlineCallFrame):
        (JSC::ExecState::codeOriginIndexForDFG):
        (JSC::ExecState::currentVPC):
        (JSC::ExecState::setCurrentVPC):
        (JSC::ExecState::setCallerFrame):
        (JSC::ExecState::setScope):
        (JSC::ExecState::init):
        (JSC::ExecState::argumentCountIncludingThis):
        (JSC::ExecState::offsetFor):
        (JSC::ExecState::setArgumentCountIncludingThis):
        (JSC::ExecState::setCallee):
        (JSC::ExecState::setCodeBlock):
        (JSC::ExecState::setReturnPC):
        (JSC::ExecState::setInlineCallFrame):
        (ExecState):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::slideRegisterWindowForCall):
        (JSC::eval):
        (JSC::loadVarargs):
        (JSC::Interpreter::dumpRegisters):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::endRepeatCall):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::stack):
        (Interpreter):
        (JSC::Interpreter::execute):
        (JSC):
        * interpreter/JSStack.cpp: Copied from Source/JavaScriptCore/interpreter/RegisterFile.cpp.
        (JSC::stackStatisticsMutex):
        (JSC::JSStack::~JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::gatherConservativeRoots):
        (JSC::JSStack::releaseExcessCapacity):
        (JSC::JSStack::initializeThreading):
        (JSC::JSStack::committedByteCount):
        (JSC::JSStack::addToCommittedByteCount):
        * interpreter/JSStack.h: Copied from Source/JavaScriptCore/interpreter/RegisterFile.h.
        (JSStack):
        (JSC::JSStack::JSStack):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        * interpreter/RegisterFile.cpp: Removed.
        * interpreter/RegisterFile.h: Removed.
        * interpreter/VMInspector.cpp:
        (JSC::VMInspector::dumpFrame):
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC):
        (JIT):
        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_ret_object_or_this):
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITCode.h:
        (JSC):
        (JSC::JITCode::execute):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitPutToCallFrameHeader):
        (JSC::JIT::emitPutCellToCallFrameHeader):
        (JSC::JIT::emitPutIntToCallFrameHeader):
        (JSC::JIT::emitPutImmediateToCallFrameHeader):
        (JSC::JIT::emitGetFromCallFrameHeaderPtr):
        (JSC::JIT::emitGetFromCallFrameHeader32):
        (JSC::JIT::updateTopCallFrame):
        (JSC::JIT::unmap):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileCTIMachineTrampolines):
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_ret_object_or_this):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_get_arguments_length):
        (JSC::JIT::emit_op_get_argument_by_val):
        (JSC::JIT::emit_op_resolve_global_dynamic):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTIMachineTrampolines):
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_get_arguments_length):
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_scoped_var):
        (JSC::JIT::emit_op_put_scoped_var):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_scoped_var):
        (JSC::JIT::emit_op_put_scoped_var):
        * jit/JITStubs.cpp:
        (JSC::ctiTrampoline):
        (JSC::JITThunks::JITThunks):
        (JSC):
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:
        (JSC):
        (JITStackFrame):
        * jit/JSInterfaceJIT.h:
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::returnJSValue):
        (JSC::SpecializedThunkJIT::returnDouble):
        (JSC::SpecializedThunkJIT::returnInt32):
        (JSC::SpecializedThunkJIT::returnJSCell):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::genericCall):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOffForInlineCallFrame):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::visitChildren):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::globalExec):
        * runtime/JSGlobalObject.h:
        (JSC):
        (JSGlobalObject):
        * runtime/JSLock.cpp:
        (JSC):
        * runtime/JSVariableObject.h:
        (JSVariableObject):
        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):

2012-10-08  Kiran Muppala  <cmuppala@apple.com>

        Throttle DOM timers on hidden pages.
        https://bugs.webkit.org/show_bug.cgi?id=98474

        Reviewed by Maciej Stachowiak.

        Add HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define.

        * Configurations/FeatureDefines.xcconfig:

2012-10-08  Michael Saboff  <msaboff@apple.com>

        After r130344, OpaqueJSString() creates an empty string which should be a null string
        https://bugs.webkit.org/show_bug.cgi?id=98417

        Reviewed by Sam Weinig.

        Changed create() of a null string to return 0. This is the same behavior as before r130344.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::create):

2012-10-07  Caio Marcelo de Oliveira Filho  <caio.oliveira@openbossa.org>

        Rename first/second to key/value in HashMap iterators
        https://bugs.webkit.org/show_bug.cgi?id=82784

        Reviewed by Eric Seidel.

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnNonIndexPropertyNames):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::~OpaqueJSClass):
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        (OpaqueJSClass::contextData):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::EvalCodeCache::visitAggregate):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/JumpTable.h:
        (JSC::StringJumpTable::offsetForValue):
        (JSC::StringJumpTable::ctiForValue):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::LazyOperandValueProfileParser::getIfPresent):
        * bytecode/SamplingTool.cpp:
        (JSC::SamplingTool::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::addConstant):
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        (JSC::BytecodeGenerator::emitLazyNewFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * debugger/Debugger.cpp:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        * dfg/DFGByteCodeCache.h:
        (JSC::DFG::ByteCodeCache::~ByteCodeCache):
        (JSC::DFG::ByteCodeCache::get):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstant):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::StructureCheckHoistingPhase::noticeClobber):
        * heap/Heap.cpp:
        (JSC::Heap::markProtectedObjects):
        * heap/Heap.h:
        (JSC::Heap::forEachProtectedCell):
        * heap/JITStubRoutineSet.cpp:
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::internalAppend):
        * heap/Weak.h:
        (JSC::weakRemove):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::ctiStub):
        * parser/Parser.cpp:
        (JSC::::parseStrictObjectLiteral):
        * profiler/Profile.cpp:
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintDataSampleStyle):
        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnNonIndexPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::invalidateCode):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayValueMap::visitChildren):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::clear):
        (JSC::WeakGCMap::set):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::sampleChild):
        (JSC::ProfileTreeNode::childCount):
        (JSC::ProfileTreeNode::dumpInternal):
        (JSC::ProfileTreeNode::compareEntries):

2012-10-05  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSC should have a way to gather and log Heap memory use and pause times
        https://bugs.webkit.org/show_bug.cgi?id=98431

        Reviewed by Geoffrey Garen.

        In order to improve our infrastructure for benchmark-driven development, we should 
        have a centralized method of gathering and logging various statistics about the state 
        of the JS heap. This would allow us to create and to use other tools to analyze the 
        output of the VM after running various workloads.

        The first two statistics that might be interesting is memory use by JSC and GC pause 
        times. We can control whether this recording happens through the use of the Options 
        class, allowing us to either use environment variables or command line flags.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::collect): If we finish a collection and are still over our set GC heap size, 
        we end the program immediately and report an error. Also added recording of pause times.
        * heap/Heap.h:
        (Heap):
        (JSC::Heap::shouldCollect): When we set a specific GC heap size through Options, we 
        ignore all other heuristics on when we should collect and instead only ask if we're 
        greater than the amount specified in the Option value. This allows us to view time/memory 
        tradeoffs more clearly.
        * heap/HeapStatistics.cpp: Added.
        (JSC):
        (JSC::HeapStatistics::initialize):
        (JSC::HeapStatistics::recordGCPauseTime):
        (JSC::HeapStatistics::logStatistics):
        (JSC::HeapStatistics::exitWithFailure):
        (JSC::HeapStatistics::reportSuccess):
        (JSC::HeapStatistics::parseMemoryAmount):
        (StorageStatistics):
        (JSC::StorageStatistics::StorageStatistics):
        (JSC::StorageStatistics::operator()):
        (JSC::StorageStatistics::objectWithOutOfLineStorageCount):
        (JSC::StorageStatistics::objectCount):
        (JSC::StorageStatistics::storageSize):
        (JSC::StorageStatistics::storageCapacity):
        (JSC::HeapStatistics::showObjectStatistics): Moved the old showHeapStatistics (renamed to showObjectStatistics) 
        to try to start collecting our various memory statistics gathering/reporting mechanisms scattered throughout the 
        codebase into one place.
        * heap/HeapStatistics.h: Added.
        (JSC):
        (HeapStatistics):
        * jsc.cpp:
        (main):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce): We need to initialize our data structures for recording 
        statistics if necessary.
        * runtime/Options.cpp: Add new Options for the various types of statistics we'll be gathering.
        (JSC::parse):
        (JSC):
        (JSC::Options::initialize): Initialize the various new options using environment variables.
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        (JSC):

2012-10-04  Rik Cabanier  <cabanier@adobe.com>

        Turn Compositing on by default in WebKit build
        https://bugs.webkit.org/show_bug.cgi?id=98315

        Reviewed by Simon Fraser.

        enable -webkit-blend-mode on trunk.

        * Configurations/FeatureDefines.xcconfig:

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

        Crash in Safari at com.apple.JavaScriptCore: WTF::StringImpl::is8Bit const + 12
        https://bugs.webkit.org/show_bug.cgi?id=98433

        Reviewed by Jessie Berlin.

        The problem is due to a String with a null StringImpl (i.e. a null string).
        Added a length check before the is8Bit() check since length() checks for a null StringImpl.  Changed the
        characters16() call to characters() since it can handle a null StringImpl as well.

        * API/JSValueRef.cpp:
        (JSValueMakeFromJSONString):

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

        Use copyLCharsFromUCharSource() for IdentifierLCharFromUCharTranslator translation
        https://bugs.webkit.org/show_bug.cgi?id=98335

        Reviewed by Michael Saboff.

        Michael Saboff added an optimized version of UChar->LChar conversion in r125846.
        Use this function in JSC::Identifier.

        * runtime/Identifier.cpp:
        (JSC::IdentifierLCharFromUCharTranslator::translate):

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

        After r130344, OpaqueJSString() creates a empty string which should be a null string
        https://bugs.webkit.org/show_bug.cgi?id=98417

        Reviewed by Alexey Proskuryakov.

        Removed the setting of enclosed string to an empty string from default constructor.
        Before changeset r130344, the semantic was the default constructor produced a null
        string.

        * API/OpaqueJSString.h:
        (OpaqueJSString::OpaqueJSString):

2012-10-04  Csaba Osztrogonác  <ossy@webkit.org>

        [Qt] Add missing LLInt dependencies to the build system
        https://bugs.webkit.org/show_bug.cgi?id=98394

        Reviewed by Geoffrey Garen.

        * DerivedSources.pri:
        * LLIntOffsetsExtractor.pro:

2012-10-03  Geoffrey Garen  <ggaren@apple.com>

        Next step toward fixing Windows: add new symbol.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-10-03  Geoffrey Garen  <ggaren@apple.com>

        First step toward fixing Windows: remove old symbol.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-10-03  Geoffrey Garen  <ggaren@apple.com>

        Removed the assumption that "final" objects have a fixed number of inline slots
        https://bugs.webkit.org/show_bug.cgi?id=98332

        Reviewed by Filip Pizlo.

        This is a step toward object size inference.

        I replaced the inline storage capacity constant with a data member per
        structure, set the the maximum supported value for the constant to 100,
        then fixed what broke. (Note that even though this patch increases the
        theoretical maximum inline capacity, it doesn't change any actual inline
        capacity.)

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::compileGetDirectOffset): These functions just get a rename:
        the constant they need is the first out of line offset along the offset
        number line, which is not necessarily the same thing (and is, in this
        patch, never the same thing) as the inline capacity of any given object.

        (JSC::JIT::emit_op_get_by_pname):
        * jit/JITPropertyAccess32_64.cpp: This function changes functionality,
        since it needs to convert from the abstract offset number line to an
        actual offset in memory, and it can't assume that inline and out-of-line
        offsets are contiguous on the number line.

        (JSC::JIT::compileGetDirectOffset): Updated for rename.

        (JSC::JIT::emit_op_get_by_pname): Same as emit_op_get_by_pname above.

        * llint/LowLevelInterpreter.asm: Updated to mirror changes in PropertyOffset.h,
        since we duplicate values from there.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm: Just like the JIT, most things are just
        renames, and get_by_pname changes to do more math. I also standardized
        offset calculations to use a hard-coded "-2", to match the JIT. This
        isn't really better, but it makes global search and replace easier,
        should we choose to refactor this code not to hard-code constants.

        I also renamed loadPropertyAtVariableOffsetKnownNotFinal to
        loadPropertyAtVariableOffsetKnownNotInline in order to sever the assumption
        that inline capacity is tied to object type, and I changed the 64bit LLInt
        to use this -- not using this previously seems to have been an oversight.

        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
        (JSC::JSFinalObject::visitChildren):
        * runtime/JSObject.h:
        (JSC::JSObject::offsetForLocation):
        (JSNonFinalObject):
        (JSC::JSFinalObject::createStructure):
        (JSFinalObject):
        (JSC::JSFinalObject::finishCreation): Updated for above changes.

        * runtime/JSPropertyNameIterator.h:
        (JSPropertyNameIterator):
        (JSC::JSPropertyNameIterator::finishCreation): Store the inline capacity
        of our object, since it's not a constant.

        (JSC::JSPropertyNameIterator::getOffset): Removed. This function was
        wrong. Luckily, it was also unused, since the C++ interpreter is gone.

        * runtime/PropertyMapHashTable.h:
        (PropertyTable): Use a helper function instead of hard-coding assumptions
        about object types.

        (JSC::PropertyTable::nextOffset):
        * runtime/PropertyOffset.h:
        (JSC):
        (JSC::checkOffset):
        (JSC::validateOffset):
        (JSC::isInlineOffset):
        (JSC::numberOfSlotsForLastOffset):
        (JSC::propertyOffsetFor): Refactored these functions to take inline capacity
        as an argument, since it's not fixed at compile time anymore.

        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::flattenDictionaryStructure):
        (JSC::Structure::putSpecificValue):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::outOfLineCapacity):
        (JSC::Structure::hasInlineStorage):
        (JSC::Structure::inlineCapacity):
        (JSC::Structure::inlineSize):
        (JSC::Structure::firstValidOffset):
        (JSC::Structure::lastValidOffset):
        (JSC::Structure::create): Removed some hard-coded assumptions about inline
        capacity and object type, and replaced with more liberal use of helper functions.

2012-10-03  Michael Saboff  <msaboff@apple.com>

        OpaqueJSString doesn't optimally handle 8 bit strings
        https://bugs.webkit.org/show_bug.cgi?id=98300

        Reviewed by Geoffrey Garen.

        Change OpaqueJSString to store and manage a String instead of a UChar buffer.
        The member string is a copy of any string used during creation.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::create):
        (OpaqueJSString::identifier):
        * API/OpaqueJSString.h:
        (OpaqueJSString::characters):
        (OpaqueJSString::length):
        (OpaqueJSString::string):
        (OpaqueJSString::OpaqueJSString):
        (OpaqueJSString):

2012-10-03  Filip Pizlo  <fpizlo@apple.com>

        Array.splice should be fast when it is used to remove elements other than the very first
        https://bugs.webkit.org/show_bug.cgi?id=98236

        Reviewed by Michael Saboff.

        Applied the same technique that was used to optimize the unshift case of splice in
        http://trac.webkit.org/changeset/129676.  This is a >20x speed-up on programs that
        use splice for element removal.

        * runtime/ArrayPrototype.cpp:
        (JSC::shift):
        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCount):
        * runtime/JSArray.h:
        (JSArray):

2012-09-16  Mark Hahnenberg  <mhahnenberg@apple.com>

        Delayed structure sweep can leak structures without bound
        https://bugs.webkit.org/show_bug.cgi?id=96546

        Reviewed by Geoffrey Garen.

        This patch gets rid of the separate Structure allocator in the MarkedSpace and adds two new destructor-only
        allocators. We now have separate allocators for our three types of objects: those objects with no destructors,
        those objects with destructors and with immortal structures, and those objects with destructors that don't have 
        immortal structures. All of the objects of the third type (destructors without immortal structures) now 
        inherit from a new class named JSDestructibleObject (which in turn is a subclass of JSNonFinalObject), which stores 
        the ClassInfo for these classes at a fixed offset for safe retrieval during sweeping/destruction.

        * API/JSCallbackConstructor.cpp: Use JSDestructibleObject for JSCallbackConstructor.
        (JSC):
        (JSC::JSCallbackConstructor::JSCallbackConstructor):
        * API/JSCallbackConstructor.h:
        (JSCallbackConstructor):
        * API/JSCallbackObject.cpp: Inherit from JSDestructibleObject for normal JSCallbackObjects and use a finalizer for 
        JSCallbackObject<JSGlobalObject>, since JSGlobalObject also uses a finalizer.
        (JSC):
        (JSC::::create): We need to move the create function for JSCallbackObject<JSGlobalObject> out of line so we can add 
        the finalizer for it. We don't want to add the finalizer is something like finishCreation in case somebody decides 
        to subclass this. We use this same technique for many other subclasses of JSGlobalObject.
        (JSC::::createStructure):
        * API/JSCallbackObject.h:
        (JSCallbackObject):
        (JSC):
        * API/JSClassRef.cpp: Change all the JSCallbackObject<JSNonFinalObject> to use JSDestructibleObject instead.
        (OpaqueJSClass::prototype):
        * API/JSObjectRef.cpp: Ditto.
        (JSObjectMake):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSValueRef.cpp: Ditto.
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp: Ditto.
        * JSCTypedArrayStubs.h:
        (JSC):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.h: Use the proper allocator type when doing inline allocation in the DFG.
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject):
        * heap/Heap.cpp:
        (JSC):
        * heap/Heap.h: Add accessors for the various types of allocators now. Also remove the isSafeToSweepStructures function 
        since it's always safe to sweep Structures now.
        (JSC::Heap::allocatorForObjectWithNormalDestructor): 
        (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor):
        (Heap):
        (JSC::Heap::allocateWithNormalDestructor):
        (JSC):
        (JSC::Heap::allocateWithImmortalStructureDestructor):
        * heap/IncrementalSweeper.cpp: Remove all the logic to detect when it's safe to sweep Structures from the 
        IncrementalSweeper since it's always safe to sweep Structures now.
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::sweepNextBlock):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping):
        (JSC):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp: Remove the logic that was preventing us from sweeping Structures if it wasn't safe. Add 
        tracking of the specific destructor type of allocator. 
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::destructorType):
        (MarkedAllocator):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        * heap/MarkedBlock.cpp: Add all the destructor type stuff to MarkedBlocks so that we do the right thing when sweeping. 
        We also use the stored destructor type to determine the right thing to do in all JSCell::classInfo() calls.
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedBlock.h:
        (JSC):
        (JSC::MarkedBlock::allocator):
        (JSC::MarkedBlock::destructorType):
        * heap/MarkedSpace.cpp: Add the new destructor allocators to MarkedSpace.
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor):
        (JSC::MarkedSpace::normalDestructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithImmortalStructureDestructor):
        (JSC::MarkedSpace::allocateWithNormalDestructor):
        (JSC::MarkedSpace::forEachBlock):
        * heap/SlotVisitor.cpp: Add include because the symbol was needed in an inlined function.
        * jit/JIT.h: Make sure we use the correct allocator when doing inline allocations in the baseline JIT.
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateJSFinalObject):
        (JSC::JIT::emitAllocateJSArray):
        * jsc.cpp: 
        (GlobalObject::create): Add finalizer here since JSGlobalObject needs to use a finalizer instead of inheriting from 
        JSDestructibleObject.
        * runtime/Arguments.cpp: Inherit from JSDestructibleObject.
        (JSC):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::Arguments):
        * runtime/ErrorPrototype.cpp: Added an assert to make sure we have a trivial destructor.
        (JSC):
        * runtime/Executable.h: Indicate that all of the Executable* classes have immortal Structures.
        (JSC):
        * runtime/InternalFunction.cpp: Inherit from JSDestructibleObject.
        (JSC):
        (JSC::InternalFunction::InternalFunction):
        * runtime/InternalFunction.h:
        (InternalFunction):
        * runtime/JSCell.h: Added two static bools, needsDestruction and hasImmortalStructure, that classes can override 
        to indicate at compile time which part of the heap they should be allocated in.
        (JSC::allocateCell): Use the appropriate allocator depending on the destructor type.
        * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be 
        accessed safely when the object is being destroyed.
        (JSC):
        (JSDestructibleObject):
        (JSC::JSDestructibleObject::classInfo):
        (JSC::JSDestructibleObject::JSDestructibleObject):
        (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe.
        * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all 
        of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well.
        (JSC::JSGlobalObject::reset):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one 
        for the m_rareData field when it's created.
        (JSC::JSGlobalObject::create):
        (JSC):
        * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject.
        (JSGlobalThis):
        (JSC::JSGlobalThis::JSGlobalThis):
        * runtime/JSPropertyNameIterator.h: Has an immortal Structure.
        (JSC):
        * runtime/JSScope.cpp:
        (JSC):
        * runtime/JSString.h: Has an immortal Structure.
        (JSC):
        * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject.
        (JSWrapperObject):
        (JSC::JSWrapperObject::JSWrapperObject):
        * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff.
        (JSC):
        * runtime/NameInstance.h: Inherit from JSDestructibleObject.
        (NameInstance):
        * runtime/RegExp.h: Has immortal Structure.
        (JSC):
        * runtime/RegExpObject.cpp: Inheritance cleanup.
        (JSC):
        * runtime/SparseArrayValueMap.h: Has immortal Structure.
        (JSC):
        * runtime/Structure.h: Has immortal Structure.
        (JSC):
        * runtime/StructureChain.h: Ditto.
        (JSC):
        * runtime/SymbolTable.h: Ditto.
        (SharedSymbolTable):
        (JSC):

== Rolled over to ChangeLog-2012-10-02 ==
