Source/JavaScriptCore/ChangeLog

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

        JSC should try to make profiling deterministic because otherwise reproducing failures is
        nearly impossible
        https://bugs.webkit.org/show_bug.cgi?id=89940

        Rubber stamped by Gavin Barraclough.
        
        This rolls out the part of http://trac.webkit.org/changeset/121215 that introduced randomness
        into the system. Now, instead of randomizing the tier-up threshold, we always set it to an
        artificially low (and statically predetermined!) value. This gives most of the benefit of
        threshold randomization without actually making the system behave completely differently on
        each invocation.

        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter::setThreshold):
        * runtime/Options.cpp:
        (Options):
        (JSC::Options::initializeOptions):
        * runtime/Options.h:
        (Options):

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

        Value profiling should use tier-up threshold randomization to get more coverage
        https://bugs.webkit.org/show_bug.cgi?id=89802

        Reviewed by Gavin Barraclough.
        
        This patch causes both LLInt and Baseline JIT code to take the OSR slow path several
        times before actually doing OSR. If we take the OSR slow path before the execution
        count threshold is reached, then we just call CodeBlock::updateAllPredictions() to
        compute the current latest least-upper-bound SpecType of all values seen in each
        ValueProfile.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC):
        (JSC::CodeBlock::updateAllPredictions):
        (JSC::CodeBlock::shouldOptimizeNow):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::llintExecuteCounter):
        (JSC::CodeBlock::jitExecuteCounter):
        (CodeBlock):
        (JSC::CodeBlock::updateAllPredictions):
        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter::setThreshold):
        (JSC::ExecutionCounter::status):
        (JSC):
        * bytecode/ExecutionCounter.h:
        (JSC::ExecutionCounter::count):
        (ExecutionCounter):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::weakRandomInteger):
        * runtime/Options.cpp:
        (Options):
        (JSC::Options::initializeOptions):
        * runtime/Options.h:
        (Options):
        * runtime/WeakRandom.h:
        (WeakRandom):
        (JSC::WeakRandom::seedUnsafe):

2012-06-25  Yong Li  <yoli@rim.com>

        [BlackBerry] Add JSC statistics into about:memory
        https://bugs.webkit.org/show_bug.cgi?id=89779

        Reviewed by Rob Buis.

        Add MemoryStatistics.cpp into build, and fill JITBytes for BlackBerry port.

        * PlatformBlackBerry.cmake:
        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):

2012-06-23  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r121058.
        http://trac.webkit.org/changeset/121058
        https://bugs.webkit.org/show_bug.cgi?id=89809

        Patch causes plugins tests to crash in GTK debug builds
        (Requested by zdobersek on #webkit).

        * API/APIShims.h:
        (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock):
        (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock):
        (APIEntryShimWithoutLock):
        (JSC::APIEntryShim::APIEntryShim):
        (APIEntryShim):
        (JSC::APICallbackShim::~APICallbackShim):
        * API/JSContextRef.cpp:
        (JSGlobalContextCreate):
        (JSGlobalContextCreateInGroup):
        (JSGlobalContextRelease):
        (JSContextCreateBacktrace):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateSlowCase):
        * heap/Heap.cpp:
        (JSC::Heap::protect):
        (JSC::Heap::unprotect):
        (JSC::Heap::collect):
        (JSC::Heap::setActivityCallback):
        (JSC::Heap::activityCallback):
        (JSC::Heap::sweeper):
        * heap/Heap.h:
        (Heap):
        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::~HeapTimer):
        (JSC::HeapTimer::invalidate):
        (JSC::HeapTimer::timerDidFire):
        (JSC):
        * heap/HeapTimer.h:
        (HeapTimer):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doWork):
        (JSC::IncrementalSweeper::create):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCase):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::reap):
        * jsc.cpp:
        (functionGC):
        (functionReleaseExecutableMemory):
        (jscmain):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::evaluate):
        * runtime/GCActivityCallback.h:
        (DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::create):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::~JSGlobalData):
        (JSC::JSGlobalData::sharedInstance):
        (JSC::JSGlobalData::sharedInstanceInternal):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::~JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSLock.cpp:
        (JSC):
        (JSC::createJSLockCount):
        (JSC::JSLock::lockCount):
        (JSC::setLockCount):
        (JSC::JSLock::JSLock):
        (JSC::JSLock::lock):
        (JSC::JSLock::unlock):
        (JSC::JSLock::currentThreadIsHoldingLock):
        (JSC::JSLock::DropAllLocks::DropAllLocks):
        (JSC::JSLock::DropAllLocks::~DropAllLocks):
        * runtime/JSLock.h:
        (JSC):
        (JSLock):
        (JSC::JSLock::JSLock):
        (JSC::JSLock::~JSLock):
        (DropAllLocks):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        * testRegExp.cpp:
        (realMain):

2012-06-22  Alexandru Chiculita  <achicu@adobe.com>

        [CSS Shaders] Re-enable the CSS Shaders compile time flag on Safari Mac
        https://bugs.webkit.org/show_bug.cgi?id=89781

        Reviewed by Dean Jackson.

        Added ENABLE_CSS_SHADERS flag as enabled by default on Safari for Mac.

        * Configurations/FeatureDefines.xcconfig:

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

        DFG tier-up should happen in prologues, not epilogues
        https://bugs.webkit.org/show_bug.cgi?id=89752

        Reviewed by Geoffrey Garen.

        This change has two outcomes:
        
        1) Slightly reduces the likelihood that a function will be optimized both
        standalone and via inlining.  Previously, if you had a call sequence like foo() 
        calls bar() exactly once, and nobody else calls bar(), then bar() would get
        optimized first (because it returns first) and then foo() gets optimized.  If foo()
        can inline bar() then that means that bar() gets optimized twice.  But now, if we
        optimize in prologues, then foo() will be optimized first.  If it inlines bar(),
        that means that there will no longer be any calls to bar().
        
        2) It lets us kill some code in JITStubs.  Epilogue tier-up was very different from
        loop tier-up, since epilogue tier-up should not attempt OSR.  But prologue tier-up
        requires OSR (albeit really easy OSR since it's the top of the compilation unit),
        so it becomes just like loop tier-up.  As a result, we now have one optimization
        hook (cti_optimize) instead of two (cti_optimize_from_loop and
        cti_optimize_from_ret).
        
        As a consequence of not having an optimization check in epilogues, the OSR exit
        code must now trigger reoptimization itself instead of just signaling the epilogue
        check to fire.
        
        This also adds the ability to count the number of DFG compilations, which was
        useful for debugging this patch and might be useful for other things in the future.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::reoptimize):
        (JSC):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGDriver.cpp:
        (DFG):
        (JSC::DFG::getNumCompilations):
        (JSC::DFG::compile):
        * dfg/DFGDriver.h:
        (DFG):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::handleExitCounts):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * jit/JIT.cpp:
        (JSC::JIT::emitOptimizationCheck):
        * jit/JIT.h:
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_ret_object_or_this):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_ret_object_or_this):
        (JSC::JIT::emit_op_enter):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_enter):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:

2012-06-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSLock should be per-JSGlobalData
        https://bugs.webkit.org/show_bug.cgi?id=89123

        Reviewed by Gavin Barraclough.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * API/APIShims.h:
        (APIEntryShimWithoutLock):
        (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): Added an extra parameter to the constructor to 
        determine whether we should ref the JSGlobalData or not. We want to ref all the time except for in the 
        HeapTimer class because timerDidFire could run after somebody has started to tear down that particular 
        JSGlobalData, so we wouldn't want to resurrect the ref count of that JSGlobalData from 0 back to 1 after 
        its destruction has begun. 
        (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): Now derefs if it also refed.
        (JSC::APIEntryShim::APIEntryShim):
        (APIEntryShim):
        (JSC::APIEntryShim::~APIEntryShim):
        (JSC::APIEntryShim::init): Factored out common initialization code for the various APIEntryShim constructors.
        Also moved the timeoutChecker stop and start here because we need to start after we've grabbed the API lock
        and before we've released it, which can only done in APIEntryShim.
        (JSC::APICallbackShim::~APICallbackShim): We no longer need to synchronize here.
        * API/JSContextRef.cpp:
        (JSGlobalContextCreate):
        (JSGlobalContextCreateInGroup):
        (JSGlobalContextRelease):
        (JSContextCreateBacktrace):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateSlowCase):
        * heap/Heap.cpp:
        (JSC::Heap::protect):
        (JSC::Heap::unprotect):
        (JSC::Heap::collect):
        (JSC::Heap::setActivityCallback):
        (JSC::Heap::activityCallback):
        (JSC::Heap::sweeper):
        * heap/Heap.h: Changed m_activityCallback and m_sweeper to be raw pointers rather than OwnPtrs because they 
        are now responsible for their own lifetime. Also changed the order of declaration of the GCActivityCallback
        and the IncrementalSweeper to make sure they're the last things that get initialized during construction to 
        prevent any issues with uninitialized memory in the JSGlobalData/Heap they might care about.
        (Heap):
        * heap/HeapTimer.cpp: Refactored to allow for thread-safe operation and shutdown.
        (JSC::HeapTimer::~HeapTimer):
        (JSC::HeapTimer::invalidate):
        (JSC):
        (JSC::HeapTimer::didStartVMShutdown): Called at the beginning of ~JSGlobalData. If we're on the same thread 
        that the HeapTimer is running on, we kill the HeapTimer ourselves. If not, then we set some state in the 
        HeapTimer and schedule it to fire immediately so that it can notice and kill itself.
        (JSC::HeapTimer::timerDidFire): We grab our mutex and check our JSGlobalData pointer. If it has been zero-ed
        out, then we know the VM has started to shutdown and we should kill ourselves. Otherwise, grab the APIEntryShim,
        but without ref-ing the JSGlobalData (we don't want to bring the JSGlobalData's ref-count from 0 to 1) in case 
        we were interrupted between releasing our mutex and trying to grab the APILock.
        * heap/HeapTimer.h: 
        (HeapTimer):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doWork): We no longer need the API shim here since HeapTimer::timerDidFire handles 
        all of that for us. 
        (JSC::IncrementalSweeper::create):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCase):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::reap):
        * jsc.cpp:
        (functionGC):
        (functionReleaseExecutableMemory):
        (jscmain):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::evaluate):
        * runtime/GCActivityCallback.h:
        (DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::create):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::~JSGlobalData): Signals to the two HeapTimers (GCActivityCallback and IncrementalSweeper)
        that the VM has started shutting down. It then waits until the HeapTimer is done with whatever activity 
        it needs to do before continuing with any further destruction. Also asserts that we do not currently hold the 
        APILock because this could potentially cause deadlock when we try to signal to the HeapTimers using their mutexes.
        (JSC::JSGlobalData::sharedInstance): Protect the initialization for the shared instance with the GlobalJSLock.
        (JSC::JSGlobalData::sharedInstanceInternal):
        * runtime/JSGlobalData.h: Change to be ThreadSafeRefCounted so that we don't have to worry about refing and 
        de-refing JSGlobalDatas on separate threads since we don't do it that often anyways.
        (JSGlobalData):
        (JSC::JSGlobalData::apiLock):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::~JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSLock.cpp:
        (JSC):
        (JSC::GlobalJSLock::GlobalJSLock): For accessing the shared instance.
        (JSC::GlobalJSLock::~GlobalJSLock):
        (JSC::JSLockHolder::JSLockHolder): MutexLocker for JSLock. Also refs the JSGlobalData to keep it alive so that 
        it can successfully unlock it later without it disappearing from underneath it.
        (JSC::JSLockHolder::~JSLockHolder):
        (JSC::JSLock::JSLock):
        (JSC::JSLock::~JSLock):
        (JSC::JSLock::lock): Uses the spin lock for guarding the lock count and owner thread fields. Uses the mutex for 
        actually waiting for long periods. 
        (JSC::JSLock::unlock):
        (JSC::JSLock::currentThreadIsHoldingLock): 
        (JSC::JSLock::dropAllLocks):
        (JSC::JSLock::dropAllLocksUnconditionally):
        (JSC::JSLock::grabAllLocks):
        (JSC::JSLock::DropAllLocks::DropAllLocks):
        (JSC::JSLock::DropAllLocks::~DropAllLocks):
        * runtime/JSLock.h:
        (JSC):
        (GlobalJSLock):
        (JSLockHolder):
        (JSLock):
        (DropAllLocks):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        * testRegExp.cpp:
        (realMain):

2012-06-22  Peter Beverloo  <peter@chromium.org>

        [Chromium] Disable c++0x compatibility warnings in JavaScriptCore.gyp when building for Android
        https://bugs.webkit.org/show_bug.cgi?id=88853

        Reviewed by Steve Block.

        The Android exclusions were necessary to fix a gyp generation error, as
        the gcc_version variable wasn't being defined for Android. Remove these
        exceptions when Chromium is able to define the gcc_version variable.

        * JavaScriptCore.gyp/JavaScriptCore.gyp:

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

        op_resolve_global should not prevent DFG inlining
        https://bugs.webkit.org/show_bug.cgi?id=89726

        Reviewed by Gavin Barraclough.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/GlobalResolveInfo.h:
        (JSC::GlobalResolveInfo::GlobalResolveInfo):
        (GlobalResolveInfo):
        * dfg/DFGByteCodeParser.cpp:
        (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-06-20  Filip Pizlo  <fpizlo@apple.com>

        DFG should inline 'new Array()'
        https://bugs.webkit.org/show_bug.cgi?id=89632

        Reviewed by Geoffrey Garen.
        
        This adds support for treating InternalFunction like intrinsics. The code
        to do so is actually quite clean, so I don't feel bad about perpetuating
        the InternalFunction vs. JSFunction-with-NativeExecutable dichotomy.
        
        Currently this newfound power is only used to inline 'new Array()'.
        
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (DFG):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isInternalFunctionConstant):
        (JSC::DFG::Graph::valueOfInternalFunctionConstant):

2012-06-21  Mark Hahnenberg  <mhahnenberg@apple.com>

        Adding copyrights to new files.

        * heap/HeapTimer.cpp:
        * heap/HeapTimer.h:
        * heap/IncrementalSweeper.cpp:
        * heap/IncrementalSweeper.h:

2012-06-21  Arnaud Renevier  <arno@renevier.net>

        make sure headers are included only once per file
        https://bugs.webkit.org/show_bug.cgi?id=88922

        Reviewed by Alexey Proskuryakov.

        * bytecode/CodeBlock.h:
        * heap/MachineStackMarker.cpp:
        * runtime/JSVariableObject.h:

2012-06-21  Ryuan Choi  <ryuan.choi@gmail.com>

        [EFL][WK2] Make WebKit2/Efl headers and resources installable.
        https://bugs.webkit.org/show_bug.cgi?id=88207

        Reviewed by Chang Shu.

        * shell/CMakeLists.txt: Use ${EXEC_INSTALL_DIR} instead of hardcoding "bin"

2012-06-20  Geoffrey Garen  <ggaren@apple.com>

        Reduced (but did not eliminate) use of "berzerker GC"
        https://bugs.webkit.org/show_bug.cgi?id=89237

        Reviewed by Gavin Barraclough.

        (PART 1)

        This patch turned out to be crashy, so I'm landing the non-crashy bits
        first.

        This part is pre-requisite refactoring. I didn't actually turn off
        "berzerker GC" or turn on incremental shrinking.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::removeBlock): Make sure to clear the free list when
        we throw away the block we're currently allocating out of. Otherwise, we'll
        allocate out of a stale free list.

        * heap/MarkedSpace.cpp:
        (JSC::Free::Free):
        (JSC::Free::operator()):
        (JSC::Free::returnValue): Refactored this functor to use a shared helper
        function, so we can share our implementation with the incremental sweeper.

        Also changed to freeing individual blocks immediately instead of linking
        them into a list for later freeing. This makes the programming interface
        simpler, and it's slightly more efficient to boot.

        (JSC::MarkedSpace::~MarkedSpace): Updated for rename.

        (JSC::MarkedSpace::freeBlock):
        (JSC::MarkedSpace::freeOrShrinkBlock): New helper functions to share behavior
        with the incremental sweeper.

        (JSC::MarkedSpace::shrink): Updated for new functor behavior.

        * heap/MarkedSpace.h: Statically typed languages are awesome.

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

        DFG should optimize ResolveGlobal
        https://bugs.webkit.org/show_bug.cgi?id=89617

        Reviewed by Oliver Hunt.
        
        This adds inlining of ResolveGlobal accesses that are known monomorphic. It also
        adds the specific function optimization to ResolveGlobal, when it is inlined. And,
        it makes internal functions act like specific functions, since that will be the
        most common use-case of this optimization.
        
        This is only a slighy speed-up (sub 1%), since we don't yet do the obvious thing
        with this optimization, which is to completely inline common "globally resolved"
        function and constructor calls, like "new Array()".

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::globalResolveInfoForBytecodeOffset):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::numberOfGlobalResolveInfos):
        * bytecode/GlobalResolveInfo.h:
        (JSC::getGlobalResolveInfoBytecodeOffset):
        (JSC):
        * bytecode/ResolveGlobalStatus.cpp: Added.
        (JSC):
        (JSC::computeForStructure):
        (JSC::computeForLLInt):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h: Added.
        (JSC):
        (ResolveGlobalStatus):
        (JSC::ResolveGlobalStatus::ResolveGlobalStatus):
        (JSC::ResolveGlobalStatus::state):
        (JSC::ResolveGlobalStatus::isSet):
        (JSC::ResolveGlobalStatus::operator!):
        (JSC::ResolveGlobalStatus::isSimple):
        (JSC::ResolveGlobalStatus::takesSlowPath):
        (JSC::ResolveGlobalStatus::structure):
        (JSC::ResolveGlobalStatus::offset):
        (JSC::ResolveGlobalStatus::specificValue):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (DFG):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * runtime/JSObject.cpp:
        (JSC::getCallableObjectSlow):
        (JSC):
        (JSC::JSObject::put):
        (JSC::JSObject::putDirectVirtual):
        (JSC::JSObject::putDirectAccessor):
        * runtime/JSObject.h:
        (JSC):
        (JSC::getCallableObject):
        (JSC::JSObject::putOwnDataProperty):
        (JSC::JSObject::putDirect):
        (JSC::JSObject::putDirectWithoutTransition):

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

        Functions on global objects should be specializable
        https://bugs.webkit.org/show_bug.cgi?id=89615

        Reviewed by Oliver Hunt.
        
        I tested to see if this brought back the bug in https://bugs.webkit.org/show_bug.cgi?id=33343,
        and it didn't. Bug 33343 was the reason why we disabled global object function specialization
        to begin with. So I'm guessing this is safe.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

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

        build-webkit failure due to illegal 32-bit integer constants in code
        generated by offlineasm
        https://bugs.webkit.org/show_bug.cgi?id=89347

        Reviewed by Geoffrey Garen.
        
        The offending constants are the magic numbers used by offlineasm to find
        offsets in the generated machine code. Added code to turn them into what
        the C++ compiler will believe to be valid 32-bit values.

        * offlineasm/offsets.rb:

2012-06-19  Geoffrey Garen  <ggaren@apple.com>

        Made the incremental sweeper more aggressive
        https://bugs.webkit.org/show_bug.cgi?id=89527

        Reviewed by Oliver Hunt.

        This is a pre-requisite to getting rid of "berzerker GC" because we need
        the sweeper to reclaim memory in a timely fashion, or we'll see a memory
        footprint regression.

        * heap/IncrementalSweeper.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::scheduleTimer): Since the time slice is predictable,
        no need to use a data member to record it.

        (JSC::IncrementalSweeper::doSweep): Sweep as many blocks as we can in a
        small time slice. This is better than sweeping only one block per timer
        fire because that strategy has a heavy timer overhead, and artificially
        delays memory reclamation.

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

        DFG should be able to print disassembly interleaved with the IR
        https://bugs.webkit.org/show_bug.cgi?id=89551

        Reviewed by Geoffrey Garen.
        
        This change also removes running Dominators unconditionally on every DFG
        compile. Dominators are designed to be computed on-demand, and currently
        the only demand is graph dumps.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::labelIgnoringWatchpoints):
        (ARMv7Assembler):
        * assembler/AbstractMacroAssembler.h:
        (AbstractMacroAssembler):
        (JSC::AbstractMacroAssembler::labelIgnoringWatchpoints):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::labelIgnoringWatchpoints):
        * dfg/DFGCommon.h:
        (JSC::DFG::shouldShowDisassembly):
        (DFG):
        * dfg/DFGDisassembler.cpp: Added.
        (DFG):
        (JSC::DFG::Disassembler::Disassembler):
        (JSC::DFG::Disassembler::dump):
        (JSC::DFG::Disassembler::dumpDisassembly):
        * dfg/DFGDisassembler.h: Added.
        (DFG):
        (Disassembler):
        (JSC::DFG::Disassembler::setStartOfCode):
        (JSC::DFG::Disassembler::setForBlock):
        (JSC::DFG::Disassembler::setForNode):
        (JSC::DFG::Disassembler::setEndOfMainPath):
        (JSC::DFG::Disassembler::setEndOfCode):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dumpCodeOrigin):
        (JSC::DFG::Graph::amountOfNodeWhiteSpace):
        (DFG):
        (JSC::DFG::Graph::printNodeWhiteSpace):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (DFG):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        (JSC::DFG::JITCompiler::setStartOfCode):
        (JSC::DFG::JITCompiler::setForBlock):
        (JSC::DFG::JITCompiler::setForNode):
        (JSC::DFG::JITCompiler::setEndOfMainPath):
        (JSC::DFG::JITCompiler::setEndOfCode):
        * dfg/DFGNode.h:
        (Node):
        (JSC::DFG::Node::willHaveCodeGen):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::nodeFlagsAsString):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * runtime/Options.cpp:
        (Options):
        (JSC::Options::initializeOptions):
        * runtime/Options.h:
        (Options):

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

        JSC should be able to show disassembly for all generated JIT code
        https://bugs.webkit.org/show_bug.cgi?id=89536

        Reviewed by Gavin Barraclough.
        
        Now instead of doing linkBuffer.finalizeCode(), you do
        FINALIZE_CODE(linkBuffer, (... explanation ...)). FINALIZE_CODE() then
        prints your explanation and the disassembled code, if
        Options::showDisassembly is set to true.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/LinkBuffer.cpp: Added.
        (JSC):
        (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        (JSC::LinkBuffer::linkCode):
        (JSC::LinkBuffer::performFinalization):
        (JSC::LinkBuffer::dumpLinkStatistics):
        (JSC::LinkBuffer::dumpCode):
        * assembler/LinkBuffer.h:
        (LinkBuffer):
        (JSC):
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodeRef::tryToDisassemble):
        (MacroAssemblerCodeRef):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        * disassembler/Disassembler.h:
        (JSC):
        (JSC::tryToDisassemble):
        * disassembler/UDis86Disassembler.cpp:
        (JSC::tryToDisassemble):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITCode.h:
        (JSC::JITCode::tryToDisassemble):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileCTIMachineTrampolines):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTIMachineTrampolines):
        (JSC::JIT::privateCompileCTINativeCall):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::finalize):
        * jit/ThunkGenerators.cpp:
        (JSC::charCodeAtThunkGenerator):
        (JSC::charAtThunkGenerator):
        (JSC::fromCharCodeThunkGenerator):
        (JSC::sqrtThunkGenerator):
        (JSC::floorThunkGenerator):
        (JSC::ceilThunkGenerator):
        (JSC::roundThunkGenerator):
        (JSC::expThunkGenerator):
        (JSC::logThunkGenerator):
        (JSC::absThunkGenerator):
        (JSC::powThunkGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        (JSC::LLInt::functionForCallEntryThunkGenerator):
        (JSC::LLInt::functionForConstructEntryThunkGenerator):
        (JSC::LLInt::functionForCallArityCheckThunkGenerator):
        (JSC::LLInt::functionForConstructArityCheckThunkGenerator):
        (JSC::LLInt::evalEntryThunkGenerator):
        (JSC::LLInt::programEntryThunkGenerator):
        * runtime/Options.cpp:
        (Options):
        (JSC::Options::initializeOptions):
        * runtime/Options.h:
        (Options):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::compile):

2012-06-19  Mark Hahnenberg  <mhahnenberg@apple.com>

        [Qt][Mac] REGRESSION(r120742): It broke the build
        https://bugs.webkit.org/show_bug.cgi?id=89516

        Reviewed by Geoffrey Garen.

        Removing GCActivityCallbackCF.cpp because it doesn't mesh well with cross-platform 
        code on Darwin (e.g. Qt). We now use plain ol' vanilla ifdefs to handle platforms 
        without CF support. These if-defs will probably disappear in the future when we 
        use cross-platform timers in HeapTimer.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/GCActivityCallback.cpp:
        (JSC):
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::doWork):
        (JSC::DefaultGCActivityCallback::scheduleTimer):
        (JSC::DefaultGCActivityCallback::cancelTimer):
        (JSC::DefaultGCActivityCallback::didAllocate):
        (JSC::DefaultGCActivityCallback::willCollect):
        (JSC::DefaultGCActivityCallback::cancel):
        * runtime/GCActivityCallbackCF.cpp: Removed.

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

        DFG CFA forgets to notify subsequent phases of found constants if it proves LogicalNot to be a constant
        https://bugs.webkit.org/show_bug.cgi?id=89511
        <rdar://problem/11700089>

        Reviewed by Geoffrey Garen.

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

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

        CodeBlock::needsCallReturnIndices() is no longer needed.
        https://bugs.webkit.org/show_bug.cgi?id=89490

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::needsCallReturnIndices): removed.
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):

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

        Unreviewed, try to fix Windows build.

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

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

        It should be possible to look at disassembly
        https://bugs.webkit.org/show_bug.cgi?id=89319

        Reviewed by Sam Weinig.
        
        This imports the udis86 disassembler library. The library is placed
        behind an abstraction in disassembler/Disassembler.h, so that we can
        in the future use other disassemblers (for other platforms) whenever
        appropriate. As a first step, the disassembler is being invoked for
        DFG verbose dumps.
        
        If we ever want to merge a new version of udis86 in the future, I've
        made notes about changes I made to the library in
        disassembler/udis86/differences.txt.

        * CMakeLists.txt:
        * DerivedSources.make:
        * GNUmakefile.list.am:
        * JavaScriptCore.pri:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * disassembler: Added.
        * disassembler/Disassembler.h: Added.
        (JSC):
        (JSC::tryToDisassemble):
        * disassembler/UDis86Disassembler.cpp: Added.
        (JSC):
        (JSC::tryToDisassemble):
        * disassembler/udis86: Added.
        * disassembler/udis86/differences.txt: Added.
        * disassembler/udis86/itab.py: Added.
        (UdItabGenerator):
        (UdItabGenerator.__init__):
        (UdItabGenerator.toGroupId):
        (UdItabGenerator.genLookupTable):
        (UdItabGenerator.genLookupTableList):
        (UdItabGenerator.genInsnTable):
        (genItabH):
        (genItabH.UD_ITAB_H):
        (genItabC):
        (genItab):
        (main):
        * disassembler/udis86/optable.xml: Added.
        * disassembler/udis86/ud_opcode.py: Added.
        (UdOpcodeTables):
        (UdOpcodeTables.sizeOfTable):
        (UdOpcodeTables.nameOfTable):
        (UdOpcodeTables.updateTable):
        (UdOpcodeTables.Insn):
        (UdOpcodeTables.Insn.__init__):
        (UdOpcodeTables.Insn.__init__.opcode):
        (UdOpcodeTables.parse):
        (UdOpcodeTables.addInsnDef):
        (UdOpcodeTables.print_table):
        (UdOpcodeTables.print_tree):
        * disassembler/udis86/ud_optable.py: Added.
        (UdOptableXmlParser):
        (UdOptableXmlParser.parseDef):
        (UdOptableXmlParser.parse):
        (printFn):
        (parse):
        (main):
        * disassembler/udis86/udis86.c: Added.
        (ud_init):
        (ud_disassemble):
        (ud_set_mode):
        (ud_set_vendor):
        (ud_set_pc):
        (ud):
        (ud_insn_asm):
        (ud_insn_off):
        (ud_insn_hex):
        (ud_insn_ptr):
        (ud_insn_len):
        * disassembler/udis86/udis86.h: Added.
        * disassembler/udis86/udis86_decode.c: Added.
        (eff_adr_mode):
        (ud_lookup_mnemonic):
        (decode_prefixes):
        (modrm):
        (resolve_operand_size):
        (resolve_mnemonic):
        (decode_a):
        (decode_gpr):
        (resolve_gpr64):
        (resolve_gpr32):
        (resolve_reg):
        (decode_imm):
        (decode_modrm_reg):
        (decode_modrm_rm):
        (decode_o):
        (decode_operand):
        (decode_operands):
        (clear_insn):
        (resolve_mode):
        (gen_hex):
        (decode_insn):
        (decode_3dnow):
        (decode_ssepfx):
        (decode_ext):
        (decode_opcode):
        (ud_decode):
        * disassembler/udis86/udis86_decode.h: Added.
        (ud_itab_entry_operand):
        (ud_itab_entry):
        (ud_lookup_table_list_entry):
        (sse_pfx_idx):
        (mode_idx):
        (modrm_mod_idx):
        (vendor_idx):
        (is_group_ptr):
        (group_idx):
        * disassembler/udis86/udis86_extern.h: Added.
        * disassembler/udis86/udis86_input.c: Added.
        (inp_buff_hook):
        (inp_file_hook):
        (ud):
        (ud_set_user_opaque_data):
        (ud_get_user_opaque_data):
        (ud_set_input_buffer):
        (ud_set_input_file):
        (ud_input_skip):
        (ud_input_end):
        (ud_inp_next):
        (ud_inp_back):
        (ud_inp_peek):
        (ud_inp_move):
        (ud_inp_uint8):
        (ud_inp_uint16):
        (ud_inp_uint32):
        (ud_inp_uint64):
        * disassembler/udis86/udis86_input.h: Added.
        * disassembler/udis86/udis86_itab_holder.c: Added.
        * disassembler/udis86/udis86_syn-att.c: Added.
        (opr_cast):
        (gen_operand):
        (ud_translate_att):
        * disassembler/udis86/udis86_syn-intel.c: Added.
        (opr_cast):
        (gen_operand):
        (ud_translate_intel):
        * disassembler/udis86/udis86_syn.c: Added.
        * disassembler/udis86/udis86_syn.h: Added.
        (mkasm):
        * disassembler/udis86/udis86_types.h: Added.
        (ud_operand):
        (ud):
        * jit/JITCode.h:
        (JITCode):
        (JSC::JITCode::tryToDisassemble):

2012-06-19  Mark Hahnenberg  <mhahnenberg@apple.com>

        GCActivityCallback and IncrementalSweeper should share code
        https://bugs.webkit.org/show_bug.cgi?id=89400

        Reviewed by Geoffrey Garen.

        A lot of functionality is duplicated between GCActivityCallback and IncrementalSweeper. 
        We should extract the common functionality out into a separate class that both of them 
        can inherit from. This refactoring will be an even greater boon when we add the ability 
        to shut these two agents down in a thread-safe fashion

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * heap/Heap.cpp:
        (JSC::Heap::Heap): Move initialization down so that the JSGlobalData has a valid Heap when 
        we're initializing the GCActivityCallback and the IncrementalSweeper.
        * heap/Heap.h:
        (Heap):
        * heap/HeapTimer.cpp: Added.
        (JSC):
        (JSC::HeapTimer::HeapTimer): Initialize the various base class data that
        DefaultGCActivityCallback::commonConstructor() used to do.
        (JSC::HeapTimer::~HeapTimer): Call to invalidate().
        (JSC::HeapTimer::synchronize): Same functionality as the old DefaultGCActivityCallback::synchronize().
        Virtual so that non-CF subclasses can override.
        (JSC::HeapTimer::invalidate): Tears down the runloop timer to prevent any future firing.
        (JSC::HeapTimer::timerDidFire): Callback to pass to the timer function. Casts and calls the virtual doWork().
        * heap/HeapTimer.h: Added. This is the class that serves as the common base class for 
        both GCActivityCallback and IncrementalSweeper. It handles setting up and tearing down run loops and synchronizing 
        across threads for its subclasses. 
        (JSC):
        (HeapTimer):
        * heap/IncrementalSweeper.cpp: Changes to accomodate the extraction of common functionality 
        between IncrementalSweeper and GCActivityCallback into a common ancestor.
        (JSC):
        (JSC::IncrementalSweeper::doWork): 
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::cancelTimer):
        (JSC::IncrementalSweeper::create):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * runtime/GCActivityCallback.cpp:
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::doWork):
        * runtime/GCActivityCallback.h:
        (GCActivityCallback):
        (JSC::GCActivityCallback::willCollect):
        (JSC::GCActivityCallback::GCActivityCallback):
        (JSC):
        (DefaultGCActivityCallback): Remove the platform data struct. The platform data should be kept in 
        the class itself so as to be accessible by doWork(). Most of the platform data for CF is kept in 
        HeapTimer anyways, so we only need the m_delay field now.
        * runtime/GCActivityCallbackBlackBerry.cpp:
        (JSC):
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::doWork):
        (JSC::DefaultGCActivityCallback::didAllocate):
        * runtime/GCActivityCallbackCF.cpp:
        (JSC):
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::doWork):
        (JSC::DefaultGCActivityCallback::scheduleTimer):
        (JSC::DefaultGCActivityCallback::cancelTimer):
        (JSC::DefaultGCActivityCallback::didAllocate):
        (JSC::DefaultGCActivityCallback::willCollect):
        (JSC::DefaultGCActivityCallback::cancel):


2012-06-19  Mike West  <mkwst@chromium.org>

        Introduce ENABLE_CSP_NEXT configuration flag.
        https://bugs.webkit.org/show_bug.cgi?id=89300

        Reviewed by Adam Barth.

        The 1.0 draft of the Content Security Policy spec is just about to
        move to Last Call. We'll hide work on the upcoming 1.1 spec behind
        this ENABLE flag, disabled by default.

        Spec: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html

        * Configurations/FeatureDefines.xcconfig:

2012-06-18  Mark Lam  <mark.lam@apple.com>

        Changed JSC to always record line number information so that error.stack
        and window.onerror() can report proper line numbers.
        https://bugs.webkit.org/show_bug.cgi?id=89410

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::lineNumberForBytecodeOffset):
        (JSC::CodeBlock::shrinkToFit): m_lineInfo is now available unconditionally.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addLineInfo):
        (JSC::CodeBlock::hasLineInfo): Unused.  Now removed.
        (JSC::CodeBlock::needsCallReturnIndices):
        (CodeBlock):
        (RareData):  Hoisted m_lineInfo out of m_rareData.  m_lineInfo is now
        filled in unconditionally.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::addLineInfo):

2012-06-18  Andy Estes  <aestes@apple.com>

        Fix r120663, which didn't land the change that was reviewed.

2012-06-18  Andy Estes  <aestes@apple.com>

        [JSC] In JSGlobalData.cpp, enableAssembler() sometimes leaks two CF objects
        https://bugs.webkit.org/show_bug.cgi?id=89415

        Reviewed by Sam Weinig.

        In the case where canUseJIT was a non-NULL CFBooleanRef,
        enableAssembler() would leak both canUseJITKey and canUseJIT by
        returning before calling CFRelease. Fix this by using RetainPtr.

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

2012-06-17  Geoffrey Garen  <ggaren@apple.com>

        GC copy phase spends needless cycles zero-filling blocks
        https://bugs.webkit.org/show_bug.cgi?id=89128

        Reviewed by Gavin Barraclough.

        We only need to zero-fill when we're allocating memory that might not
        get fully initialized before GC.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::create): Added a way to create without zero-filling.
        This is our optimization.

        (JSC::CopiedBlock::zeroFillToEnd):
        (JSC::CopiedBlock::CopiedBlock): Split zero-filling out from creation,
        so we can sometimes create without zero-filling.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::init):
        (JSC::CopiedSpace::tryAllocateSlowCase):
        (JSC::CopiedSpace::doneCopying): Renamed addNewBlock to allocateBlock()
        to clarify that the new block is always newly-allocated.

        (JSC::CopiedSpace::doneFillingBlock): Make sure to zero-fill to the end
        of a block that might be used in the future for allocation. (Most of the
        time, this is a no-op, since we've already filled the block completely.)

        (JSC::CopiedSpace::getFreshBlock): Removed this function because the
        abstraction of "allocation must succeed" is no longer useful.

        * heap/CopiedSpace.h: Updated declarations to match.

        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::allocateBlockForCopyingPhase): New function, which
        knows that it can skip zero-filling.

        Added tighter scoping to our lock, to improve parallelism.

        (JSC::CopiedSpace::allocateBlock): Folded getFreshBlock functionality
        into this function, for simplicity.

        * heap/MarkStack.cpp:
        (JSC::SlotVisitor::startCopying):
        (JSC::SlotVisitor::allocateNewSpace): Use our new zero-fill-free helper
        function for great good.

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

        DFG should attempt to use structure watchpoints for all inlined get_by_id's and put_by_id's
        https://bugs.webkit.org/show_bug.cgi?id=89316

        Reviewed by Oliver Hunt.

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

2012-06-15  Yong Li  <yoli@rim.com>

        [BlackBerry] Put platform-specific GC policy in GCActivityCallback
        https://bugs.webkit.org/show_bug.cgi?id=89236

        Reviewed by Rob Buis.

        Add GCActivityCallbackBlackBerry.cpp and implement platform-specific
        low memory GC policy there.

        * PlatformBlackBerry.cmake:
        * heap/Heap.h:
        (JSC::Heap::isSafeToCollect): Added.
        * runtime/GCActivityCallbackBlackBerry.cpp: Added.
        (JSC):
        (JSC::DefaultGCActivityCallbackPlatformData::DefaultGCActivityCallbackPlatformData):
        (DefaultGCActivityCallbackPlatformData):
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::~DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::didAllocate):
        (JSC::DefaultGCActivityCallback::willCollect):
        (JSC::DefaultGCActivityCallback::synchronize):
        (JSC::DefaultGCActivityCallback::cancel):

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

        DFG should be able to set watchpoints on structure transitions in the
        method check prototype chain
        https://bugs.webkit.org/show_bug.cgi?id=89058

        Adding the same assertion to 32-bit that I added to 64-bit. This change
        does not affect correctness but it's a good thing for assertion coverage.

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

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

        DFG should be able to set watchpoints on structure transitions in the
        method check prototype chain
        https://bugs.webkit.org/show_bug.cgi?id=89058

        Reviewed by Gavin Barraclough.
        
        This adds the ability to set watchpoints on Structures, and then does
        the most modest thing we can do with this ability: the DFG now sets
        watchpoints on structure transitions in the prototype chain of method
        checks.
        
        This appears to be a >1% speed-up on V8.

        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * bytecode/StructureSet.h:
        (JSC::StructureSet::containsOnly):
        (StructureSet):
        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::WatchpointSet):
        (JSC::InlineWatchpointSet::add):
        (JSC):
        (JSC::InlineWatchpointSet::inflateSlow):
        (JSC::InlineWatchpointSet::freeFat):
        * bytecode/Watchpoint.h:
        (WatchpointSet):
        (JSC):
        (InlineWatchpointSet):
        (JSC::InlineWatchpointSet::InlineWatchpointSet):
        (JSC::InlineWatchpointSet::~InlineWatchpointSet):
        (JSC::InlineWatchpointSet::hasBeenInvalidated):
        (JSC::InlineWatchpointSet::isStillValid):
        (JSC::InlineWatchpointSet::startWatching):
        (JSC::InlineWatchpointSet::notifyWrite):
        (JSC::InlineWatchpointSet::isFat):
        (JSC::InlineWatchpointSet::fat):
        (JSC::InlineWatchpointSet::inflate):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCommon.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isCellConstant):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addWeakReferences):
        (JITCompiler):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasStructure):
        (Node):
        (JSC::DFG::Node::structure):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::tryCachePutByID):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        * runtime/Structure.h:
        (JSC::Structure::transitionWatchpointSetHasBeenInvalidated):
        (Structure):
        (JSC::Structure::transitionWatchpointSetIsStillValid):
        (JSC::Structure::addTransitionWatchpoint):
        (JSC::Structure::notifyTransitionFromThisStructure):
        (JSC::JSCell::setStructure):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTableEntry::attemptToWatch):

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

        DFG should be able to set watchpoints on global variables
        https://bugs.webkit.org/show_bug.cgi?id=88692

        Reviewed by Geoffrey Garen.
        
        Rolling back in after fixing Windows build issues, and implementing
        branchTest8 for the Qt port's strange assemblers.
        
        This implements global variable constant folding by allowing the optimizing
        compiler to set a "watchpoint" on globals that it wishes to constant fold.
        If the watchpoint fires, then an OSR exit is forced by overwriting the
        machine code that the optimizing compiler generated with a jump.
        
        As such, this patch is adding quite a bit of stuff:
        
        - Jump replacement on those hardware targets supported by the optimizing
          JIT. It is now possible to patch in a jump instruction over any recorded
          watchpoint label. The jump must be "local" in the sense that it must be
          within the range of the largest jump distance supported by a one
          instruction jump.
          
        - WatchpointSets and Watchpoints. A Watchpoint is a doubly-linked list node
          that records the location where a jump must be inserted and the
          destination to which it should jump. Watchpoints can be added to a
          WatchpointSet. The WatchpointSet can be fired all at once, which plants
          all jumps. WatchpointSet also remembers if it had ever been invalidated,
          which allows for monotonicity: we typically don't want to optimize using
          watchpoints on something for which watchpoints had previously fired. The
          act of notifying a WatchpointSet has a trivial fast path in case no
          Watchpoints are registered (one-byte load+branch).
        
        - SpeculativeJIT::speculationWatchpoint(). It's like speculationCheck(),
          except that you don't have to emit branches. But, you need to know what
          WatchpointSet to add the resulting Watchpoint to. Not everything that
          you could write a speculationCheck() for will have a WatchpointSet that
          would get notified if the condition you were speculating against became
          invalid.
          
        - SymbolTableEntry now has the ability to refer to a WatchpointSet. It can
          do so without incurring any space overhead for those entries that don't
          have WatchpointSets.
          
        - The bytecode generator infers all global function variables to be
          watchable, and makes all stores perform the WatchpointSet's write check,
          and marks all loads as being potentially watchable (i.e. you can compile
          them to a watchpoint and a constant).
        
        Put together, this allows for fully sleazy inlining of calls to globally
        declared functions. The inline prologue will no longer contain the load of
        the function, or any checks of the function you're calling. I.e. it's
        pretty much like the kind of inlining you would see in Java or C++.
        Furthermore, the watchpointing functionality is built to be fairly general,
        and should allow setting watchpoints on all sorts of interesting things
        in the future.
        
        The sleazy inlining means that we will now sometimes inline in code paths
        that have never executed. Previously, to inline we would have either had
        to have executed the call (to read the call's inline cache) or have
        executed the method check (to read the method check's inline cache). Now,
        we might inline when the callee is a watched global variable. This
        revealed some humorous bugs. First, constant folding disagreed with CFA
        over what kinds of operations can clobber (example: code path A is dead
        but stores a String into variable X, all other code paths store 0 into
        X, and then you do CompareEq(X, 0) - CFA will say that this is a non-
        clobbering constant, but constant folding thought it was clobbering
        because it saw the String prediction). Second, inlining would crash if
        the inline callee had not been compiled. This patch fixes both bugs,
        since otherwise run-javascriptcore-tests would report regressions.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::ARMv7Assembler):
        (JSC::ARMv7Assembler::labelForWatchpoint):
        (JSC::ARMv7Assembler::label):
        (JSC::ARMv7Assembler::replaceWithJump):
        (JSC::ARMv7Assembler::maxJumpReplacementSize):
        * assembler/AbstractMacroAssembler.h:
        (JSC):
        (AbstractMacroAssembler):
        (Label):
        (JSC::AbstractMacroAssembler::watchpointLabel):
        (JSC::AbstractMacroAssembler::readPointer):
        * assembler/AssemblerBuffer.h:
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchTest8):
        (MacroAssemblerARM):
        (JSC::MacroAssemblerARM::replaceWithJump):
        (JSC::MacroAssemblerARM::maxJumpReplacementSize):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::load8Signed):
        (JSC::MacroAssemblerARMv7::load16Signed):
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::replaceWithJump):
        (JSC::MacroAssemblerARMv7::maxJumpReplacementSize):
        (JSC::MacroAssemblerARMv7::branchTest8):
        (JSC::MacroAssemblerARMv7::jump):
        (JSC::MacroAssemblerARMv7::makeBranch):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchTest8):
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::replaceWithJump):
        (JSC::MacroAssemblerMIPS::maxJumpReplacementSize):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchTest8):
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::replaceWithJump):
        (JSC::MacroAssemblerSH4::maxJumpReplacementSize):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::branchTest8):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::replaceWithJump):
        (MacroAssemblerX86Common):
        (JSC::MacroAssemblerX86Common::maxJumpReplacementSize):
        * assembler/MacroAssemblerX86_64.h:
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::branchTest8):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::X86Assembler):
        (X86Assembler):
        (JSC::X86Assembler::cmpb_im):
        (JSC::X86Assembler::testb_im):
        (JSC::X86Assembler::labelForWatchpoint):
        (JSC::X86Assembler::label):
        (JSC::X86Assembler::replaceWithJump):
        (JSC::X86Assembler::maxJumpReplacementSize):
        (JSC::X86Assembler::X86InstructionFormatter::memoryModRM):
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::dump):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::appendOSRExit):
        (JSC::CodeBlock::appendSpeculationRecovery):
        (CodeBlock):
        (JSC::CodeBlock::appendWatchpoint):
        (JSC::CodeBlock::numberOfWatchpoints):
        (JSC::CodeBlock::watchpoint):
        (DFGData):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        (JSC::DFG::exitKindIsCountable):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForChain):
        * bytecode/Instruction.h:
        (Instruction):
        (JSC::Instruction::Instruction):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/Watchpoint.cpp: Added.
        (JSC):
        (JSC::Watchpoint::~Watchpoint):
        (JSC::Watchpoint::correctLabels):
        (JSC::Watchpoint::fire):
        (JSC::WatchpointSet::WatchpointSet):
        (JSC::WatchpointSet::~WatchpointSet):
        (JSC::WatchpointSet::add):
        (JSC::WatchpointSet::notifyWriteSlow):
        (JSC::WatchpointSet::fireAllWatchpoints):
        * bytecode/Watchpoint.h: Added.
        (JSC):
        (Watchpoint):
        (JSC::Watchpoint::Watchpoint):
        (JSC::Watchpoint::setDestination):
        (WatchpointSet):
        (JSC::WatchpointSet::isStillValid):
        (JSC::WatchpointSet::hasBeenInvalidated):
        (JSC::WatchpointSet::startWatching):
        (JSC::WatchpointSet::notifyWrite):
        (JSC::WatchpointSet::addressOfIsWatched):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveWithBase):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetStaticVar):
        (JSC::BytecodeGenerator::emitPutStaticVar):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixResolveNode::emitBytecode):
        (JSC::PrefixResolveNode::emitBytecode):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::clobberStructures):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        (JSC::DFG::AbstractState::didClobber):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArguments):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::globalVarWatchpointElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::globalVarStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGCorrectableJumpPoint.h:
        (JSC::DFG::CorrectableJumpPoint::isSet):
        (CorrectableJumpPoint):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifierNumberForCheck):
        (Node):
        (JSC::DFG::Node::identifierNumberForCheck):
        (JSC::DFG::Node::hasRegisterPointer):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::appendCall):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_global_var_check):
        (JSC):
        (JSC::JIT::emitSlow_op_put_global_var_check):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_global_var_check):
        (JSC):
        (JSC::JIT::emitSlow_op_put_global_var_check):
        * 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/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSObject.cpp:
        (JSC::JSObject::removeDirect):
        * runtime/JSObject.h:
        (JSObject):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/SymbolTable.cpp: Added.
        (JSC):
        (JSC::SymbolTableEntry::copySlow):
        (JSC::SymbolTableEntry::freeFatEntrySlow):
        (JSC::SymbolTableEntry::couldBeWatched):
        (JSC::SymbolTableEntry::attemptToWatch):
        (JSC::SymbolTableEntry::addressOfIsWatched):
        (JSC::SymbolTableEntry::addWatchpoint):
        (JSC::SymbolTableEntry::notifyWriteSlow):
        (JSC::SymbolTableEntry::inflateSlow):
        * runtime/SymbolTable.h:
        (JSC):
        (SymbolTableEntry):
        (Fast):
        (JSC::SymbolTableEntry::Fast::Fast):
        (JSC::SymbolTableEntry::Fast::isNull):
        (JSC::SymbolTableEntry::Fast::getIndex):
        (JSC::SymbolTableEntry::Fast::isReadOnly):
        (JSC::SymbolTableEntry::Fast::getAttributes):
        (JSC::SymbolTableEntry::Fast::isFat):
        (JSC::SymbolTableEntry::SymbolTableEntry):
        (JSC::SymbolTableEntry::~SymbolTableEntry):
        (JSC::SymbolTableEntry::operator=):
        (JSC::SymbolTableEntry::isNull):
        (JSC::SymbolTableEntry::getIndex):
        (JSC::SymbolTableEntry::getFast):
        (JSC::SymbolTableEntry::getAttributes):
        (JSC::SymbolTableEntry::isReadOnly):
        (JSC::SymbolTableEntry::watchpointSet):
        (JSC::SymbolTableEntry::notifyWrite):
        (FatEntry):
        (JSC::SymbolTableEntry::FatEntry::FatEntry):
        (JSC::SymbolTableEntry::isFat):
        (JSC::SymbolTableEntry::fatEntry):
        (JSC::SymbolTableEntry::inflate):
        (JSC::SymbolTableEntry::bits):
        (JSC::SymbolTableEntry::freeFatEntry):
        (JSC::SymbolTableEntry::pack):
        (JSC::SymbolTableEntry::isValidIndex):

2012-06-13  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r120172.
        http://trac.webkit.org/changeset/120172
        https://bugs.webkit.org/show_bug.cgi?id=88976

        The patch causes compilation failures on Gtk, Qt and Apple Win
        bots (Requested by zdobersek on #webkit).

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::nop):
        (JSC::ARMv7Assembler::label):
        (JSC::ARMv7Assembler::readPointer):
        (ARMv7Assembler):
        * assembler/AbstractMacroAssembler.h:
        (JSC):
        (AbstractMacroAssembler):
        (Label):
        * assembler/AssemblerBuffer.h:
        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::nop):
        (JSC::MacroAssemblerARMv7::jump):
        (JSC::MacroAssemblerARMv7::makeBranch):
        * assembler/MacroAssemblerMIPS.h:
        * assembler/MacroAssemblerSH4.h:
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::moveWithPatch):
        * assembler/MacroAssemblerX86Common.h:
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchTest8):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::cmpb_im):
        (JSC::X86Assembler::codeSize):
        (JSC::X86Assembler::label):
        (JSC::X86Assembler::X86InstructionFormatter::memoryModRM):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::appendOSRExit):
        (JSC::CodeBlock::appendSpeculationRecovery):
        (DFGData):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        (JSC::DFG::exitKindIsCountable):
        * bytecode/Instruction.h:
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/Watchpoint.cpp: Removed.
        * bytecode/Watchpoint.h: Removed.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveWithBase):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetStaticVar):
        (JSC::BytecodeGenerator::emitPutStaticVar):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixResolveNode::emitBytecode):
        (JSC::PrefixResolveNode::emitBytecode):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::clobberStructures):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArguments):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::globalVarStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGCorrectableJumpPoint.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasRegisterPointer):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::appendCallSetResult):
        (JSC::DFG::SpeculativeJIT::speculationCheck):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        * jit/JITPropertyAccess32_64.cpp:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSObject.cpp:
        (JSC::JSObject::removeDirect):
        * runtime/JSObject.h:
        (JSObject):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/SymbolTable.cpp: Removed.
        * runtime/SymbolTable.h:
        (JSC):
        (JSC::SymbolTableEntry::isNull):
        (JSC::SymbolTableEntry::getIndex):
        (SymbolTableEntry):
        (JSC::SymbolTableEntry::getAttributes):
        (JSC::SymbolTableEntry::isReadOnly):
        (JSC::SymbolTableEntry::pack):
        (JSC::SymbolTableEntry::isValidIndex):

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

        DFG should be able to set watchpoints on global variables
        https://bugs.webkit.org/show_bug.cgi?id=88692

        Reviewed by Geoffrey Garen.
        
        This implements global variable constant folding by allowing the optimizing
        compiler to set a "watchpoint" on globals that it wishes to constant fold.
        If the watchpoint fires, then an OSR exit is forced by overwriting the
        machine code that the optimizing compiler generated with a jump.
        
        As such, this patch is adding quite a bit of stuff:
        
        - Jump replacement on those hardware targets supported by the optimizing
          JIT. It is now possible to patch in a jump instruction over any recorded
          watchpoint label. The jump must be "local" in the sense that it must be
          within the range of the largest jump distance supported by a one
          instruction jump.
          
        - WatchpointSets and Watchpoints. A Watchpoint is a doubly-linked list node
          that records the location where a jump must be inserted and the
          destination to which it should jump. Watchpoints can be added to a
          WatchpointSet. The WatchpointSet can be fired all at once, which plants
          all jumps. WatchpointSet also remembers if it had ever been invalidated,
          which allows for monotonicity: we typically don't want to optimize using
          watchpoints on something for which watchpoints had previously fired. The
          act of notifying a WatchpointSet has a trivial fast path in case no
          Watchpoints are registered (one-byte load+branch).
        
        - SpeculativeJIT::speculationWatchpoint(). It's like speculationCheck(),
          except that you don't have to emit branches. But, you need to know what
          WatchpointSet to add the resulting Watchpoint to. Not everything that
          you could write a speculationCheck() for will have a WatchpointSet that
          would get notified if the condition you were speculating against became
          invalid.
          
        - SymbolTableEntry now has the ability to refer to a WatchpointSet. It can
          do so without incurring any space overhead for those entries that don't
          have WatchpointSets.
          
        - The bytecode generator infers all global function variables to be
          watchable, and makes all stores perform the WatchpointSet's write check,
          and marks all loads as being potentially watchable (i.e. you can compile
          them to a watchpoint and a constant).
        
        Put together, this allows for fully sleazy inlining of calls to globally
        declared functions. The inline prologue will no longer contain the load of
        the function, or any checks of the function you're calling. I.e. it's
        pretty much like the kind of inlining you would see in Java or C++.
        Furthermore, the watchpointing functionality is built to be fairly general,
        and should allow setting watchpoints on all sorts of interesting things
        in the future.
        
        The sleazy inlining means that we will now sometimes inline in code paths
        that have never executed. Previously, to inline we would have either had
        to have executed the call (to read the call's inline cache) or have
        executed the method check (to read the method check's inline cache). Now,
        we might inline when the callee is a watched global variable. This
        revealed some humorous bugs. First, constant folding disagreed with CFA
        over what kinds of operations can clobber (example: code path A is dead
        but stores a String into variable X, all other code paths store 0 into
        X, and then you do CompareEq(X, 0) - CFA will say that this is a non-
        clobbering constant, but constant folding thought it was clobbering
        because it saw the String prediction). Second, inlining would crash if
        the inline callee had not been compiled. This patch fixes both bugs,
        since otherwise run-javascriptcore-tests would report regressions.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::ARMv7Assembler):
        (JSC::ARMv7Assembler::labelForWatchpoint):
        (JSC::ARMv7Assembler::label):
        (JSC::ARMv7Assembler::replaceWithJump):
        (JSC::ARMv7Assembler::maxJumpReplacementSize):
        * assembler/AbstractMacroAssembler.h:
        (JSC):
        (AbstractMacroAssembler):
        (Label):
        (JSC::AbstractMacroAssembler::watchpointLabel):
        * assembler/AssemblerBuffer.h:
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::replaceWithJump):
        (MacroAssemblerARM):
        (JSC::MacroAssemblerARM::maxJumpReplacementSize):
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::replaceWithJump):
        (JSC::MacroAssemblerARMv7::maxJumpReplacementSize):
        (JSC::MacroAssemblerARMv7::branchTest8):
        (JSC::MacroAssemblerARMv7::jump):
        (JSC::MacroAssemblerARMv7::makeBranch):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::replaceWithJump):
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::maxJumpReplacementSize):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::replaceWithJump):
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::maxJumpReplacementSize):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::branchTest8):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::replaceWithJump):
        (MacroAssemblerX86Common):
        (JSC::MacroAssemblerX86Common::maxJumpReplacementSize):
        * assembler/MacroAssemblerX86_64.h:
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::branchTest8):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::X86Assembler):
        (X86Assembler):
        (JSC::X86Assembler::cmpb_im):
        (JSC::X86Assembler::testb_im):
        (JSC::X86Assembler::labelForWatchpoint):
        (JSC::X86Assembler::label):
        (JSC::X86Assembler::replaceWithJump):
        (JSC::X86Assembler::maxJumpReplacementSize):
        (JSC::X86Assembler::X86InstructionFormatter::memoryModRM):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::appendOSRExit):
        (JSC::CodeBlock::appendSpeculationRecovery):
        (CodeBlock):
        (JSC::CodeBlock::appendWatchpoint):
        (JSC::CodeBlock::numberOfWatchpoints):
        (JSC::CodeBlock::watchpoint):
        (DFGData):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        (JSC::DFG::exitKindIsCountable):
        * bytecode/Instruction.h:
        (Instruction):
        (JSC::Instruction::Instruction):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/Watchpoint.cpp: Added.
        (JSC):
        (JSC::Watchpoint::~Watchpoint):
        (JSC::Watchpoint::correctLabels):
        (JSC::Watchpoint::fire):
        (JSC::WatchpointSet::WatchpointSet):
        (JSC::WatchpointSet::~WatchpointSet):
        (JSC::WatchpointSet::add):
        (JSC::WatchpointSet::notifyWriteSlow):
        (JSC::WatchpointSet::fireAllWatchpoints):
        * bytecode/Watchpoint.h: Added.
        (JSC):
        (Watchpoint):
        (JSC::Watchpoint::Watchpoint):
        (JSC::Watchpoint::setDestination):
        (WatchpointSet):
        (JSC::WatchpointSet::isStillValid):
        (JSC::WatchpointSet::hasBeenInvalidated):
        (JSC::WatchpointSet::startWatching):
        (JSC::WatchpointSet::notifyWrite):
        (JSC::WatchpointSet::addressOfIsWatched):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveWithBase):
        (JSC::BytecodeGenerator::emitResolveWithThis):
        (JSC::BytecodeGenerator::emitGetStaticVar):
        (JSC::BytecodeGenerator::emitPutStaticVar):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixResolveNode::emitBytecode):
        (JSC::PrefixResolveNode::emitBytecode):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::clobberStructures):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        (JSC::DFG::AbstractState::didClobber):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArguments):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::globalVarWatchpointElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::globalVarStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGCorrectableJumpPoint.h:
        (JSC::DFG::CorrectableJumpPoint::isSet):
        (CorrectableJumpPoint):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifierNumberForCheck):
        (Node):
        (JSC::DFG::Node::identifierNumberForCheck):
        (JSC::DFG::Node::hasRegisterPointer):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::appendCall):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_global_var_check):
        (JSC):
        (JSC::JIT::emitSlow_op_put_global_var_check):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_global_var_check):
        (JSC):
        (JSC::JIT::emitSlow_op_put_global_var_check):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::JITThunks):
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (LLInt):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSObject.cpp:
        (JSC::JSObject::removeDirect):
        * runtime/JSObject.h:
        (JSObject):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/SymbolTable.cpp: Added.
        (JSC):
        (JSC::SymbolTableEntry::copySlow):
        (JSC::SymbolTableEntry::freeFatEntrySlow):
        (JSC::SymbolTableEntry::couldBeWatched):
        (JSC::SymbolTableEntry::attemptToWatch):
        (JSC::SymbolTableEntry::addressOfIsWatched):
        (JSC::SymbolTableEntry::addWatchpoint):
        (JSC::SymbolTableEntry::notifyWriteSlow):
        (JSC::SymbolTableEntry::inflateSlow):
        * runtime/SymbolTable.h:
        (JSC):
        (SymbolTableEntry):
        (Fast):
        (JSC::SymbolTableEntry::Fast::Fast):
        (JSC::SymbolTableEntry::Fast::isNull):
        (JSC::SymbolTableEntry::Fast::getIndex):
        (JSC::SymbolTableEntry::Fast::isReadOnly):
        (JSC::SymbolTableEntry::Fast::getAttributes):
        (JSC::SymbolTableEntry::Fast::isFat):
        (JSC::SymbolTableEntry::SymbolTableEntry):
        (JSC::SymbolTableEntry::~SymbolTableEntry):
        (JSC::SymbolTableEntry::operator=):
        (JSC::SymbolTableEntry::isNull):
        (JSC::SymbolTableEntry::getIndex):
        (JSC::SymbolTableEntry::getFast):
        (JSC::SymbolTableEntry::getAttributes):
        (JSC::SymbolTableEntry::isReadOnly):
        (JSC::SymbolTableEntry::watchpointSet):
        (JSC::SymbolTableEntry::notifyWrite):
        (FatEntry):
        (JSC::SymbolTableEntry::FatEntry::FatEntry):
        (JSC::SymbolTableEntry::isFat):
        (JSC::SymbolTableEntry::fatEntry):
        (JSC::SymbolTableEntry::inflate):
        (JSC::SymbolTableEntry::bits):
        (JSC::SymbolTableEntry::freeFatEntry):
        (JSC::SymbolTableEntry::pack):
        (JSC::SymbolTableEntry::isValidIndex):

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

        Unreviewed build fix for ARMv7 debug builds.

        * jit/JITStubs.cpp:
        (JSC::JITThunks::JITThunks):

2012-06-12  Geoffrey Garen  <ggaren@apple.com>

        Build fix for case-sensitive file systems: use the right case.

        * heap/ListableHandler.h:

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

        GC should be 1.7X faster
        https://bugs.webkit.org/show_bug.cgi?id=88840

        Reviewed by Oliver Hunt.

        I profiled, and removed anything that showed up as a concurrency
        bottleneck. Then, I added 3 threads to our max thread count, since we
        can scale up to more threads now.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::BlockAllocator):
        (JSC::BlockAllocator::~BlockAllocator):
        (JSC::BlockAllocator::releaseFreeBlocks):
        (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock):
        (JSC::BlockAllocator::waitForRelativeTime):
        (JSC::BlockAllocator::blockFreeingThreadMain):
        * heap/BlockAllocator.h:
        (BlockAllocator):
        (JSC::BlockAllocator::allocate):
        (JSC::BlockAllocator::deallocate): Use a spin lock for the common case
        where we're just popping a linked list. (A pthread mutex would sleep our
        thread even if the lock were only contended for a microsecond.) 

        Scope the lock to avoid holding it while allocating VM, since that's a
        slow activity and it doesn't modify any of our data structures.

        We still use a pthread mutex to handle our condition variable since we
        have to, and it's not a hot path.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::CopiedSpace):
        (JSC::CopiedSpace::doneFillingBlock):
        * heap/CopiedSpace.h:
        (JSC::CopiedSpace::CopiedSpace): Use a spin lock for the to space lock,
        since it just guards linked list and hash table manipulation.

        * heap/MarkStack.cpp:
        (JSC::MarkStackSegmentAllocator::MarkStackSegmentAllocator):
        (JSC::MarkStackSegmentAllocator::allocate):
        (JSC::MarkStackSegmentAllocator::release):
        (JSC::MarkStackSegmentAllocator::shrinkReserve): Use a spin lock, since
        we're just managing a linked list.

        (JSC::MarkStackArray::donateSomeCellsTo): Changed donation to be proportional
        to our current stack size. This fixes cases where we used to donate too
        much. Interestingly, donating too much was starving the donor (when it
        ran out of work later) *and* the recipient (since it had to wait on a
        long donation operation to complete before it could acquire the lock).

        In the worst case, we're still guaranteed to donate N cells in roughly log N time.

        This change also fixes cases where we used to donate too little, since
        we would always keep a fixed minimum number of cells. In the worst case,
        with N marking threads, would could have N large object graph roots in
        our stack for the duration of GC, and scale to only 1 thread.

        It's an interesting observation that a single object in the mark stack
        might represent an arbitrarily large object graph -- and only the act
        of marking can find out.

        (JSC::MarkStackArray::stealSomeCellsFrom): Steal in proportion to idle
        threads. Once again, this fixes cases where constants could cause us
        to steal too much or too little.

        (JSC::SlotVisitor::donateKnownParallel): Always wake up other threads
        if they're idle. We can afford to do this because we're conservative
        about when we donate.

        (JSC::SlotVisitor::drainFromShared):
        * heap/MarkStack.h:
        (MarkStackSegmentAllocator):
        (MarkStackArray):
        (JSC):
        * heap/SlotVisitor.h: Merged the "should I donate?" decision into a
        single function, for simplicity.

        * runtime/Options.cpp:
        (minimumNumberOfScansBetweenRebalance): Reduced the delay before donation
        a lot. We can afford to do this because, in the common case, donation is
        a single branch that decides not to donate. 

        (cpusToUse): Use more CPUs now, since we scale better now.

        * runtime/Options.h:
        (Options): Removed now-unused variables.

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

        REGRESSION(120121): inspector tests crash in DFG
        https://bugs.webkit.org/show_bug.cgi?id=88941

        Reviewed by Geoffrey Garen.
        
        The CFG simplifier has two different ways of fixing up GetLocal, Phantom, and Flush. If we've
        already fixed up the node one way, we shouldn't try the other way. The reason why we shouldn't
        is that the second way depends on the node referring to other nodes in the to-be-jettisoned
        block. After fixup they potentially will refer to nodes in the block being merged to.

        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):

2012-06-12  Leo Yang  <leo.yang@torchmobile.com.cn>

        Dynamic hash table in DOMObjectHashTableMap is wrong in multiple threads
        https://bugs.webkit.org/show_bug.cgi?id=87334

        Reviewed by Geoffrey Garen.

        Add a copy member function to JSC::HasTable. This function will copy all data
        members except for *table* which contains thread specific data that prevents
        up copying it. When you want to copy a JSC::HashTable that was constructed
        on another thread you should call JSC::HashTable::copy().

        * runtime/Lookup.h:
        (JSC::HashTable::copy):
        (HashTable):

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

        DFG should not ASSERT if you have a double use of a variable that is not revealed to be a double
        until after CFG simplification
        https://bugs.webkit.org/show_bug.cgi?id=88927
        <rdar://problem/11513971>

        Reviewed by Geoffrey Garen.
        
        Speculation fixup needs to run if simplification did things, because simplification can change
        predictions - particularly if you had a control flow path that stored weird things into a
        variable, but that path got axed by the simplifier.
        
        Running fixup in the fixpoint requires making it idempotent, which it previously wasn't. Only
        one place needed to be changed, namely the un-MustGenerate-ion of ValueToInt32.

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

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

        REGRESSION (r119779): Javascript TypeError: 'undefined' is not an object
        https://bugs.webkit.org/show_bug.cgi?id=88783
        <rdar://problem/11640299>

        Reviewed by Geoffrey Garen.
        
        If you don't keep alive the base of an object access over the various checks
        you do for the prototype chain, you're going to have a bad time.

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

2012-06-12  Hojong Han  <hojong.han@samsung.com>

        Property names of the built-in object cannot be retrieved 
        after trying to delete one of its properties
        https://bugs.webkit.org/show_bug.cgi?id=86461

        Reviewed by Gavin Barraclough.

        * runtime/JSObject.cpp:
        (JSC::getClassPropertyNames):
        (JSC::JSObject::getOwnPropertyNames):

2012-06-11  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        [CMAKE][EFL] Remove duplicated executable output path
        https://bugs.webkit.org/show_bug.cgi?id=88765

        Reviewed by Daniel Bates.

        CMake files for EFL port have redefined executable output path. However, EFL port doesn't
        need to define again because it is already defined in top-level CMake file.

        * shell/CMakeLists.txt:

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

        Unreviewed. Fix make distcheck issues.

        * GNUmakefile.list.am: Remove non existent header file.

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

        Unreviewed. Build fix for !ENABLE(JIT) after r119844 and r119925.

        * runtime/Executable.h:
        (ExecutableBase):
        (JSC::ExecutableBase::clearCodeVirtual):

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

        Unreviewed. Build fix for !ENABLE(JIT) after r119844.

        * runtime/Executable.h:
        (ExecutableBase):
        (JSC):

2012-06-09  Dominic Cooney  <dominicc@chromium.org>

        [Chromium] Remove JavaScriptCore dependencies from gyp
        https://bugs.webkit.org/show_bug.cgi?id=88510

        Reviewed by Adam Barth.

        Chromium doesn't support JSC any more and there doesn't seem to be
        a strong interest in using GYP as the common build system in other
        ports.

        * JavaScriptCore.gyp/JavaScriptCore.gyp: WebCore still depends on YARR interpreter.
        * JavaScriptCore.gypi: Only include YARR source.
        * gyp/JavaScriptCore.gyp: Removed.
        * gyp/gtk.gyp: Removed.

2012-06-09  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in part2 of r118646.

        This patch removes eager finalization.

        Weak pointer finalization should be lazy
        https://bugs.webkit.org/show_bug.cgi?id=87599

        Reviewed by Sam Weinig.

        * heap/Heap.cpp:
        (JSC::Heap::collect): Don't finalize eagerly -- we'll do it lazily.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep): Do sweep weak sets when sweeping a block,
        since we won't get another chance.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::sweepWeakSet):
        * heap/MarkedSpace.cpp:
        (MarkedSpace::WeakSetSweep):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::sweepWeakSets): Removed now-unused code.

2012-06-09  Sukolsak Sakshuwong  <sukolsak@google.com>

        Add UNDO_MANAGER flag
        https://bugs.webkit.org/show_bug.cgi?id=87908

        Reviewed by Tony Chang.

        * Configurations/FeatureDefines.xcconfig:

2012-06-08  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in part1 of r118646.

        This patch includes everything necessary for lazy finalization, but
        keeps eager finalization enabled for the time being.

        Weak pointer finalization should be lazy
        https://bugs.webkit.org/show_bug.cgi?id=87599

        Reviewed by Sam Weinig.

        * heap/MarkedBlock.cpp:
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::resetAllocator):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::resetAllocators):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::resetAllocators): Don't force allocator reset anymore.
        It will happen automatically when a weak set is swept. It's simpler to
        have only one canonical way for this to happen, and it wasn't buying
        us anything to do it eagerly.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::sweep): Don't short-circuit a sweep unless we know
        the sweep would be a no-op. If even one finalizer is pending, we need to
        run it, since we won't get another chance.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep): This loop can be simpler now that
        WeakBlock::sweep() does what we mean.
        Reset our allocator after a sweep because this is the optimal time to
        start trying to recycle old weak pointers.
        (JSC::WeakSet::tryFindAllocator): Don't sweep when searching for an
        allocator because we've swept already, and forcing a new sweep would be
        wasteful.
        * heap/WeakSet.h:
        (JSC::WeakSet::shrink): Be sure to reset our allocator after a shrink
        because the shrink may have removed the block the allocator was going to
        allocate out of.

2012-06-08  Gavin Barraclough  <barraclough@apple.com>

        Unreviewed roll out r119795.
        
        This broke jquery/core.html

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        * llint/LowLevelInterpreter.asm:
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSGlobalThis.cpp:
        (JSC::JSGlobalThis::setUnwrappedObject):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::createInheritorID):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::resetInheritorID):
        (JSC):
        (JSC::JSObject::offsetOfInheritorID):
        (JSC::JSObject::inheritorID):

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

        PredictedType should be called SpeculatedType
        https://bugs.webkit.org/show_bug.cgi?id=88477

        Unreviewed, fix a renaming goof from http://trac.webkit.org/changeset/119660.
        I accidentally renamed ByteCodeParser::getPrediction to
        ByteCodeParser::getSpeculation.  That was not the intent. This changes it
        back.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getPrediction):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::parseBlock):

2012-06-08  Andy Wingo  <wingo@igalia.com>

        Explictly mark stubs called by JIT as being internal
        https://bugs.webkit.org/show_bug.cgi?id=88552

        Reviewed by Filip Pizlo.

        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * jit/HostCallReturnValue.h:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * jit/ThunkGenerators.cpp:
        * llint/LLIntSlowPaths.h: Mark a bunch of stubs as being
        WTF_INTERNAL.  Change most calls to SYMBOL_STRING_RELOCATION to
        LOCAL_REFERENCE, or GLOBAL_REFERENCE in the case of the wrappers
        to truly global symbols.
        * offlineasm/asm.rb: Generate LOCAL_REFERENCE instead of
        SYMBOL_STRING_RELOCATION.

2012-06-08  Geoffrey Garen  <ggaren@apple.com>

        Don't rely on weak pointers for eager CodeBlock finalization
        https://bugs.webkit.org/show_bug.cgi?id=88465

        Reviewed by Gavin Barraclough.

        This is incompatible with lazy weak pointer finalization.

        I considered just making CodeBlock finalization lazy-friendly, but it
        turns out that the heap is already way up in CodeBlock's business when
        it comes to finalization, so I decided to finish the job and move full
        responsibility for CodeBlock finalization into the heap.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Maybe this
        will build.

        * debugger/Debugger.cpp: Updated for rename.

        * heap/Heap.cpp:
        (JSC::Heap::deleteAllCompiledCode): Renamed for consistency. Fixed a bug
        where we would not delete code for a code block that had been previously
        jettisoned. I don't know if this happens in practice -- I mostly did
        this to improve consistency with deleteUnmarkedCompiledCode.

        (JSC::Heap::deleteUnmarkedCompiledCode): New function, responsible for
        eager finalization of unmarked code blocks.

        (JSC::Heap::collect): Updated for rename. Updated to call
        deleteUnmarkedCompiledCode(), which takes care of jettisoned DFG code
        blocks too.

        (JSC::Heap::addCompiledCode): Renamed, since this points to all code
        now, not just functions.

        * heap/Heap.h:
        (Heap): Keep track of all user code, not just functions. This is a
        negligible additional overhead, since most code is function code.

        * runtime/Executable.cpp:
        (JSC::*::finalize): Removed these functions, since we don't rely on
        weak pointer finalization anymore.

        (JSC::FunctionExecutable::FunctionExecutable): Moved linked-list stuff
        into base class so all executables can be in the list.

        (JSC::EvalExecutable::clearCode):
        (JSC::ProgramExecutable::clearCode):
        (JSC::FunctionExecutable::clearCode): All we need to do is delete our
        CodeBlock -- that will delete all of its internal data structures.

        (JSC::FunctionExecutable::clearCodeIfNotCompiling): Factored out a helper
        function to improve clarity.

        * runtime/Executable.h:
        (JSC::ExecutableBase): Moved linked-list stuff
        into base class so all executables can be in the list.

        (JSC::NativeExecutable::create):
        (NativeExecutable):
        (ScriptExecutable):
        (JSC::ScriptExecutable::finishCreation):
        (JSC::EvalExecutable::create):
        (EvalExecutable):
        (JSC::ProgramExecutable::create):
        (ProgramExecutable):
        (FunctionExecutable):
        (JSC::FunctionExecutable::create): Don't use a finalizer -- the heap
        will call us back to destroy our code block.

        (JSC::FunctionExecutable::discardCode): Renamed to clearCodeIfNotCompiling()
        for clarity.

        (JSC::FunctionExecutable::isCompiling): New helper function, for clarity.

        (JSC::ScriptExecutable::clearCodeVirtual): New helper function, since
        the heap needs to make polymorphic calls to clear code.

        * runtime/JSGlobalData.cpp:
        (JSC::StackPreservingRecompiler::operator()):
        * runtime/JSGlobalObject.cpp:
        (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): Updated for
        renames.

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

        DFG should inline prototype chain accesses, and do the right things if the
        specific function optimization is available
        https://bugs.webkit.org/show_bug.cgi?id=88594

        Reviewed by Gavin Barraclough.
        
        Looks like a 3% win on V8.

        * bytecode/CodeBlock.h:
        (JSC::Structure::prototypeForLookup):
        (JSC):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC):
        (JSC::GetByIdStatus::computeForChain):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):
        (JSC::GetByIdStatus::isSimple):
        (JSC::GetByIdStatus::chain):
        (JSC::GetByIdStatus::specificValue):
        (GetByIdStatus):
        * bytecode/StructureSet.h:
        (StructureSet):
        (JSC::StructureSet::singletonStructure):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::initGetByIdProto):
        (JSC::StructureStubInfo::initGetByIdChain):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetById):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::tryCacheGetByID):
        * runtime/JSGlobalObject.h:
        (JSC::Structure::prototypeForLookup):
        (JSC):
        * runtime/Structure.h:
        (Structure):

2012-06-07  Gavin Barraclough  <barraclough@apple.com>

        Remove JSObject::m_inheritorID
        https://bugs.webkit.org/show_bug.cgi?id=88378

        Reviewed by Geoff Garen.

        This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction),
        and most objects don't need an inheritorID (this value is only used if the object is used as a prototype).
        Instead use a private named value in the object's property storage.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
            - No need m_inheritorID to initialize!
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
            - No need m_inheritorID to initialize!
        * llint/LowLevelInterpreter.asm:
            - No need m_inheritorID to initialize!
        * runtime/JSGlobalData.h:
        (JSGlobalData):
            - Added private name 'm_inheritorIDKey'.
        * runtime/JSGlobalThis.cpp:
        (JSC::JSGlobalThis::setUnwrappedObject):
            - resetInheritorID is now passed a JSGlobalData&.
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
            - No m_inheritorID to be marked.
        (JSC::JSObject::createInheritorID):
            - Store the newly created inheritorID in the property map.
        * runtime/JSObject.h:
        (JSC::JSObject::resetInheritorID):
            - Remove the inheritorID from property storage.
        (JSC::JSObject::inheritorID):
            - Read the inheritorID from property storage.

2012-06-07  Gavin Barraclough  <barraclough@apple.com>

        Math.pow on iOS does not support denormal numbers.
        https://bugs.webkit.org/show_bug.cgi?id=88592

        Reviewed by Filip Pizlo.

        Import an implementation from fdlibm, detect cases where it is safe to use the system
        implementation & where we should fall back to fdlibm.

        * runtime/MathObject.cpp:
        (JSC::isDenormal):
        (JSC::isEdgeCase):
        (JSC::mathPow):
            - On iOS, detect cases where denormal support may be required & use fdlibm in these cases.
        (JSC::mathProtoFuncPow):
            - Changed to use mathPow.
        (JSC::fdlibmScalbn):
        (JSC::fdlibmPow):
            - These functions imported from fdlibm; original style retained to ease future merging.

2012-06-07  Patrick Gansterer  <paroga@webkit.org>

        Unreviewed. Build fix for !ENABLE(JIT) after r119441.

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

2012-06-07  Andy Wingo  <wingo@igalia.com>

        Unreviewed build fix after r119593.

        * llint/LLIntOfflineAsmConfig.h (OFFLINE_ASM_GLOBAL_LABEL): Fix
        uses of "name" to be "label", the macro's parameter.  Otherwise we
        serialize mentions of the literal symbol "name" into the objcode.
        Causes a build error using GNU ld (not gold).

2012-06-06  Ryosuke Niwa  <rniwa@webkit.org>

        Chromium build fix attempt. Why do we need to list these files in gyp!?

        * JavaScriptCore.gypi:

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

        PredictedType should be called SpeculatedType
        https://bugs.webkit.org/show_bug.cgi?id=88477

        Rubber stamped by Gavin Barraclough.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shouldOptimizeNow):
        (JSC::CodeBlock::dumpValueProfiles):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::LazyOperandValueProfileParser::prediction):
        * bytecode/LazyOperandValueProfile.h:
        (LazyOperandValueProfileParser):
        * bytecode/PredictedType.cpp: Removed.
        * bytecode/PredictedType.h: Removed.
        * bytecode/SpeculatedType.cpp: Copied from Source/JavaScriptCore/bytecode/PredictedType.cpp.
        (JSC::speculationToString):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromClassInfo):
        (JSC::speculationFromStructure):
        (JSC::speculationFromCell):
        (JSC::speculationFromValue):
        * bytecode/SpeculatedType.h: Copied from Source/JavaScriptCore/bytecode/PredictedType.h.
        (JSC):
        (JSC::isAnySpeculation):
        (JSC::isCellSpeculation):
        (JSC::isObjectSpeculation):
        (JSC::isFinalObjectSpeculation):
        (JSC::isFinalObjectOrOtherSpeculation):
        (JSC::isFixedIndexedStorageObjectSpeculation):
        (JSC::isStringSpeculation):
        (JSC::isArraySpeculation):
        (JSC::isFunctionSpeculation):
        (JSC::isInt8ArraySpeculation):
        (JSC::isInt16ArraySpeculation):
        (JSC::isInt32ArraySpeculation):
        (JSC::isUint8ArraySpeculation):
        (JSC::isUint8ClampedArraySpeculation):
        (JSC::isUint16ArraySpeculation):
        (JSC::isUint32ArraySpeculation):
        (JSC::isFloat32ArraySpeculation):
        (JSC::isFloat64ArraySpeculation):
        (JSC::isArgumentsSpeculation):
        (JSC::isActionableIntMutableArraySpeculation):
        (JSC::isActionableFloatMutableArraySpeculation):
        (JSC::isActionableTypedMutableArraySpeculation):
        (JSC::isActionableMutableArraySpeculation):
        (JSC::isActionableArraySpeculation):
        (JSC::isArrayOrOtherSpeculation):
        (JSC::isMyArgumentsSpeculation):
        (JSC::isInt32Speculation):
        (JSC::isDoubleRealSpeculation):
        (JSC::isDoubleSpeculation):
        (JSC::isNumberSpeculation):
        (JSC::isBooleanSpeculation):
        (JSC::isOtherSpeculation):
        (JSC::isEmptySpeculation):
        (JSC::mergeSpeculations):
        (JSC::mergeSpeculation):
        * bytecode/StructureSet.h:
        (JSC::StructureSet::speculationFromStructures):
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::ValueProfileBase):
        (JSC::ValueProfileBase::dump):
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        (ValueProfileBase):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::mergeStateAtTail):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::speculateInt32Unary):
        (JSC::DFG::AbstractState::speculateNumberUnary):
        (JSC::DFG::AbstractState::speculateBooleanUnary):
        (JSC::DFG::AbstractState::speculateInt32Binary):
        (JSC::DFG::AbstractState::speculateNumberBinary):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::filter):
        (JSC::DFG::StructureAbstractValue::speculationFromStructures):
        (JSC::DFG::AbstractValue::AbstractValue):
        (JSC::DFG::AbstractValue::clear):
        (JSC::DFG::AbstractValue::isClear):
        (JSC::DFG::AbstractValue::makeTop):
        (JSC::DFG::AbstractValue::clobberStructures):
        (JSC::DFG::AbstractValue::isTop):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::merge):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::validateIgnoringValue):
        (JSC::DFG::AbstractValue::validate):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::dump):
        (AbstractValue):
        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::ArgumentPosition):
        (JSC::DFG::ArgumentPosition::mergeArgumentAwareness):
        (JSC::DFG::ArgumentPosition::prediction):
        (ArgumentPosition):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getSpeculationWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getSpeculation):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::fixVariableAccessSpeculations):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixDoubleEdge):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::nameOfVariableAccessData):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::predictArgumentTypes):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::getJSConstantSpeculation):
        (JSC::DFG::Graph::isPredictedNumerical):
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::getSpeculation):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::getHeapPrediction):
        (JSC::DFG::Node::predictHeap):
        (JSC::DFG::Node::prediction):
        (JSC::DFG::Node::predict):
        (JSC::DFG::Node::shouldSpeculateInteger):
        (JSC::DFG::Node::shouldSpeculateDouble):
        (JSC::DFG::Node::shouldSpeculateNumber):
        (JSC::DFG::Node::shouldSpeculateBoolean):
        (JSC::DFG::Node::shouldSpeculateFinalObject):
        (JSC::DFG::Node::shouldSpeculateFinalObjectOrOther):
        (JSC::DFG::Node::shouldSpeculateArray):
        (JSC::DFG::Node::shouldSpeculateArguments):
        (JSC::DFG::Node::shouldSpeculateInt8Array):
        (JSC::DFG::Node::shouldSpeculateInt16Array):
        (JSC::DFG::Node::shouldSpeculateInt32Array):
        (JSC::DFG::Node::shouldSpeculateUint8Array):
        (JSC::DFG::Node::shouldSpeculateUint8ClampedArray):
        (JSC::DFG::Node::shouldSpeculateUint16Array):
        (JSC::DFG::Node::shouldSpeculateUint32Array):
        (JSC::DFG::Node::shouldSpeculateFloat32Array):
        (JSC::DFG::Node::shouldSpeculateFloat64Array):
        (JSC::DFG::Node::shouldSpeculateArrayOrOther):
        (JSC::DFG::Node::shouldSpeculateObject):
        (JSC::DFG::Node::shouldSpeculateCell):
        (Node):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::setPrediction):
        (JSC::DFG::PredictionPropagationPhase::mergePrediction):
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::fillStorage):
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        (JSC::DFG::GPRTemporary::GPRTemporary):
        (JSC::DFG::FPRTemporary::FPRTemporary):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
        (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayLength):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        (JSC::DFG::SpeculativeJIT::compileAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        (JSC::DFG::SpeculativeJIT::compileRegExpExec):
        * dfg/DFGSpeculativeJIT.h:
        (DFG):
        (JSC::DFG::ValueSource::forSpeculation):
        (SpeculativeJIT):
        (GPRTemporary):
        (FPRTemporary):
        (JSC::DFG::SpecDoubleOperand::SpecDoubleOperand):
        (JSC::DFG::SpecDoubleOperand::~SpecDoubleOperand):
        (JSC::DFG::SpecDoubleOperand::fpr):
        (JSC::DFG::SpecCellOperand::SpecCellOperand):
        (JSC::DFG::SpecCellOperand::~SpecCellOperand):
        (JSC::DFG::SpecCellOperand::gpr):
        (JSC::DFG::SpecBooleanOperand::SpecBooleanOperand):
        (JSC::DFG::SpecBooleanOperand::~SpecBooleanOperand):
        (JSC::DFG::SpecBooleanOperand::gpr):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpecDouble):
        (JSC::DFG::SpeculativeJIT::fillSpecCell):
        (JSC::DFG::SpeculativeJIT::fillSpecBoolean):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileDoubleCompare):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpecDouble):
        (JSC::DFG::SpeculativeJIT::fillSpecCell):
        (JSC::DFG::SpeculativeJIT::fillSpecBoolean):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileDoubleCompare):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::VariableAccessData):
        (JSC::DFG::VariableAccessData::predict):
        (JSC::DFG::VariableAccessData::nonUnifiedPrediction):
        (JSC::DFG::VariableAccessData::prediction):
        (JSC::DFG::VariableAccessData::argumentAwarePrediction):
        (JSC::DFG::VariableAccessData::mergeArgumentAwarePrediction):
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
        (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
        (VariableAccessData):

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

        Global object variable accesses should not require an extra load
        https://bugs.webkit.org/show_bug.cgi?id=88385

        Reviewed by Gavin Barraclough and Geoffrey Garen.
        
        Previously, if you wanted to access a global variable, you'd first have
        to load the register array from the appropriate global object and then
        either load or store at an offset to the register array. This is because
        JSGlobalObject inherited from JSVariableObject, and JSVariableObject is
        designed with the pessimistic assumption that its register array may
        point into the call stack. This is never the case for global objects.
        Hence, even though the global object may add more registers at any time,
        it does not need to store them in a contiguous array. It can use a
        SegmentedVector or similar.
        
        This patch refactors global objects and variable objects as follows:
        
        - The functionality to track variables in an indexable array using a
          SymbolTable to map names to indices is moved into JSSymbolTableObject,
          which is now a supertype of JSVariableObject. JSVariableObject is now
          just a holder for a registers array and implements the registerAt()
          method that is left abstract in JSSymbolTableObject. Because all users
          of JSVariableObject know whether they are a JSStaticScopeObject,
          JSActivation, or JSGlobalObject, this "abstract" method is not virtual;
          instead the utility methods that would call registerAt() are now
          template functions that require you to know statically what subtype of
          JSSymbolTableObject you're using (JSVariableObject or something else),
          so that registerAt() can be statically bound.
        
        - A new class is added called JSSegmentedVariableObject, which only
          differs from JSVariableObject in how it allocates registers. It uses a
          SegmentedVector instead of manually managing a pointer to a contiguous
          slab of registers. This changes the interface somewhat; for example
          with JSVariableObject if you wanted to add a register you had to do
          it yourself since the JSVariableObject didn't know how the registers
          array ought to be allocated. With JSSegmentedVariableObject you can
          just call addRegisters(). JSSegmentedVariableObject preserves the
          invariant that once you get a pointer into a register, that pointer
          will continue to be valid so long as the JSSegmentedVariableObject is
          alive. This allows the JITs and interpreters to skip the extra load.
        
        - JSGlobalObject now inherits from JSSegmentedVariableObject. For now
          (and possibly forever) it is the only subtype of this new class.
        
        - The bytecode format is changed so that get_global_var and
          put_global_var have a pointer to the register directly rather than
          having an index. A convenience method is provided in
          JSSegmentedVariableObject to get the index given a a pointer, which is
          used for assertions and debug dumps.
        
        This appears to be a 1% across the board win.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Instruction.h:
        (Instruction):
        (JSC::Instruction::Instruction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::registerPointer):
        (JSC):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::retrieveLastUnaryOp):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::emitGetStaticVar):
        (JSC::BytecodeGenerator::emitPutStaticVar):
        * bytecompiler/BytecodeGenerator.h:
        (ResolveResult):
        (BytecodeGenerator):
        * dfg/DFGAssemblyHelpers.h:
        (AssemblyHelpers):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::globalVarLoadElimination):
        (JSC::DFG::CSEPhase::globalVarStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::globalObjectFor):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasVarNumber):
        (Node):
        (JSC::DFG::Node::hasRegisterPointer):
        (JSC::DFG::Node::registerPointer):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * heap/Heap.h:
        (Heap):
        (JSC::Heap::isWriteBarrierEnabled):
        (JSC):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::privateExecute):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_global_var):
        (JSC::JIT::emit_op_put_global_var):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_global_var):
        (JSC::JIT::emit_op_put_global_var):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSGlobalObject.cpp:
        (JSC):
        (JSC::JSGlobalObject::put):
        (JSC::JSGlobalObject::putDirectVirtual):
        (JSC::JSGlobalObject::defineOwnProperty):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::addStaticGlobals):
        (JSC::JSGlobalObject::getOwnPropertySlot):
        (JSC::JSGlobalObject::getOwnPropertyDescriptor):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC):
        (JSC::JSGlobalObject::hasOwnPropertyForWrite):
        * runtime/JSSegmentedVariableObject.cpp: Added.
        (JSC):
        (JSC::JSSegmentedVariableObject::findRegisterIndex):
        (JSC::JSSegmentedVariableObject::addRegisters):
        (JSC::JSSegmentedVariableObject::visitChildren):
        * runtime/JSSegmentedVariableObject.h: Added.
        (JSC):
        (JSSegmentedVariableObject):
        (JSC::JSSegmentedVariableObject::registerAt):
        (JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject):
        (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
        (JSC::JSSegmentedVariableObject::finishCreation):
        * runtime/JSStaticScopeObject.cpp:
        (JSC::JSStaticScopeObject::put):
        (JSC::JSStaticScopeObject::putDirectVirtual):
        (JSC::JSStaticScopeObject::getOwnPropertySlot):
        * runtime/JSSymbolTableObject.cpp: Added.
        (JSC):
        (JSC::JSSymbolTableObject::destroy):
        (JSC::JSSymbolTableObject::deleteProperty):
        (JSC::JSSymbolTableObject::getOwnPropertyNames):
        (JSC::JSSymbolTableObject::putDirectVirtual):
        (JSC::JSSymbolTableObject::isDynamicScope):
        * runtime/JSSymbolTableObject.h: Added.
        (JSC):
        (JSSymbolTableObject):
        (JSC::JSSymbolTableObject::symbolTable):
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        (JSC::JSSymbolTableObject::finishCreation):
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/JSVariableObject.cpp:
        (JSC):
        * runtime/JSVariableObject.h:
        (JSVariableObject):
        (JSC::JSVariableObject::JSVariableObject):
        (JSC::JSVariableObject::finishCreation):
        (JSC):
        * runtime/WriteBarrier.h:

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

        DFG arguments access slow path should not crash if the arguments haven't been created
        https://bugs.webkit.org/show_bug.cgi?id=88471

        Reviewed by Gavin Barraclough.

        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * 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-06-06  Michael Saboff  <msaboff@apple.com>

        ENH: Add Logging to GC Marking Phase
        https://bugs.webkit.org/show_bug.cgi?id=88364

        Reviewed by Filip Pizlo.

        Log GC marking to stderr or a file.  The logging in controlled
        with the define ENABLE_OBJECT_MARK_LOGGING in wtf/Platform.h.
        If DATA_LOG_TO_FILE in wtf/DataLog.cpp is set to 1, output is
        logged to a file otherwise it is logged to stderr.

        When logging is enabled, the GC is built single threaded since the
        log output from the various threads isn't buffered and output in a
        thread safe manner.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        * heap/MarkStack.cpp:
        (JSC::MarkStackThreadSharedData::resetChildren):
        (JSC::MarkStackThreadSharedData::childVisitCount):
        (JSC::MarkStackThreadSharedData::markingThreadMain):
        (JSC::MarkStackThreadSharedData::markingThreadStartFunc):
        (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData):
        (JSC::MarkStackThreadSharedData::reset):
        * heap/MarkStack.h:
        (MarkStackThreadSharedData):
        (MarkStack):
        (JSC::MarkStack::sharedData):
        (JSC::MarkStack::resetChildCount):
        (JSC::MarkStack::childCount):
        (JSC::MarkStack::incrementChildCount):
        * runtime/JSArray.cpp:
        (JSC::JSArray::visitChildren):
        * runtime/JSCell.cpp:
        (JSC::JSCell::className):
        * runtime/JSCell.h:
        (JSCell):
        (JSC::JSCell::visitChildren):
        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren):
        * runtime/JSString.h:
        (JSString):
        * runtime/Structure.h:
        (JSC::MarkStack::internalAppend):

2012-06-06  Gavin Barraclough  <barraclough@apple.com>

        Assigning to a static property should not change iteration order
        https://bugs.webkit.org/show_bug.cgi?id=88401

        Reviewed by Geoff Garen.

        A specific iteration order is not defined by the spec, but test-262 somewhat tenuously
        requires that it is at least stable, e.g. ch10/10.4/10.4.2/S10.4.2_A1.1_T1.js

        Whilst it is not clear that this behavior really arises from the specification, it
        would seem like common sense to conform to this.

        The problem here is that we allow properties in the structure to shadow those in the
        static table, and we iterate the properties in the structure first - which means that
        as values of existing properties are modified, their iteration order changes too.

        The easy fix is to iterate the properties from the static table first. This has a
        further benefit, since it will mean that user added properties will come after those
        present in the static table (respected the expected insertion-order).

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyNames):
            - Iterate static properties first.

2012-06-06  Andy Wingo  <wingo@igalia.com>

        Ensure consistent order of evaluation in LLInt slow paths
        https://bugs.webkit.org/show_bug.cgi?id=88409

        Reviewed by Geoffrey Garen.

        * llint/LLIntSlowPaths.cpp:
        (slow_path_mul)
        (slow_path_sub)
        (slow_path_div)
        (slow_path_mod)
        (slow_path_lshift)
        (slow_path_rshift)
        (slow_path_urshift)
        (slow_path_bitand)
        (slow_path_bitor)
        (slow_path_bitxor): Avoid calling toNumber, toInt32, or toUInt32
        multiple times without intervening sequence points.  Fixes
        fast/js/exception-sequencing-binops.html with GCC 4.7 on x86-64
        Linux, which reordered evaluation of the arguments to fmod.

2012-06-06  Andy Wingo  <wingo@igalia.com>

        [GTK] Enable the LLInt
        https://bugs.webkit.org/show_bug.cgi?id=88315

        Reviewed by Filip Pizlo.

        * GNUmakefile.am: Add rules to generate LLIntDesiredOffsets.h and
        LLIntAssembly.h.
        * GNUmakefile.list.am: Add offlineasm and llint files to the
        dist.  Add LLInt source files to the build.
        * llint/LowLevelInterpreter.asm (crash): Generate a store of
        0xbbadbeef to a register, not to a constant.  Otherwise, gas was
        failing to assemble result.
        * offlineasm/asm.rb (labelReference): Generate a
        SYMBOL_STRING_RELOCATION instead of a SYMBOL_STRING, so that we go
        through the PLT on ELF systems.

2012-06-06  Andy Wingo  <wingo@igalia.com>

        REGRESSION (r106478): None of the Paper.js JavaScript examples work
        https://bugs.webkit.org/show_bug.cgi?id=87158

        Reviewed by Michael Saboff.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::resolve): If we have to bail out to
        dynamicResolve(), only skip static scopes from the head of the
        scope chain.  Before, we were also skipping activations with
        direct eval as well, which was incorrect.

2012-06-06  Dan Bernstein  <mitz@apple.com>

        Reverted r119567, the fix for <http://webkit.org/b/88378>, because it broke the 32-bit build.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        * llint/LowLevelInterpreter.asm:
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSGlobalThis.cpp:
        (JSC::JSGlobalThis::setUnwrappedObject):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::createInheritorID):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::resetInheritorID):
        (JSC):
        (JSC::JSObject::offsetOfInheritorID):
        (JSC::JSObject::inheritorID):

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

        Improve Math.round and Math.floor intrinsic
        https://bugs.webkit.org/show_bug.cgi?id=88314

        Reviewed by Filip Pizlo.

        Currently we call a native function from the JIT code to complete the
        "round" and "floor" operations. We could inline some fast paths
        especially for those positive values on the platforms where floating
        point truncation is supported.
        This brings 3% gain on Kraken, especially 32% on audio-oscillator,
        and slight win on SunSpider, measured on IA32.

        * jit/ThunkGenerators.cpp:
        (JSC::floorThunkGenerator):
        (JSC):
        (JSC::roundThunkGenerator):

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

        Remove JSObject::m_inheritorID
        https://bugs.webkit.org/show_bug.cgi?id=88378

        Reviewed by Geoff Garen.

        This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction),
        and most objects don't need an inheritorID (this value is only used if the object is used as a prototype).
        Instead use a private named value in the object's property storage.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
            - No need m_inheritorID to initialize!
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
            - No need m_inheritorID to initialize!
        * llint/LowLevelInterpreter.asm:
            - No need m_inheritorID to initialize!
        * runtime/JSGlobalData.h:
        (JSGlobalData):
            - Added private name 'm_inheritorIDKey'.
        * runtime/JSGlobalThis.cpp:
        (JSC::JSGlobalThis::setUnwrappedObject):
            - resetInheritorID is now passed a JSGlobalData&.
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
            - No m_inheritorID to be marked.
        (JSC::JSObject::createInheritorID):
            - Store the newly created inheritorID in the property map.
        * runtime/JSObject.h:
        (JSC::JSObject::resetInheritorID):
            - Remove the inheritorID from property storage.
        (JSC::JSObject::inheritorID):
            - Read the inheritorID from property storage.

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

        DFG CFG simplification should not attempt to deref nodes inside of an unreachable subgraph
        https://bugs.webkit.org/show_bug.cgi?id=88362

        Reviewed by Gavin Barraclough.

        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::fixPhis):
        (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference):

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

        Entry into JSC should CRASH() if the Heap is busy
        https://bugs.webkit.org/show_bug.cgi?id=88355

        Reviewed by Geoffrey Garen.

        Interpreter::execute() returns jsNull() right now if we try to enter it while 
        the Heap is busy (e.g. with a collection), which is okay, but some code paths 
        that call Interpreter::execute() allocate objects before checking if the Heap 
        is busy. Attempting to execute JS code while the Heap is busy should not be 
        allowed and should be enforced by a release-mode CRASH() to prevent vague, 
        unhelpful backtraces later on if somebody makes a mistake. Normally, recursively 
        executing JS code is okay, e.g. for evals, but it should not occur during a 
        Heap allocation or collection because the Heap is not guaranteed to be in a 
        consistent state (especially during collections). We are protected from 
        executing JS on the same Heap concurrently on two separate threads because 
        they must each take a JSLock first. However, we are not protected from reentrant 
        execution of JS on the same thread because JSLock allows reentrancy. Therefore, 
        we should fail early if we detect an entrance into JS code while the Heap is busy.

        * heap/Heap.cpp: Changed Heap::collect so that it sets the m_operationInProgress field 
        at the beginning of collection and then unsets it at the end so that it is set at all 
        times throughout the duration of a collection rather than sporadically during various 
        phases. There is no reason to unset during a collection because our collector does 
        not currently support running additional JS between the phases of a collection.
        (JSC::Heap::getConservativeRegisterRoots):
        (JSC::Heap::markRoots):
        (JSC::Heap::collect):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute): Crash if the Heap is busy.
        * runtime/Completion.cpp: Crash if the Heap is busy. We do it here before we call 
        Interpreter::execute() because we do some allocation prior to calling execute() which 
        could cause Heap corruption if, for example, that allocation caused a collection.
        (JSC::evaluate):

2012-06-05  Dongwoo Im  <dw.im@samsung.com>

        Add 'isProtocolHandlerRegistered' and 'unregisterProtocolHandler'.
        https://bugs.webkit.org/show_bug.cgi?id=73176

        Reviewed by Adam Barth.

        Two more APIs are added in Custom Scheme Handler specification.
        http://dev.w3.org/html5/spec/Overview.html#custom-handlers
        One is 'isProtocolHandlerRegistered' to query whether the specific URL
        is registered or not.
        The other is 'unregisterProtocolHandler' to remove the registered URL.

        * Configurations/FeatureDefines.xcconfig: Add a macro 'ENABLE_CUSTOM_SCHEME_HANDLER'.

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

        DFG CFG simplification should correct the variables at the head of the predecessor block
        https://bugs.webkit.org/show_bug.cgi?id=88284

        Reviewed by Geoffrey Garen.

        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):

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

        Unreviewed.

        Rolled out r119364 because it's still causing crashes (when running
        v8-earley in release builds of DRT)

        This time for sure!

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::resetAllocator):
        (JSC):
        * heap/MarkedSpace.cpp:
        (JSC::ResetAllocator::operator()):
        (JSC):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::sweepWeakSets):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::sweep):
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep):
        (JSC::WeakSet::tryFindAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::shrink):

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

        DFG arguments simplification should have rationalized handling of TearOffArguments
        https://bugs.webkit.org/show_bug.cgi?id=88206

        Reviewed by Geoffrey Garen.
        
        - Accesses to the unmodified arguments register ought to have the same effect on
          alias/escape analysis of arguments as accesses to the mutable arguments register.
        
        - The existence of TearOffArguments should not get in the way of arguments aliasing.
        
        - TearOffArguments should be eliminated if CreateArguments is eliminated.

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

2012-06-04  Gavin Barraclough  <barraclough@apple.com>

        Remove enabledProfilerReference
        https://bugs.webkit.org/show_bug.cgi?id=88258

        Reviewed by Michael Saboff.

        Make the enabled profiler a member of JSGlobalData, and switch code that accesses it to do so directly
        via the JSGlobalData, rather than holding a Profiler** reference to it. Do not pass the Profiler**
        reference to JIT code. This patch does not change the stack layout on entry into JIT code (passing an
        unused void* instead), since this is an intrusive change better handled in a separate patch.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::privateExecute):
        * jit/JITCode.h:
        (JSC::JITCode::execute):
            - Don't pass Profiler** to JIT code.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call):
        (JSC::JIT::emit_op_profile_did_call):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call):
        (JSC::JIT::emit_op_profile_did_call):
        * jit/JITStubs.cpp:
        (JSC):
        (JSC::ctiTrampoline):
        (JSC::ctiVMThrowTrampoline):
        (JSC::ctiOpThrowNotCaught):
        (JSC::JITThunks::JITThunks):
        (JSC::DEFINE_STUB_FUNCTION):
            - For ARM_THUMB2, rename ENABLE_PROFILER_REFERENCE_OFFSET to FIRST_STACK_ARGUMENT (which is how it is being used).
            - For MIPS, remove ENABLE_PROFILER_REFERENCE_OFFSET.
        * jit/JITStubs.h:
        (JITStackFrame):
        (JSC):
            - Renamed enabledProfilerReference to unusedX.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * profiler/Profiler.cpp:
        (JSC):
        (JSC::Profiler::startProfiling):
        (JSC::Profiler::stopProfiling):
        * profiler/Profiler.h:
        (Profiler):
            - Removed s_sharedEnabledProfilerReference, enabledProfilerReference().
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSC):
        (JSC::JSGlobalData::enabledProfiler):
        (JSGlobalData):
            - Added m_enabledProfiler, enabledProfiler().
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::~JSGlobalObject):

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

        get_argument_by_val should be profiled everywhere
        https://bugs.webkit.org/show_bug.cgi?id=88205

        Reviewed by Geoffrey Garen.

        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

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

        DFG arguments simplification takes unkindly to direct accesses to the arguments register
        https://bugs.webkit.org/show_bug.cgi?id=88261

        Reviewed by Geoffrey Garen.
        
        Fixed arguments simplification for direct accesses to the arguments register, which may
        arise if CSE had not run. Fixed CSE so that it does run prior to arguments simplification,
        by making it a full-fledged member of the fixpoint. Fixed other issues in arguments
        simplification, like realizing that it needs to bail if there is a direct assignment to
        the arguments register, and failing to turn CreateArguments into PhantomArguments. Also
        fixed CSE's handling of store elimination of captured locals in the presence of a
        GetMyArgumentByVal (or one of its friends), and fixed CSE to correctly fixup variables at
        tail if the Flush it removes is the last operation on a local in a basic block.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::run):
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        (CSEPhase):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):

2012-06-04  Anders Carlsson  <andersca@apple.com>

        Fix a struct/class mismatch.

        * heap/Handle.h:
        (Handle):

2012-06-04  David Kilzer  <ddkilzer@apple.com>

        BUILD FIX: FeatureDefines.xcconfig should match across projects

        * Configurations/FeatureDefines.xcconfig:
        - Add missing ENABLE_LEGACY_CSS_VENDOR_PREFIXES.

2012-06-02  Geoffrey Garen  <ggaren@apple.com>

        Weak pointer finalization should be lazy
        https://bugs.webkit.org/show_bug.cgi?id=87599

        Reviewed by Sam Weinig.

        This time for sure!

        * heap/Heap.cpp:
        (JSC::Heap::collect): Don't sweep eagerly -- we'll sweep lazily instead.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep): Sweep our weak set before we sweep our other
        destructors -- this is our last chance to run weak set finalizers before
        we recycle our memory.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::resetAllocator):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::resetAllocators):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::resetAllocators): Don't force allocator reset anymore.
        It will happen automatically when a weak set is swept. It's simpler to
        have only one canonical way for this to happen, and it wasn't buying
        us anything to do it eagerly.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::sweep): Don't short-circuit a sweep unless we know
        the sweep would be a no-op. If even one finalizer is pending, we need to
        run it, since we won't get another chance.

        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep): This loop can be simpler now that
        WeakBlock::sweep() does what we mean.

        Reset our allocator after a sweep because this is the optimal time to
        start trying to recycle old weak pointers.

        (JSC::WeakSet::tryFindAllocator): Don't sweep when searching for an
        allocator because we've swept already, and forcing a new sweep would be
        wasteful.

        * heap/WeakSet.h:
        (JSC::WeakSet::shrink): Be sure to reset our allocator after a shrink
        because the shrink may have removed the block the allocator was going to
        allocate out of.

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

        If the DFG bytecode parser detects that op_method_check has gone polymorphic, it
        shouldn't revert all the way to GetById/GetByIdFlush
        https://bugs.webkit.org/show_bug.cgi?id=88176

        Reviewed by Geoffrey Garen.
        
        Refactored the code so that the op_method_check case of the parser gracefully falls
        through to all of the goodness of the normal op_get_by_id case.

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

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

        DFG CSE should be able to eliminate unnecessary flushes of arguments and captured variables
        https://bugs.webkit.org/show_bug.cgi?id=87929

        Reviewed by Geoffrey Garen.
        
        Slight speed-up on V8. Big win (up to 50%) on programs that inline very small functions.
        
        This required a bunch of changes:
        
        - The obvious change is making CSE essentially ignore whether or not the set of
          operations between the Flush and the SetLocal can exit, and instead focus on whether or
          not that set of operations can clobber the world or access local variables. This code
          is now refactored to return a set of flags indicating any of these events, and the CSE
          decides what to do based on those flags. If the set of operations is non-clobbering
          and non-accessing, then the Flush is turned into a Phantom on the child of the
          SetLocal. This expands the liveness of the relevant variable but virtually guarantees
          that it will be register allocated and not flushed to the stack. So, yeah, this patch
          is a lot of work to save a few stores to the stack.
        
        - Previously, CheckArgumentsNotCreated was optimized "lazily" in that you only knew if
          it was a no-op if you were holding onto a CFA abstract state. But this would make the
          CSE act pessimistically, since it doesn't use the CFA. Hence, this patch changes the
          constant folding phase into something more broad; it now fixes up
          CheckArgumentsNotCreated nodes by turning them into phantoms if it knows that they are
          no-ops.
        
        - Arguments simplification was previously relying on this very strange PhantomArguments
          node, which had two different meanings: for normal execution it meant the empty value
          but for OSR exit it meant that the arguments should be reified. This produces problems
          when set SetLocals to the captured arguments registers are CSE'd away, since we'd be
          triggering reification of arguments without having initialized the arguments registers
          to empty. The cleanest solution was to fix PhantomArguments to have one meaning:
          namely, arguments reification on OSR exit. Hence, this patch changes arguments
          simplification to change SetLocal of CreateArguments on the arguments registers to be
          a SetLocal of Empty.
        
        - Argument value recoveries were previously derived from the value source of the
          arguments at the InlineStart. But that relies on all SetLocals to arguments having
          been flushed. It's possible that we could have elided the SetLocal to the arguments
          at the callsite because there were subsequent SetLocals to the arguments inside of the
          callee, in which case the InlineStart would get the wrong information. Hence, this
          patch changes argument value recovery computation to operate over the ArgumentPositions
          directly.
        
        - But that doesn't actually work, because previously, there was no way to link an
          InlineStart back to the corresponding ArgumentPositions, at least not without some
          ugliness. So this patch instates the rule that the m_argumentPositions vector consists
          of disjoint subsequences such that each subsequence corresponds to an inline callsite
          and can be identified by its first index, and within each subsequence are the
          ArgumentPositions of all of the arguments ordered by argument index. This required
          flipping the order in which ArgumentPositions are added to the vector, and giving
          InlineStart an operand that indicates the start of that inline callsite's
          ArgumentPosition subsequence.
        
        - This patch also revealed a nasty bug in the reification of arguments in inline call
          frames on OSR exit. Since the reification was happening after the values of virtual
          registers were recovered, the value recoveries of the inline arguments were wrong.
          Hence using operationCreateInlinedArguments is wrong. For example a value recovery
          might say that you have to box a double, but if we had already boxed it then boxing
          it a second time will result in garbage. The specific case of this bug was this patch
          uncovered was that now it is possible for an inline call frame to not have any valid
          value recoveries for any inline arguments, if the optimization elides all argument
          flushes, while at the same time optimizing away arguments creation. Then OSR exit
          would try to recover the arguments using the inline call frame, which had bogus
          information, and humorous crashes would ensue. This patch fixes this issue by moving
          arguments reification to after call frame reification, so that arguments reification
          can always use operationCreateArguments instead of operationCreateInlinedArguments.
        
        - This patch may turn a Flush into a Phantom. That's kind of the whole point. But that
          broke forward speculation checks, which knew to look for a Flush prior to a SetLocal
          but didn't know that there could alternatively be a Phantom in place of the Flush.
          This patch fixes that by augmenting the forward speculation check logic.
        
        - Finally, in the process of having fun with all of the above, I realized that my DFG
          validation was not actually running on every phase like I had originally designed it
          to. In fact it was only running just after bytecode parsing. I initially tried to
          make it run in every phase but found that this causes some tests to timeout
          (specifically the evil fuzzing ones), so I decided on a compromise where: (i) in
          release mode validation never runs, (ii) in debug mode validation will run just
          after parsing and just before the backend, and (iii) it's possible with a simple
          switch to enable validation to run on every phase.
        
        Luckily all of the above issues were already covered by the 77 or so DFG-specific
        layout tests. Hence, this patch does not introduce any new tests despite being so
        meaty.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::prediction):
        (JSC::DFG::ArgumentPosition::doubleFormatState):
        (JSC::DFG::ArgumentPosition::shouldUseDoubleFormat):
        (ArgumentPosition):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::SetLocalStoreEliminationResult::SetLocalStoreEliminationResult):
        (SetLocalStoreEliminationResult):
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGCommon.h:
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGNode.h:
        (Node):
        (JSC::DFG::Node::hasArgumentPositionStart):
        (JSC::DFG::Node::argumentPositionStart):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGPhase.cpp:
        (DFG):
        * dfg/DFGPhase.h:
        (Phase):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-06-02  Geoffrey Garen  <ggaren@apple.com>

        DOM string cache should hash pointers, not characters
        https://bugs.webkit.org/show_bug.cgi?id=88175

        Reviewed by Phil Pizlo and Sam Weinig.

        * heap/Weak.h:
        (JSC::weakAdd):
        (JSC::weakRemove): Made these function templates slightly more generic
        to accommodate new client types.

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

        DFG CFA should know that PutByVal can clobber the world
        https://bugs.webkit.org/show_bug.cgi?id=88155

        Reviewed by Gavin Barraclough.

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

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

        DFG CFA should mark basic blocks as having constants if local accesses yield constants
        https://bugs.webkit.org/show_bug.cgi?id=88153

        Reviewed by Gavin Barraclough.

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

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

        DFG arguments simplification phase uses a node.codeOrigin after appending a node
        https://bugs.webkit.org/show_bug.cgi?id=88151

        Reviewed by Geoffrey Garen.
        
        The right thing to do is to save the CodeOrigin before appending to the graph.

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

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

        DFG should not emit unnecessary speculation checks when performing an int32 to double conversion on
        a value that is proved to be a number, predicted to be an int32, but not proved to be an int32
        https://bugs.webkit.org/show_bug.cgi?id=88146

        Reviewed by Gavin Barraclough.

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

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

        DFG constant folding search for the last local access skips the immediately previous local access
        https://bugs.webkit.org/show_bug.cgi?id=88141

        Reviewed by Michael Saboff.
        
        If you use a loop in the style of:

        for (i = start; i--;)

        then you need to remember that the first value of 'i' that the loop body will see is 'start - 1'.
        Hence the following is probably wrong:
        
        for (i = start - 1; i--;)

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

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

        DFG constant folding should be OK with GetLocal of captured variables having a constant
        https://bugs.webkit.org/show_bug.cgi?id=88137

        Reviewed by Gavin Barraclough.

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

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

        JSGlobalObject does not mark m_privateNameStructure
        https://bugs.webkit.org/show_bug.cgi?id=88023

        Rubber stamped by Gavin Barraclough.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::visitChildren): We need to mark this so it doesn't get 
        inadvertently garbage collected.

2012-05-31  Erik Arvidsson  <arv@chromium.org>

        Make DOM Exceptions Errors
        https://bugs.webkit.org/show_bug.cgi?id=85078

        Reviewed by Oliver Hunt.

        WebIDL mandates that exceptions should have Error.prototype on its prototype chain.

        For JSC we have access to the Error.prototype from the binding code.

        For V8 we set a field in the WrapperTypeInfo and when the constructor function is created we
        set the prototype as needed.

        Updated test: fast/dom/DOMException/prototype-object.html

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSGlobalObject.h:
        (JSC):
        (JSGlobalObject):
        (JSC::JSGlobalObject::errorPrototype):

2012-05-31  Andy Wingo  <wingo@igalia.com>

        Fix reference to unset variable in debug mode
        https://bugs.webkit.org/show_bug.cgi?id=87981

        Reviewed by Geoffrey Garen.

        * runtime/JSONObject.cpp (Stringifier::Holder::Holder):
        Initialize m_size in debug mode, as we check it later in an assert.

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

        Heap should sweep incrementally
        https://bugs.webkit.org/show_bug.cgi?id=85429

        We shouldn't have to wait for the opportunistic GC timer to fire in order 
        to call object destructors. Instead, we should incrementally sweep some 
        subset of the blocks requiring sweeping periodically. We tie this sweeping 
        to a timer rather than to collections because we want to reclaim this memory 
        even if we stop allocating. This way, our memory usage scales smoothly with 
        actual use, regardless of whether we've recently done an opportunistic GC or not.

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.gypi:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::collect): We no longer sweep during a full sweep. We only shrink now,
        which we will switch over to being done during incremental sweeping too as soon as
        all finalizers can be run lazily (and, by extension, incrementally). 
        (JSC::Heap::sweeper):
        (JSC):
        * heap/Heap.h:
        (JSC):
        (Heap):
        * heap/IncrementalSweeper.cpp: Added.
        (JSC):
        (JSC::IncrementalSweeper::timerDidFire): The IncrementalSweeper works very similarly to 
        GCActivityCallback. It is tied to a run-loop based timer that fires periodically based 
        on how long the previous sweep increment took to run. The IncrementalSweeper doesn't do 
        anything if the platform doesn't support CoreFoundation.
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::~IncrementalSweeper):
        (JSC::IncrementalSweeper::create):
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::cancelTimer):
        (JSC::IncrementalSweeper::doSweep): Iterates over the snapshot of the MarkedSpace taken 
        during the last collection, checking to see which blocks need sweeping. If it successfully 
        gets to the end of the blocks that need sweeping then it cancels the timer.
        (JSC::IncrementalSweeper::startSweeping): We take a snapshot of the Heap and store it in 
        a Vector that the incremental sweep will iterate over. We also reset our index into this Vector.
        * heap/IncrementalSweeper.h: Added.
        (JSC):
        (IncrementalSweeper):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::needsSweeping): If a block is in the Marked state it needs sweeping 
        to be usable and to run any destructors that need to be run.

2012-05-30  Patrick Gansterer  <paroga@webkit.org>

        [WINCE] Fix JSString after r115516.
        https://bugs.webkit.org/show_bug.cgi?id=87892

        Reviewed by Geoffrey Garen.

        r115516 splitted JSString into two classes, with addition nested classes.
        Add a workaround for the WinCE compiler since it can't resolve the friend class
        declerations corretly and denies the access to protected members of JSString.

        * runtime/JSString.h:
        (JSC::JSRopeString::RopeBuilder::append):
        (JSC::JSRopeString::append):
        (JSRopeString):

2012-05-30  Oliver Hunt  <oliver@apple.com>

        Really provide error information with the inspector disabled
        https://bugs.webkit.org/show_bug.cgi?id=87910

        Reviewed by Filip Pizlo.

        Don't bother checking for anything other than pre-existing error info.
        In the absence of complete line number information you'll only get the
        line a function starts on, but at least it's something.

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

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

        LLInt broken on x86-32 with JIT turned off
        https://bugs.webkit.org/show_bug.cgi?id=87906

        Reviewed by Geoffrey Garen.
        
        Fixed the code to not clobber registers that contain important things, like the call frame.

        * llint/LowLevelInterpreter32_64.asm:

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

        ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it
        https://bugs.webkit.org/show_bug.cgi?id=87887

        Reviewed by Darin Adler.
        
        Better fix - we now never call SourceProvider::asID() if SourceProvider* is 0.

        * parser/Nodes.h:
        (JSC::ScopeNode::sourceID):
        * parser/SourceCode.h:
        (JSC::SourceCode::providerID):
        (SourceCode):
        * parser/SourceProvider.h:
        (SourceProvider):
        (JSC::SourceProvider::asID):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::sourceID):

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

        ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it
        https://bugs.webkit.org/show_bug.cgi?id=87887

        Reviewed by Geoffrey Garen.

        * parser/SourceProvider.h:
        (JSC::SourceProvider::asID):

2012-05-30  Oliver Hunt  <oliver@apple.com>

        DFG does not correctly handle exceptions caught in the LLInt
        https://bugs.webkit.org/show_bug.cgi?id=87885

        Reviewed by Filip Pizlo.

        Make the DFG use genericThrow, rather than reimplementing a small portion of it.
        Also make the LLInt slow paths validate that their PC is correct.

        * dfg/DFGOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (LLInt):

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

        DFG CFA should infer types and values of captured variables
        https://bugs.webkit.org/show_bug.cgi?id=87813

        Reviewed by Gavin Barraclough.
        
        Slight speed-up in V8/earley-boyer (~1%).

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::argumentsAreCaptured):
        (JSC::CodeBlock::argumentIsCaptured):
        (CodeBlock):
        * dfg/DFGAbstractState.cpp:
        (DFG):
        (JSC::DFG::AbstractState::beginBasicBlock):
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::clobberWorld):
        (JSC::DFG::AbstractState::clobberStructures):
        (JSC::DFG::AbstractState::mergeStateAtTail):
        (JSC::DFG::AbstractState::merge):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::variables):
        (AbstractState):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-05-30  Patrick Gansterer  <paroga@webkit.org>

        Unreviewed. Build fix for !ENABLE(JIT) after r117823.

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

2012-05-30  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r118868.
        http://trac.webkit.org/changeset/118868
        https://bugs.webkit.org/show_bug.cgi?id=87828

        introduced ~20 crashes on Mac and Qt bots (Requested by pizlo_
        on #webkit).

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::sweepWeakSet):
        (JSC):
        * heap/MarkedSpace.cpp:
        (JSC::SweepWeakSet::operator()):
        (JSC):
        (JSC::MarkedSpace::sweepWeakSets):
        * heap/MarkedSpace.h:
        (MarkedSpace):

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

        Rolled back in r118646, now that
        https://bugs.webkit.org/show_bug.cgi?id=87784 is fixed.

        http://trac.webkit.org/changeset/118646
        https://bugs.webkit.org/show_bug.cgi?id=87599

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep):
        * heap/MarkedBlock.h:
        (JSC):
        * heap/MarkedSpace.cpp:
        (JSC):
        * heap/MarkedSpace.h:
        (MarkedSpace):

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

        DFG should keep captured variables alive until the (inline) return.
        https://bugs.webkit.org/show_bug.cgi?id=87205

        Reviewed by Gavin Barraclough.
        
        Changes the way we do flushing for captured variables and arguments. Instead of flushing
        each SetLocal immediately, we flush at kill points. So a SetLocal will cause a Flush of
        whatever was live in the variable previously, and a return will cause a Flush of all
        captured variables and all arguments.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setDirect):
        (JSC::DFG::ByteCodeParser::set):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForArgument):
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::findArgumentPosition):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):

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

        WeakGCMap should be lazy-finalization-safe
        https://bugs.webkit.org/show_bug.cgi?id=87784

        Reviewed by Darin Adler.

        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::get): Since this is a map of raw WeakImpl pointers, and
        not Weak<T>, we need to verify manually that the WeakImpl is live before
        we return its payload.

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

        CopiedSpace::doneCopying could start another collection
        https://bugs.webkit.org/show_bug.cgi?id=86538

        Reviewed by Geoffrey Garen.

        It's possible that if we don't have anything at the head of to-space 
        after a collection and the BlockAllocator doesn't have any fresh blocks 
        to give us right now we could start another collection while still in 
        the middle of the first collection when we call CopiedSpace::addNewBlock(). 

        One way to resolve this would be to have Heap::shouldCollect() check that 
        m_operationInProgress is NoOperation. This would prevent the path in 
        getFreshBlock() that starts the collection if we're already in the middle of one.

        I could not come up with a test case to reproduce this crash on ToT.

        * heap/Heap.h:
        (JSC::Heap::shouldCollect): We shouldn't collect if we're already in the middle
        of a collection, i.e. the current operation should be NoOperation.

2012-05-29  David Barr  <davidbarr@chromium.org>

        Introduce ENABLE_CSS_IMAGE_RESOLUTION compile flag
        https://bugs.webkit.org/show_bug.cgi?id=87685

        Reviewed by Eric Seidel.

        Add a configuration option for CSS image-resolution support, disabling it by default.

        * Configurations/FeatureDefines.xcconfig:

2012-05-28  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r118646.
        http://trac.webkit.org/changeset/118646
        https://bugs.webkit.org/show_bug.cgi?id=87691

        broke V8 raytrace benchmark (Requested by pizlo_ on #webkit).

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::sweepWeakSet):
        (JSC):
        * heap/MarkedSpace.cpp:
        (JSC::SweepWeakSet::operator()):
        (JSC):
        (JSC::MarkedSpace::sweepWeakSets):
        * heap/MarkedSpace.h:
        (MarkedSpace):

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

        DFG should not generate code for code that the CFA proves to be unreachable
        https://bugs.webkit.org/show_bug.cgi?id=87682

        Reviewed by Sam Weinig.
        
        This also fixes a small performance bug where CFA was not marking blocks
        as having constants (and hence not triggering constant folding) if the only
        constants were on GetLocals.
        
        And fixing that bug revealed another bug: constant folding was assuming that
        a GetLocal must be the first access to a local in a basic block. This isn't
        true. The first access may be a Flush. This patch fixes that issue using the
        safest approach possible, since we don't need to be clever for something that
        only happens in one of our benchmarks.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-05-28  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

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

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

        Weak pointer finalization should be lazy
        https://bugs.webkit.org/show_bug.cgi?id=87599

        Reviewed by Darin Adler.

        * heap/Heap.cpp:
        (JSC::Heap::collect): Don't force immediate finalization -- it will
        happen lazily.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep): Sweep a block's weak set when sweeping the
        block. The weak set may not have been swept yet, and this is our last
        chance to run weak finalizers before we recycle the memory they reference.

        * heap/MarkedBlock.h:
        * heap/MarkedSpace.cpp:
        (JSC::MarkedBlock::sweepWeakSets):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::sweepWeakSets): Nixed sweepWeakSets because it's unused
        now.

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 ==