path: root/Source/JavaScriptCore/ChangeLog

2012-05-26  Geoffrey Garen  <ggaren@apple.com>

        WebKit should be lazy-finalization-safe (esp. the DOM) v2
        https://bugs.webkit.org/show_bug.cgi?id=87581

        Reviewed by Oliver Hunt.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::callDestructor):
        * heap/WeakBlock.h:
        * heap/WeakSetInlines.h:
        (JSC::WeakBlock::finalize): Since we don't guarantee destruction order,
        it's not valid to access GC pointers like the Structure pointer during
        finalization. We NULL out the structure pointer in debug builds to try
        to make this programming mistake more obvious.

        * API/JSCallbackConstructor.cpp:
        (JSC::JSCallbackConstructor::destroy):
        * API/JSCallbackObject.cpp:
        (JSC::::destroy):
        (JSC::JSCallbackObjectData::finalize):
        * runtime/Arguments.cpp:
        (JSC::Arguments::destroy):
        * runtime/DateInstance.cpp:
        (JSC::DateInstance::destroy):
        * runtime/Error.cpp:
        (JSC::StrictModeTypeErrorFunction::destroy):
        * runtime/Executable.cpp:
        (JSC::ExecutableBase::destroy):
        (JSC::NativeExecutable::destroy):
        (JSC::ScriptExecutable::destroy):
        (JSC::EvalExecutable::destroy):
        (JSC::ProgramExecutable::destroy):
        (JSC::FunctionExecutable::destroy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::destroy):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::destroy):
        * runtime/JSStaticScopeObject.cpp:
        (JSC::JSStaticScopeObject::destroy):
        * runtime/JSString.cpp:
        (JSC::JSString::destroy):
        * runtime/JSVariableObject.cpp:
        (JSC::JSVariableObject::destroy):
        * runtime/NameInstance.cpp:
        (JSC::NameInstance::destroy):
        * runtime/RegExp.cpp:
        (JSC::RegExp::destroy):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::destroy):
        * runtime/Structure.cpp:
        (JSC::Structure::destroy):
        * runtime/StructureChain.cpp:
        (JSC::StructureChain::destroy): Use static_cast instead of jsCast because
        jsCast does Structure-based validation, and our Structure is not guaranteed
        to be alive when we get finalized.

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

        DFG CSE should eliminate redundant WeakJSConstants
        https://bugs.webkit.org/show_bug.cgi?id=87179

        Reviewed by Gavin Barraclough.
        
        Merged r118141 from dfgopt.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::weakConstantCSE):
        (CSEPhase):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::weakConstant):

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

        DFG CSE should do redundant store elimination
        https://bugs.webkit.org/show_bug.cgi?id=87161

        Reviewed by Oliver Hunt.
        
        Merge r118138 from dfgopt.
        
        This patch adds redundant store elimination. For example, consider this
        code:
        
        o.x = 42;
        o.x = 84;
        
        If o.x is speculated to be a well-behaved field, the first assignment is
        unnecessary, since the second just overwrites it. We would like to
        eliminate the first assignment in these cases. The need for this
        optimization arises mostly from stores that our runtime requires. For
        example:
        
        o = {f:1, g:2, h:3};
        
        This will have four assignments to the structure for the newly created
        object - one assignment for the empty structure, one for {f}, one for
        {f, g}, and one for {f, g, h}. We would like to only have the last of
        those assigments in this case.
        
        Intriguingly, doing so for captured variables breaks the way arguments
        simplification used to work. Consider that prior to either arguments
        simplification or store elimination we will have IR that looks like:
        
        a: SetLocal(r0, Empty)
        b: SetLocal(r1, Empty)
        c: GetLocal(r0)
        d: CreateArguments(@c)
        e: SetLocal(r0, @d)
        f: SetLocal(r1, @d)
        
        Then redundant store elimination will eliminate the stores that
        initialize the arguments registers to Empty, but then arguments
        simplification eliminates the stores that initialize the arguments to
        the newly created arguments - and at this point we no longer have any
        stores to the arguments register, leading to hilarious crashes. This
        patch therefore changes arguments simplification to replace
        CreateArguments with JSConstant(Empty) rather than eliminating the
        SetLocals. But this revealed bugs where arguments simplification was
        being overzealous, so I fixed those bugs.
        
        This is a minor speed-up on V8/early and a handful of other tests.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::uncheckedActivationRegister):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::globalVarStoreElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        (JSC::DFG::CSEPhase::setReplacement):
        (JSC::DFG::CSEPhase::eliminate):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::uncheckedActivationRegisterFor):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isPhantomArguments):
        (Node):
        (JSC::DFG::Node::hasConstant):
        (JSC::DFG::Node::valueOfJSConstant):
        (JSC::DFG::Node::hasStructureTransitionData):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        DFG ConvertThis should just be a CheckStructure if the structure is known
        https://bugs.webkit.org/show_bug.cgi?id=87057

        Reviewed by Gavin Barraclough.
        
        Merged r118021 from dfgopt.
        
        This gives ValueProfile the ability to track singleton values - i.e. profiling
        sites that always see the same value.
        
        That is then used to profile the structure in op_convert_this.
        
        This is then used to optimize op_convert_this into a CheckStructure if the
        structure is always the same.
        
        That then results in better CSE in inlined code that uses 'this', since
        previously we couldn't CSE accesses on 'this' from different inline call frames.
        
        Also fixed a bug where we were unnecessarily flushing 'this'.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
        * bytecode/LazyOperandValueProfile.h:
        (CompressedLazyOperandValueProfileHolder):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::ValueProfileBase):
        (JSC::ValueProfileBase::dump):
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        (ValueProfileBase):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_convert_this):
        (JSC::JIT::emitSlow_op_convert_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_convert_this):
        (JSC::JIT::emitSlow_op_convert_this):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSValue.h:
        (JSValue):
        * runtime/Structure.h:
        (JSC::JSValue::structureOrUndefined):
        (JSC):

2012-05-24  Tim Horton  <timothy_horton@apple.com>

        Add feature defines for web-facing parts of CSS Regions and Exclusions
        https://bugs.webkit.org/show_bug.cgi?id=87442
        <rdar://problem/10887709>

        Reviewed by Dan Bernstein.

        * Configurations/FeatureDefines.xcconfig:

2012-05-24  Geoffrey Garen  <ggaren@apple.com>

        WebKit should be lazy-finalization-safe (esp. the DOM)
        https://bugs.webkit.org/show_bug.cgi?id=87456

        Reviewed by Filip Pizlo.

        Lazy finalization adds one twist to weak pointer use:

                A HashMap of weak pointers may contain logically null entries.
                (Weak pointers behave as-if null once their payloads die.)
                Insertion must not assume that a pre-existing entry is
                necessarily valid, and iteration must not assume that all
                entries can be dereferenced.

        (Previously, I thought that it also added a second twist:

                A demand-allocated weak pointer may replace a dead payload
                before the payload's finalizer runs. In that case, when the
                payload's finalizer runs, the payload has already been
                overwritten, and the finalizer should not clear the payload,
                which now points to something new.

        But that's not the case here, since we cancel the old payload's
        finalizer when we over-write it. I've added ASSERTs to verify this
        assumption, in case it ever changes.)

        * API/JSClassRef.cpp:
        (OpaqueJSClass::prototype): No need to specify null; that's the default.

        * API/JSWeakObjectMapRefPrivate.cpp: Use remove, since take() is gone.

        * heap/PassWeak.h:
        (WeakImplAccessor::was): This is no longer a debug-only function, since
        it's required to reason about lazily finalized pointers.

        * heap/Weak.h:
        (JSC::weakAdd):
        (JSC::weakRemove):
        (JSC::weakClear): Added these helper functions for the common idioms of
        what clients want to do in their weak pointer finalizers.

        * jit/JITStubs.cpp:
        (JSC::JITThunks::hostFunctionStub): Use the new idioms. Otherwise, we
        would return NULL for a "zombie" executable weak pointer that was waiting
        for finalization (item (2)), and finalizing a dead executable weak pointer
        would potentially destroy a new, live one (item (1)).

        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::lookupOrCreate):
        (JSC::RegExpCache::finalize): Ditto.

        (JSC::RegExpCache::invalidateCode): Check for null while iterating. (See
        item (2).)

        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::contains):
        (JSC::StructureTransitionTable::add): Use get and set instead of add and
        contains, since add and contains are not compatible with lazy finalization.

        * runtime/WeakGCMap.h:
        (WeakGCMap):
        (JSC::WeakGCMap::clear):
        (JSC::WeakGCMap::remove): Removed a bunch of code that was incompatible with
        lazy finalization because I didn't feel like making it compatible, and I had
        no way to test it.

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

        REGRESSION (r118013-r118031): Loops/Reloads under www.yahoo.com, quits after three tries with error
        https://bugs.webkit.org/show_bug.cgi?id=87327

        Reviewed by Geoffrey Garen.
        
        If you use AbstractValue::filter(StructureSet) to test subset relationships between TOP and a
        set containing >=2 elements, you're going to have a bad time.
        
        That's because AbstractValue considers a set with >=2 elements to be equivalent to TOP, in order
        to save space and speed up convergence. So filtering has no effect in this case, which made
        the code think that the abstract value was proving that the structure check was unnecessary.
        The correct thing to do is to use isSubsetOf() on the StructureAbstractValue, which does the
        right thingies for TOP and >=2 elements.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        new test fast/js/dfg-arguments-mixed-alias.html fails on JSVALUE32_64
        https://bugs.webkit.org/show_bug.cgi?id=87378

        Reviewed by Gavin Barraclough.
        
        - Captured variable tracking forgot did not consistently handle arguments, leading to OSR
          badness.
        
        - Nodes capable of exiting were tracked in a non-monotonic way, leading to compiler errors.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::CSEPhase):
        (CSEPhase):
        (JSC::DFG::performCSE):
        * dfg/DFGCSEPhase.h:
        (DFG):
        * dfg/DFGCommon.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::resetExitStates):
        (DFG):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGPhase.h:
        (DFG):
        (JSC::DFG::runPhase):

2012-05-24  Geoffrey Garen  <ggaren@apple.com>

        Made WeakSet per-block instead of per-heap
        https://bugs.webkit.org/show_bug.cgi?id=87401

        Reviewed by Oliver Hunt.

        This allows us fast access to the set of all weak pointers for a block,
        which is a step toward lazy finalization.

        No performance change.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::lastChanceToFinalize): Removed the per-heap weak set, since
        it's per-block now.

        (JSC::Heap::markRoots): Delegate weak set visiting to the marked space,
        since it knows how to iterate all blocks.

        (JSC::Heap::collect): Moved the reaping outside of markRoots, since it
        doesn't mark anything.

        Make sure to reset allocators after shrinking, since shrinking may
        deallocate the current allocator.

        * heap/Heap.h:
        (Heap): No more per-heap weak set, since it's per-block now.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::lastChanceToFinalize): Migrated finalization logic
        here from the heap, so the heap doesn't need to know about our internal
        data structures like our weak set.

        (JSC::MarkedBlock::heap):
        (JSC::MarkedBlock::weakSet):
        (JSC::MarkedBlock::shrink):
        (JSC::MarkedBlock::resetAllocator):
        (JSC::MarkedBlock::visitWeakSet):
        (JSC::MarkedBlock::reapWeakSet):
        (JSC::MarkedBlock::sweepWeakSet):
        * heap/MarkedSpace.cpp:
        (JSC::VisitWeakSet::VisitWeakSet):
        (JSC::VisitWeakSet::operator()):
        (VisitWeakSet):
        (JSC):
        (JSC::ReapWeakSet::operator()):
        (JSC::SweepWeakSet::operator()):
        (JSC::LastChanceToFinalize::operator()):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::ResetAllocator::operator()):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        (JSC::MarkedSpace::reapWeakSets):
        (JSC::MarkedSpace::sweepWeakSets):
        (JSC::Shrink::operator()):
        (JSC::MarkedSpace::shrink):
        * heap/MarkedSpace.h:
        (MarkedSpace): Make sure to account for our weak sets when sweeping,
        shrinking, etc.

        * heap/WeakSet.cpp:
        (JSC):
        * heap/WeakSet.h:
        (WeakSet):
        (JSC::WeakSet::heap):
        (JSC):
        (JSC::WeakSet::lastChanceToFinalize):
        (JSC::WeakSet::visit):
        (JSC::WeakSet::reap):
        (JSC::WeakSet::shrink):
        (JSC::WeakSet::resetAllocator): Inlined some things since they're called
        once per block now instead of once per heap.

        * heap/WeakSetInlines.h:
        (JSC::WeakSet::allocate): Use the per-block weak set since there is no
        per-heap weak set anymore.

2012-05-24  Gavin Barraclough  <barraclough@apple.com>

        Fix arm build

        Rubber stamped by Geoff Garen

        * dfg/DFGGPRInfo.h:
        (GPRInfo):

2012-05-24  Gavin Barraclough  <barraclough@apple.com>

        Move cacheFlush from ExecutableAllocator to Assembler classes
        https://bugs.webkit.org/show_bug.cgi?id=87420

        Reviewed by Oliver Hunt.

        Makes more sense there, & remove a pile of #ifdefs.

        * assembler/ARMAssembler.cpp:
        (JSC):
        (JSC::ARMAssembler::cacheFlush):
        * assembler/ARMAssembler.h:
        (ARMAssembler):
        (JSC::ARMAssembler::cacheFlush):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::relinkJump):
        (JSC::ARMv7Assembler::cacheFlush):
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::setInt32):
        (JSC::ARMv7Assembler::setUInt7ForLoad):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::cacheFlush):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::performFinalization):
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::relinkJump):
        (JSC::MIPSAssembler::relinkCall):
        (JSC::MIPSAssembler::repatchInt32):
        (JSC::MIPSAssembler::cacheFlush):
        (MIPSAssembler):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::repatchCompact):
        (JSC::SH4Assembler::cacheFlush):
        (SH4Assembler):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::cacheFlush):
        * jit/ExecutableAllocator.cpp:
        (JSC):
        * jit/ExecutableAllocator.h:
        (ExecutableAllocator):

2012-05-24  John Mellor  <johnme@chromium.org>

        Font Boosting: Add compile flag and runtime setting
        https://bugs.webkit.org/show_bug.cgi?id=87394

        Reviewed by Adam Barth.

        Add ENABLE_FONT_BOOSTING.

        * Configurations/FeatureDefines.xcconfig:

2012-05-24  Allan Sandfeld Jensen  <allan.jensen@nokia.com>

        cti_vm_throw gets kicked out by gcc 4.6 -flto
        https://bugs.webkit.org/show_bug.cgi?id=56088

        Reviewed by Darin Adler.

        Add REFERENCED_FROM_ASM to functions only referenced from assembler.

        * dfg/DFGOperations.cpp:
        * jit/HostCallReturnValue.h:
        * jit/JITStubs.h:
        * jit/ThunkGenerators.cpp:

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

        Incorrect merge of r117542 from dfg opt branch in r118323 is leading to fast/js/dfg-arguments-osr-exit.html failing
        https://bugs.webkit.org/show_bug.cgi?id=87350

        Reviewed by Maciej Stachowiak.
        
        The dfgopt branch introduced the notion of a local variable being killed because it was aliased
        to the Arguments object as in cases like:
        
        var a = arguments;
        return a.length;
        
        This required changes to OSR exit handling - if the variable is dead but aliased to arguments, then
        OSR exit should reify the arguments. But meanwhile, in tip of tree we introduced special handling for
        dead variables on OSR exit. When the two were merged in r118323, the structure of the if/else branches
        ended up being such that we would treat dead arguments variables as totally dead as opposed to treating
        them as variables that need arguments reification.
        
        This fixes the structure of the relevant if/else block so that variables that are dead-but-arguments
        end up being treated as reified arguments objects, while variables that are dead but not aliased to
        arguments are treated as tip of tree would have treated them (initialize to Undefined).

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

2012-05-24  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed 32 bit buildfix after r118325.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): Use ASSERT_UNUSED instead ASSERT.

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

        DFG operationTearOffActivation should return after handling the null activation case
        https://bugs.webkit.org/show_bug.cgi?id=87348
        <rdar://problem/11522295>

        Reviewed by Oliver Hunt.

        * dfg/DFGOperations.cpp:

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

        Unreviewed, merge the arguments fix in r118138 to get bots green.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):

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

        DFG CFA should record if a node can OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=86905

        Reviewed by Oliver Hunt.
        
        Merged r117931 from dfgopt.
        
        Adds a NodeFlag that denotes nodes that are known to not have OSR exits.
        This ought to aid any backwards analyses that need to know when a
        backward flow merge might happen due to a side exit.
        
        Also added assertions into speculationCheck() that ensure that we did not
        mark a node as non-exiting and then promptly compile in an exit. This
        helped catch some minor bugs where we were doing unnecessary speculation
        checks.
        
        This is a perf-neutral change. The speculation checks that this removes
        were not on hot paths of major benchmarks.

        * bytecode/PredictedType.h:
        (JSC):
        (JSC::isAnyPrediction):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::speculateInt32Unary):
        (AbstractState):
        (JSC::DFG::AbstractState::speculateNumberUnary):
        (JSC::DFG::AbstractState::speculateBooleanUnary):
        (JSC::DFG::AbstractState::speculateInt32Binary):
        (JSC::DFG::AbstractState::speculateNumberBinary):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::mergeFlags):
        (JSC::DFG::Node::filterFlags):
        (Node):
        (JSC::DFG::Node::setCanExit):
        (JSC::DFG::Node::canExit):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::nodeFlagsAsString):
        * dfg/DFGNodeFlags.h:
        (DFG):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::speculationCheck):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (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::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        (JSC::DFG::SpeculativeJIT::compile):

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

        DFG should not do unnecessary indirections when storing to objects
        https://bugs.webkit.org/show_bug.cgi?id=86959

        Reviewed by Oliver Hunt.
        
        Merged r117819 from dfgopt.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        DFG should optimize aliased uses of the Arguments object of the current call frame
        https://bugs.webkit.org/show_bug.cgi?id=86552

        Reviewed by Geoff Garen.
        
        Merged r117542 and r117543 from dfgopt.
        
        Performs must-alias and escape analysis on uses of CreateArguments, and if
        a variable is must-aliased to CreateArguments and does not escape, then we
        turn all uses of that variable into direct arguments accesses.
        
        36% speed-up on V8/earley leading to a 2.3% speed-up overall in V8.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::uncheckedArgumentsRegister):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::argumentsThatWereNotCreated):
        (ValueRecovery):
        (JSC::ValueRecovery::dump):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAdjacencyList.h:
        (AdjacencyList):
        (JSC::DFG::AdjacencyList::removeEdgeFromBag):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (ArgumentsSimplificationPhase):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::argumentsRegisterFor):
        (AssemblyHelpers):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference):
        * dfg/DFGGPRInfo.h:
        (GPRInfo):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::collectGarbage):
        (DFG):
        * dfg/DFGGraph.h:
        (Graph):
        (JSC::DFG::Graph::executableFor):
        (JSC::DFG::Graph::argumentsRegisterFor):
        (JSC::DFG::Graph::uncheckedArgumentsRegisterFor):
        (JSC::DFG::Graph::clobbersWorld):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler.h:
        (JSC::DFG::OSRExitCompiler::OSRExitCompiler):
        (OSRExitCompiler):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::ValueSource::dump):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::VariableAccessData):
        (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias):
        (VariableAccessData):
        (JSC::DFG::VariableAccessData::isArgumentsAlias):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_get_argument_by_val):

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

        DFGCapabilities should not try to get an arguments register from code blocks that don't have one
        https://bugs.webkit.org/show_bug.cgi?id=87332

        Reviewed by Andy Estes.

        * dfg/DFGCapabilities.h:
        (JSC::DFG::canInlineOpcode):

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

        DFG should have sparse conditional constant propagation
        https://bugs.webkit.org/show_bug.cgi?id=86580

        Reviewed by Oliver Hunt.
        
        Merged r117370 from dfgopt.
        
        This enhances CFA so that if it suspects at any point during the fixpoint that a
        branch will only go one way, then it only propagates in that one way.
        
        This vastly increases the opportunities for CFG simplification. For example, it
        enables us to evaporate this loop:
        
        for (var i = 0; i < 1; ++i) doThings(i);
        
        As a result, it uncovered loads of bugs in the CFG simplifier. In particular:
        
        - Phi fixup was assuming that all Phis worth fixing up are shouldGenerate().
          That's not true; we also fixup Phis that are dead.
          
        - GetLocal fixup was assuming that it's only necessary to rewire links to a
          GetLocal, and that the GetLocal's own links don't need to be rewired. Untrue,
          because the GetLocal may not be rewirable (first block has no GetLocal for r42
          but second block does have a GetLocal), in which case it will refer to a Phi
          in the second block. We need it to refer to a Phi from the first block to
          ensure that subsequent transformations work.
          
        - Tail operand fixup was ignoring the fact that Phis in successors may contain
          references to the children of our tail variables. Hence, successor Phi child
          substitution needs to use the original second block variable table as its
          prior, rather than trying to reconstruct the prior later (since by that point
          the children of the second block's tail variables will have been fixed up, so
          we will not know what the prior would have been).

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::beginBasicBlock):
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::reset):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::branchDirectionToString):
        (AbstractState):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference):
        (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::OperandSubstitution):
        (OperandSubstitution):
        (JSC::DFG::CFGSimplificationPhase::skipGetLocal):
        (JSC::DFG::CFGSimplificationPhase::recordPossibleIncomingReference):
        (CFGSimplificationPhase):
        (JSC::DFG::CFGSimplificationPhase::fixTailOperand):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::changeEdge):

2012-05-23  Ojan Vafai  <ojan@chromium.org>

        add back the ability to disable flexbox
        https://bugs.webkit.org/show_bug.cgi?id=87147

        Reviewed by Tony Chang.

        * Configurations/FeatureDefines.xcconfig:

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

        Unreviewed, fix Windows build.

        * bytecode/CodeBlock.h:
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canCompileOpcodes):
        * dfg/DFGCommon.h:
        (DFG):

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

        DFG should optimize inlined uses of arguments.length and arguments[i]
        https://bugs.webkit.org/show_bug.cgi?id=86327

        Reviewed by Gavin Barraclough.
        
        Merged r117017 from dfgopt.
        
        Turns inlined uses of arguments.length into a constant.
        
        Turns inlined uses of arguments[constant] into a direct reference to the
        argument.
        
        Big win on micro-benchmarks. Not yet a win on V8 because the hot uses of
        arguments.length and arguments[i] are aliased. I'll leave the aliasing
        optimizations to a later patch.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/DFGExitProfile.h:
        (FrequentExitSite):
        (JSC::DFG::FrequentExitSite::FrequentExitSite):
        (JSC::DFG::QueryableExitProfile::hasExitSite):
        (QueryableExitProfile):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentsSimplificationPhase.cpp: Added.
        (DFG):
        (ArgumentsSimplificationPhase):
        (JSC::DFG::ArgumentsSimplificationPhase::ArgumentsSimplificationPhase):
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::performArgumentsSimplification):
        * dfg/DFGArgumentsSimplificationPhase.h: Added.
        (DFG):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::executableFor):
        (DFG):
        * dfg/DFGAssemblyHelpers.h:
        (AssemblyHelpers):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getLocalLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::executableFor):
        (Graph):
        (JSC::DFG::Graph::clobbersWorld):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToConstant):
        (JSC::DFG::Node::convertToGetLocalUnlinked):
        (Node):
        (JSC::DFG::Node::unlinkedLocal):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        DFG should be able to optimize foo.apply(bar, arguments)
        https://bugs.webkit.org/show_bug.cgi?id=86306

        Reviewed by Gavin Barraclough.
        
        Merge r116912 from dfgopt.
        
        Enables compilation of op_jneq_ptr and some forms of op_call_varargs.
        
        Also includes a bunch of bug fixes that were made necessary by the increased
        pressure on the CFG simplifier.
        
        This is a 1-2% win on V8.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::CodeBlock):
        (JSC::ProgramCodeBlock::canCompileWithDFGInternal):
        (JSC::EvalCodeBlock::canCompileWithDFGInternal):
        (JSC::FunctionCodeBlock::canCompileWithDFGInternal):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::canCompileWithDFG):
        (JSC::CodeBlock::canCompileWithDFGState):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::processPhiStack):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
        (JSC::DFG::CFGSimplificationPhase::fixTailOperand):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getLocalLoadElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::setReplacement):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::debugFail):
        (DFG):
        (JSC::DFG::canHandleOpcodes):
        (JSC::DFG::canCompileOpcodes):
        (JSC::DFG::canInlineOpcodes):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        (DFG):
        (JSC::DFG::canCompileOpcodes):
        (JSC::DFG::canCompileEval):
        (JSC::DFG::canCompileProgram):
        (JSC::DFG::canCompileFunctionForCall):
        (JSC::DFG::canCompileFunctionForConstruct):
        * dfg/DFGCommon.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * 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::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (Validate):
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::checkOperand):
        (JSC::DFG::Validate::reportValidationContext):
        * jit/JIT.cpp:
        (JSC::JIT::emitOptimizationCheck):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::compileBinaryArithOp):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::sample):

2012-05-23  Geoffrey Garen  <ggaren@apple.com>

        Refactored WeakBlock to use malloc, clarify behavior
        https://bugs.webkit.org/show_bug.cgi?id=87318

        Reviewed by Filip Pizlo.

        We want to use malloc so we can make these smaller than 4KB,
        since an individual MarkedBlock will usually have fewer than
        4KB worth of weak pointers.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots): Renamed visitLiveWeakImpls to visit, since
        we no longer need to distinguish from "visitDeadWeakImpls".

        Renamed "visitDeadWeakImpls" to "reap" because we're not actually
        doing any visiting -- we're just tagging things as dead.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::destroy):
        (JSC::WeakBlock::WeakBlock): Malloc!

        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap): Renamed as above.

        * heap/WeakBlock.h:
        (WeakBlock): Reduced to 3KB, as explained above.

        * heap/WeakSet.cpp:
        (JSC::WeakSet::visit):
        (JSC::WeakSet::reap):
        * heap/WeakSet.h:
        (WeakSet): Updated for renames, and to match WebKit style.

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

        Use after free in JSC::DFG::ByteCodeParser::processPhiStack
        https://bugs.webkit.org/show_bug.cgi?id=87312
        <rdar://problem/11518848>

        Reviewed by Oliver Hunt.

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

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

        It should be possible to make C function calls from DFG code on ARM in debug mode
        https://bugs.webkit.org/show_bug.cgi?id=87313

        Reviewed by Gavin Barraclough.

        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):

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

        DFG should be able to inline functions that use arguments reflectively
        https://bugs.webkit.org/show_bug.cgi?id=86132

        Reviewed by Oliver Hunt.
        
        Merged r116838 from dfgopt.
        
        This turns on inlining of functions that use arguments reflectively, but it
        does not do any of the obvious optimizations that this exposes. I'll save that
        for another patch - the important thing for now is that this contains all of
        the plumbing necessary to make this kind of inlining sound even in bizarro
        cases like an inline callee escaping the arguments object to parts of the
        inline caller where the arguments are otherwise dead. Or even more fun cases
        like where you've inlined to an inline stack that is three-deep, and the
        function on top of the inline stack reflectively accesses the arguments of a
        function that is in the middle of the inline stack. Any subsequent
        optimizations that we do for the obvious cases of arguments usage in inline
        functions will have to take care not to break the baseline functionality that
        this patch plumbs together.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::dump):
        * bytecode/CodeBlock.h:
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::argumentsRegisterFor):
        (AssemblyHelpers):
        * dfg/DFGByteCodeParser.cpp:
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * 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):
        * interpreter/CallFrame.cpp:
        (JSC):
        (JSC::CallFrame::someCodeBlockForPossiblyInlinedCode):
        * interpreter/CallFrame.h:
        (ExecState):
        (JSC::ExecState::someCodeBlockForPossiblyInlinedCode):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::retrieveArgumentsFromVMCode):
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):
        (JSC):
        (JSC::Arguments::tearOffForInlineCallFrame):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::create):
        (JSC::Arguments::finishCreation):
        (JSC):

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

        Every OSR exit on ARM results in a crash
        https://bugs.webkit.org/show_bug.cgi?id=87307

        Reviewed by Geoffrey Garen.

        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):

2012-05-23  Geoffrey Garen  <ggaren@apple.com>

        Refactored heap tear-down to use normal value semantics (i.e., destructors)
        https://bugs.webkit.org/show_bug.cgi?id=87302

        Reviewed by Oliver Hunt.

        This is a step toward incremental DOM finalization.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        * heap/CopiedSpace.h:
        (CopiedSpace): Just use our destructor, instead of relying on the heap
        to send us a special message at a special time.

        * heap/Heap.cpp:
        (JSC::Heap::Heap): Use OwnPtr for m_markListSet because this is not Sparta.

        (JSC::Heap::~Heap): No need for delete or freeAllBlocks because normal
        destructors do this work automatically now.

        (JSC::Heap::lastChanceToFinalize): Just call lastChanceToFinalize on our
        sub-objects, and assume it does the right thing. This improves encapsulation,
        so we can add items requiring finalization to our sub-objects.

        * heap/Heap.h: Moved m_blockAllocator to get the right destruction order.

        * heap/MarkedSpace.cpp:
        (Take):
        (JSC):
        (JSC::Take::Take):
        (JSC::Take::operator()):
        (JSC::Take::returnValue): Moved to the top of the file so it can be used
        in another function.

        (JSC::MarkedSpace::~MarkedSpace): Delete all outstanding memory, like a good
        destructor should.

        (JSC::MarkedSpace::lastChanceToFinalize): Moved some code here from the heap,
        since it pertains to our internal implementation details.

        * heap/MarkedSpace.h:
        (MarkedSpace):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::lastChanceToFinalize):
        * heap/WeakBlock.h:
        (WeakBlock):
        * heap/WeakSet.cpp:
        (JSC::WeakSet::lastChanceToFinalize):
        * heap/WeakSet.h:
        (WeakSet): Stop using a special freeAllBlocks() callback and just implement
        lastChanceToFinalize.

2011-05-22  Geoffrey Garen  <ggaren@apple.com>

        Encapsulated some calculations for whether portions of the heap are empty
        https://bugs.webkit.org/show_bug.cgi?id=87210

        Reviewed by Gavin Barraclough.

        This is a step toward incremental DOM finalization.

        * heap/Heap.cpp:
        (JSC::Heap::~Heap): Explicitly call freeAllBlocks() instead of relying
        implicitly on all blocks thinking they're empty. In future, we may
        choose to tear down the heap without first setting all data structures
        to "empty".

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isEmpty):
        (JSC::MarkedBlock::gatherDirtyCells): Renamed markCountIsZero to isEmpty,
        in preparation for making it check for outstanding finalizers in addition
        to marked cells.

        * heap/MarkedSpace.cpp:
        (Take):
        (JSC::Take::Take):
        (JSC::Take::operator()):
        (JSC::Take::returnValue):
        (JSC::MarkedSpace::shrink):
        (JSC::MarkedSpace::freeAllBlocks): Refactored the "Take" functor to support
        a conditional isEmpty check, so it dould be shared by shrink() and freeAllBlocks().

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::WeakBlock):
        (JSC::WeakBlock::visitLiveWeakImpls):
        (JSC::WeakBlock::visitDeadWeakImpls):
        * heap/WeakBlock.h:
        (WeakBlock):
        (JSC::WeakBlock::isEmpty):
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep):
        (JSC::WeakSet::shrink): Use isEmpty(), in preparation for changes in
        its implementation.

2012-05-23  Oswald Buddenhagen  <oswald.buddenhagen@nokia.com>

        [Qt] Remove references to $$QT_SOURCE_TREE

        With a modularized Qt, it's ambigious. What we really want is qtbase,
        which qtcore is a proxy for (we assume it will always live in qtbase).

        Reviewed by Tor Arne Vestbø.

        * JavaScriptCore.pri:
        * Target.pri:

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

        DFG should allow inlining in case of certain arity mismatches
        https://bugs.webkit.org/show_bug.cgi?id=86059

        Reviewed by Geoff Garen.
        
        Merge r116620 from dfgopt.

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

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

        DFG variable capture analysis should work even if the variables arose through inlining
        https://bugs.webkit.org/show_bug.cgi?id=85945

        Reviewed by Oliver Hunt.
        
        Merged r116555 from dfgopt.
        
        This just changes how the DFG queries whether a variable is captured. It does not
        change any user-visible behavior.
        
        As part of this change, I further solidified the policy that the CFA behaves in an
        undefined way for captured locals and queries about their values will not yield
        reliable results. This will likely be changed in the future, but for now it makes
        sense.
        
        One fun part about this change is that it recognizes that the same variable may
        be both captured and not, at the same time, because their live interval spans
        inlining boundaries. This only happens in the case of arguments to functions that
        capture their arguments, and this change treats them with just the right touch of
        conservatism: they will be treated as if captured by the caller as well as the 
        callee.
        
        Finally, this also adds captured variable reasoning to the InlineCallFrame, which
        I thought might be useful for later tooling.
        
        This is perf-neutral, since it does it does not make the DFG take advantage of this
        new functionality in any way. In particular, it is still the case that the DFG will
        not inline functions that use arguments reflectively or that create activations.

        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::needsActivation):
        (JSC::CodeBlock::argumentIsCaptured):
        (JSC::CodeBlock::localIsCaptured):
        (JSC::CodeBlock::isCaptured):
        * bytecode/CodeOrigin.h:
        (InlineCallFrame):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::merge):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::newVariableAccessData):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flushArgument):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::processPhiStack):
        (JSC::DFG::ByteCodeParser::fixVariableAccessPredictions):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (CFGSimplificationPhase):
        (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
        (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
        (JSC::DFG::CFGSimplificationPhase::fixTailOperand):
        * dfg/DFGCommon.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::nameOfVariableAccessData):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::needsActivation):
        (JSC::DFG::Graph::usesArguments):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::VariableAccessData):
        (JSC::DFG::VariableAccessData::mergeIsCaptured):
        (VariableAccessData):
        (JSC::DFG::VariableAccessData::isCaptured):

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

        DFG should support op_get_argument_by_val and op_get_arguments_length
        https://bugs.webkit.org/show_bug.cgi?id=85911

        Reviewed by Oliver Hunt.
        
        Merged r116467 from dfgopt.
        
        This adds a simple and relatively conservative implementation of op_get_argument_by_val
        and op_get_arguments_length. We can optimize these later. For now it's great to have
        the additional coverage.
        
        This patch appears to be perf-neutral.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::addressFor):
        (JSC::DFG::AssemblyHelpers::tagFor):
        (JSC::DFG::AssemblyHelpers::payloadFor):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_argument_by_val):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        DFG should support op_tear_off_arguments
        https://bugs.webkit.org/show_bug.cgi?id=85847

        Reviewed by Michael Saboff.
        
        Merged r116378 from dfgopt.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-05-22  Mark Hahnenberg  <mhahnenberg@apple.com>

        CopiedSpace::contains doesn't check for oversize blocks
        https://bugs.webkit.org/show_bug.cgi?id=87180

        Reviewed by Geoffrey Garen.

        When doing a conservative scan we use CopiedSpace::contains to determine if a particular 
        address points into the CopiedSpace. Currently contains() only checks if the address 
        points to a block in to-space, which means that pointers to oversize blocks may not get scanned. 

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        (JSC::CopiedSpace::doneFillingBlock):
        (JSC::CopiedSpace::doneCopying):
        * heap/CopiedSpace.h: Refactored CopiedSpace so that all blocks (oversize and to-space) are 
        in a single hash set and bloom filter for membership testing.
        (CopiedSpace):
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::contains): We check for the normal block first. Since the oversize blocks are
        only page aligned, rather than block aligned, we have to re-mask the ptr to check if it's in 
        CopiedSpace. Also added a helper function of the same name that takes a CopiedBlock* and checks
        if it's in CopiedSpace so that check isn't typed out twice.
        (JSC):
        (JSC::CopiedSpace::startedCopying):
        (JSC::CopiedSpace::addNewBlock):

2012-05-22  Geoffrey Garen  <ggaren@apple.com>

        CopiedBlock and MarkedBlock should have proper value semantics (i.e., destructors)
        https://bugs.webkit.org/show_bug.cgi?id=87172

        Reviewed by Oliver Hunt and Phil Pizlo.

        This enables MarkedBlock to own non-trivial sub-objects that require
        destruction. It also fixes a FIXME about casting a CopiedBlock to a
        MarkedBlock at destroy time.

        CopiedBlock and MarkedBlock now accept an allocation chunk at create
        time and return it at destroy time. Their client is expected to
        allocate, recycle, and destroy these chunks.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::releaseFreeBlocks):
        (JSC::BlockAllocator::blockFreeingThreadMain): Don't call MarkedBlock::destroy
        because we expect that to be called before a block is put on our free
        list now. Do manually deallocate our allocation chunk because that's
        our job now.

        * heap/BlockAllocator.h:
        (BlockAllocator):
        (JSC::BlockAllocator::allocate): Allocate never fails now. This is a
        cleaner abstraction because only one object does all the VM allocation
        and deallocation. Caching is an implementation detail.

        (JSC::BlockAllocator::deallocate): We take an allocation chunk argument
        instead of a block because we now expect the block to have been destroyed 
        before we recycle its memory. For convenience, we still use the HeapBlock
        class as our linked list node. This is OK because HeapBlock is a POD type.

        * heap/CopiedBlock.h:
        (CopiedBlock):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::destroy):
        (JSC::CopiedBlock::CopiedBlock): Added proper create and destroy functions,
        to match MarkedBlock.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        (JSC::CopiedSpace::doneCopying):
        (JSC::CopiedSpace::getFreshBlock):
        (JSC::CopiedSpace::freeAllBlocks):
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::recycleBlock): Make sure to call destroy before
        returning a block to the BlockAllocator. Otherwise, our destructors
        won't run. (If we get this wrong now, we'll get a compile error.)

        * heap/HeapBlock.h:
        (JSC::HeapBlock::HeapBlock): const!

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock): No need to distinguish between
        create and recycle -- MarkedBlock always accepts memory allocated by
        its client now.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create): Don't allocate memory -- we assume that we're
        passed already-allocated memory, to clarify the responsibility for VM
        recycling.

        (JSC::MarkedBlock::destroy): Do run our destructor before giving back
        our VM -- that is the whole point of this patch.

        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        * heap/MarkedSpace.cpp: const!

        (JSC::MarkedSpace::freeBlocks): Make sure to call destroy before
        returning a block to the BlockAllocator. Otherwise, our destructors
        won't run. (If we get this wrong now, we'll get a compile error.)

== Rolled over to ChangeLog-2012-05-22 ==