File: ChangeLog-2012-10-02

package info (click to toggle)
qtwebkit-opensource-src 5.3.2%2Bdfsg-2~bpo70%2B1
links: PTS, VCS
area: main
in suites: wheezy-backports
size: 291,472 kB
sloc: cpp: 1,358,084; python: 70,286; ansic: 42,964; perl: 35,474; ruby: 12,229; objc: 9,465; xml: 8,396; asm: 3,866; yacc: 2,397; sh: 1,647; makefile: 644; lex: 644; java: 110
file content (20888 lines) | stat: -rw-r--r-- 847,838 bytes
parent folder | download | duplicates (6)
2012-10-02  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r128400): ASSERT (crash in release) @ app.asana.com
        https://bugs.webkit.org/show_bug.cgi?id=98175

        Reviewed by Oliver Hunt.

        It's bad karma to create a new structure while stealing another structure's property table
        while leaving the m_offset unset. Eventually someone will then steal your property table, and
        then you won't know how many properties you have anymore.

        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):

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

        Comment additions after r130109 

        Rubber stamped by Geoffrey Garen.

        Updated comments to how array storage works.

        * runtime/ArrayStorage.h:
        * runtime/JSArray.cpp:

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

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

        Reviewed by Geoffrey Garen.

        Currently the block freeing thread wakes up once a second to check if there are any blocks 
        for it to release back to the OS. This is wasteful. We should change it to sleep when it 
        realizes there are no more blocks to free. Any thread that returns a block to the BlockAllocator 
        should then notify the block freeing thread that there is more work to do now.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::BlockAllocator):
        (JSC::BlockAllocator::blockFreeingThreadMain):
        * heap/BlockAllocator.h:
        (BlockAllocator):
        (JSC::BlockAllocator::deallocate):

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

        JSArray::unshiftCountSlowCase needs to clear array slots when adding space to end of array
        https://bugs.webkit.org/show_bug.cgi?id=98101

        Reviewed by Filip Pizlo.

        Cleared new array entries when adding to end due to shifting contents to lower memory.  Also
        checnaged the order of moving array contents and metadata in the shift left case to avoid
        clobbering the metadata with array contents.  Optimized the to only make a memmove if the
        count is non-zero.

        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::unshiftCount):

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

        Address a FIXME in JSArray::sort
        https://bugs.webkit.org/show_bug.cgi?id=98080
        <rdar://problem/12407844>

        Reviewed by Oliver Hunt.

        Get rid of fast sorting of sparse maps. I don't know that it's broken but I do know that we don't
        have coverage for it. Then also address the FIXME in JSArray::sort regarding side-effecting
        compare functions.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSort):
        * runtime/JSArray.cpp:
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSArray):
        * runtime/JSObject.h:
        (JSC::JSObject::hasSparseMap):
        (JSObject):

2012-10-01  Jonathan Liu  <net147@gmail.com>

        Remove unused sys/mman.h include
        https://bugs.webkit.org/show_bug.cgi?id=97995

        Reviewed by Kentaro Hara.

        The sys/mman.h is not used and removing it improves portability as not
        all systems have sys/mman.h.

        * jit/ExecutableAllocatorFixedVMPool.cpp:

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

        ASSERTION in m_graph[tailNodeIndex].op() == Flush || m_graph[tailNodeIndex].op() == SetLocal on plus.google.com
        https://bugs.webkit.org/show_bug.cgi?id=97656

        Reviewed by Mark Hahnenberg.

        There were two bugs here:
        
        1) In case of multiple GetLocals to the same captured variable, the bytecode parser would linke the first,
           rather than the last, of the GetLocals into the vars-at-tail table.
        
        2) The constant folding phase was asserting that any GetLocal it eliminates must be linked into the
           vars-at-tail table, when for captured variables only the last of those should be.

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

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

        DFGStructureHoistingPhase SetLocal assumes StructureTransitionWatchpoint has a structure set
        https://bugs.webkit.org/show_bug.cgi?id=97810

        Reviewed by Mark Hahnenberg.

        No tests because this can't happen in ToT: the structure check hoisting phase runs before any
        CFA or folding, so the only StructureTransitionWatchpoints it will see are the ones inserted
        by the parser. But the parser will only insert StructureTransitinWatchpoints on constants, which
        will not be subject to SetLocals.
        
        Still, it would be good to fix this in case things changed.

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

2012-09-27  Mark Lam  <mark.lam@apple.com>

        Put initializeHostCallReturnValue() behind #if ENABLE(JIT).
        Fixes non JIT builds.
        https://bugs.webkit.org/show_bug.cgi?id=97838.

        Reviewed by John Sullivan.

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

2012-09-27  Mark Lam  <mark.lam@apple.com>

        Fixed CallFrameClosure::resetCallFrame() to use the valid
        range of argument index values.
        https://bugs.webkit.org/show_bug.cgi?id=97836.

        Reviewed by Gavin Barraclough.

        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/CallFrameClosure.h:
        (JSC::CallFrameClosure::resetCallFrame):

2012-09-27  Patrick Gansterer  <paroga@webkit.org>

        Fix usage of COMPILER() macros
        https://bugs.webkit.org/show_bug.cgi?id=97642

        Reviewed by Geoffrey Garen.

        Add COMPILER(GCC) around compiler specific code and remove it from generic code.
        This allows us to implement the DFG code for other compilers to in a next step.

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

2012-09-27  Andreas Kling  <kling@webkit.org>

        3.20MB below FunctionParameters::create() on Membuster3.
        <http://webkit.org/b/97730>

        Reviewed by Anders Carlsson.

        Figure out the exact space needed for parameter identifiers and use reserveInitialCapacity().
        Reduces memory consumption on Membuster3 by ~1.60 MB.

        * parser/Nodes.cpp:
        (JSC::FunctionParameters::FunctionParameters):

2012-09-27  Csaba Osztrogonác  <ossy@webkit.org>, Tor Arne Vestbø  <vestbo@webkit.org>

        [Qt] Enable the LLInt on Linux
        https://bugs.webkit.org/show_bug.cgi?id=95749

        Reviewed by Simon Hausmann.

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

2012-09-27  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Fix build with static JavaScriptCore library

        * shell/CMakeLists.txt: Define STATICALLY_LINKED_WITH_JavaScriptCore if
                                JavaScriptCore_LIBRARY_TYPE is set to STATIC.

2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Proxy the global this in JSC
        https://bugs.webkit.org/show_bug.cgi?id=97734

        Reviewed by Filip Pizlo.

        Eeep – fix a bug - was leaving the global this proxy's structure's globalObject as 0,
        and setting the proxy's prototype as the global object, rather than its prototype.

        * jsc.cpp:
        (GlobalObject::create):
        * runtime/JSProxy.h:
        (JSC::JSProxy::createStructure):

2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Speculative Windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Unreviewed, 32-bit build fix.

        * llint/LowLevelInterpreter32_64.asm:

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

        jneq_ptr shouldn't have a pointer
        https://bugs.webkit.org/show_bug.cgi?id=97739

        Reviewed by Oliver Hunt.

        Slamming pointers directly into bytecode is sometimes cool, but in this case it's
        unwieldy and confusing. Switched the instruction to use an enum instead. This has
        zero effect on code gen behavior in the JITs. In the LLInt, there is now more
        indirection, but that doesn't affect benchmarks.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        (Instruction):
        * bytecode/SpecialPointer.cpp: Added.
        (JSC):
        (JSC::actualPointerFor):
        * bytecode/SpecialPointer.h: Added.
        (JSC):
        (JSC::pointerIsFunction):
        (JSC::pointerIsCell):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::actualPointerFor):

2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms
        https://bugs.webkit.org/show_bug.cgi?id=97529

        Reviewed by Filip Pizlo.

        A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers.

        JSC currently throws an EvalError if you try to call eval with a this object that doesn't
        match the given eval function. This does not match other browsers, which generally just
        ignore the this value that was passed, and eval the string in the eval function's environment.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
            - Remove EvalError, ignore passed this value.

2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Proxy the global this in JSC
        https://bugs.webkit.org/show_bug.cgi?id=97734

        Reviewed by Oliver Hunt.

        Having jsc diverge from WebCore here is not beneficial; it potentially masks bugs and/or performance
        problems from command line testing.

        * jsc.cpp:
        (GlobalObject::create):
            - Create a this value proxy for the global object.
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
            - Make setGlobalThis protected.
        * runtime/JSProxy.h:
        (JSC::JSProxy::create):
        (JSC::JSProxy::target):
        (JSC::JSProxy::finishCreation):
        (JSProxy):
            - Allow proxy target to be a JSObject, add target to create method.

2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Speculative Windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        JSObject::ensureArrayStorage() ignores the possibility that extensions have been prevented
        https://bugs.webkit.org/show_bug.cgi?id=97719

        Reviewed by Gavin Barraclough.

        * runtime/JSObject.cpp:
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC):
        * runtime/JSObject.h:
        (JSC::JSObject::ensureArrayStorage):
        (JSObject):

2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Generalize JSGlobalThis as JSProxy
        https://bugs.webkit.org/show_bug.cgi?id=97716

        Reviewed by Oliver Hunt.

        Generalize JSGlobalThis as JSProxy and move proxying functionality up from the window shell into JSProxy.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::toThisObject):
            - Hoist toThisObject from WebCore.
        (JSC):
        * runtime/JSGlobalObject.h:
            - removed include.
        (JSC::JSGlobalObject::finishCreation):
            - JSGlobalThis -> JSObject
        (JSGlobalObject):
            - Hoist toThisObject from WebCore.
        * runtime/JSGlobalThis.cpp: Removed.
        * runtime/JSGlobalThis.h: Removed.
        * runtime/JSObject.cpp:
            - removed include.
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::isProxy):
            - isGlobalThis -> isProxy
            - GlobalThisType -> ProxyType
        * runtime/JSProxy.cpp: Copied from Source/JavaScriptCore/runtime/JSGlobalThis.cpp.
        (JSC):
        (JSC::JSProxy::visitChildren):
        (JSC::JSProxy::setTarget):
        (JSC::JSProxy::className):
        (JSC::JSProxy::getOwnPropertySlot):
        (JSC::JSProxy::getOwnPropertySlotByIndex):
        (JSC::JSProxy::getOwnPropertyDescriptor):
        (JSC::JSProxy::put):
        (JSC::JSProxy::putByIndex):
        (JSC::JSProxy::putDirectVirtual):
        (JSC::JSProxy::defineOwnProperty):
        (JSC::JSProxy::deleteProperty):
        (JSC::JSProxy::deletePropertyByIndex):
        (JSC::JSProxy::getPropertyNames):
        (JSC::JSProxy::getOwnPropertyNames):
            - Class cretaed from JSGlobalThis, JSDOMWindowShell.
        * runtime/JSProxy.h: Copied from Source/JavaScriptCore/runtime/JSGlobalThis.h.
        (JSC::JSProxy::create):
        (JSC::JSProxy::createStructure):
        (JSProxy):
        (JSC::JSProxy::target):
        (JSC::JSProxy::JSProxy):
            - Class cretaed from JSGlobalThis, JSDOMWindowShell.
        * runtime/JSType.h:
            - GlobalThisType -> ProxyType

2012-09-26  Michael Saboff  <msaboff@apple.com>

        Add ability for JSArray::unshiftCount to unshift in middle of an array
        https://bugs.webkit.org/show_bug.cgi?id=97691

        Reviewed by Filip Pizlo.

        Changed JSArray::unshiftCount and unshiftCountSlowCase to handle unshifting from the middle of an
        array.  Depending on where the unshift point is, either the front part of the array will be moved
        "left" or the back part will be moved right.  Given that unshiftCount only works on contiguous
        arrays it is safe to use memmove for the moves.

        This change is worth 25% performance improvement on pdfjs.  It doesn't seem to have any impact on
        any other benchmarks.

        * runtime/ArrayPrototype.cpp:
        (JSC::unshift):
        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::unshiftCount):
        * runtime/JSArray.h:
        (JSArray):

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

        Unreviewed, rolling out r129592.
        http://trac.webkit.org/changeset/129592
        https://bugs.webkit.org/show_bug.cgi?id=97670

        Failures in Chromium security tests (Requested by schenney on
        #webkit).

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):

2012-09-25  Gavin Barraclough  <barraclough@apple.com>

        REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms
        https://bugs.webkit.org/show_bug.cgi?id=97529

        Reviewed by Filip Pizlo.

        A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers.

        JSC currently throws an EvalError if you try to call eval with a this object that doesn't
        match the given eval function. This does not match other browsers, which generally just
        ignore the this value that was passed, and eval the string in the eval function's environment.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
            - Remove EvalError, ignore passed this value.

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

        DFG ArrayPush, ArrayPop don't handle clobbering or having a bad time correctly
        https://bugs.webkit.org/show_bug.cgi?id=97535

        Reviewed by Oliver Hunt.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

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

        JSC should dump object size inference statistics
        https://bugs.webkit.org/show_bug.cgi?id=97618

        Reviewed by Filip Pizlo.

        Added an option to dump object size inference statistics.

        To see statistics on live objects:

            jsc --showHeapStatistics=1

        To see cumulative statistics on all objects ever allocated:

            jsc --showHeapStatistics=1 --objectsAreImmortal=1

            (This is useful for showing GC churn caused by over-allocation.)

        To support this second mode, I refactored Zombies to separate out their
        immortality feature so I could reuse it.

        * heap/Heap.cpp:
        (JSC::MarkObject): Helper for making things immortal. We have to checked
        for being zapped because blocks start out in this state.

        (JSC::StorageStatistics): Gather statistics by walking the heap. Ignore
        arrays and hash tables for now because they're not our focus. (We'll
        remove these exceptions in future.)

        (JSC::Heap::collect): Moved zombify to the end so it wouldn't interfere
        with statistics gathering.

        (JSC::Heap::showStatistics):
        (JSC::Heap::markAllObjects): Factored out helper, so statistics could
        take advantage of immortal objects.

        (Zombify): Don't mark immortal objects -- that's another class's job now.

        (JSC::Zombify::operator()):
        (JSC::Heap::zombifyDeadObjects): Take advantage of forEachDeadCell instead
        of rolling our own.

        * heap/Heap.h:
        (Heap):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::forEachDeadCell): Added, so clients don't have to do
        the iteration logic themselves.

        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h: New options, listed above. Make sure to initialize
        based on environment variable first, so we can override with specific settings.

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

        We shouldn't use the optimized versions of shift/unshift if the user is doing crazy things to the array
        https://bugs.webkit.org/show_bug.cgi?id=97603
        <rdar://problem/12370864>

        Reviewed by Gavin Barraclough.

        You changed the length behind our backs? No optimizations for you then!

        * runtime/ArrayPrototype.cpp:
        (JSC::shift):
        (JSC::unshift):
        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCount):

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

        JSC bindings appear to sometimes ignore the possibility of arrays being in sparse mode
        https://bugs.webkit.org/show_bug.cgi?id=95610

        Reviewed by Oliver Hunt.

        Add better support for quickly accessing the indexed storage from bindings.

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

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

        Structure check hoisting phase doesn't know about the side-effecting nature of Arrayify
        https://bugs.webkit.org/show_bug.cgi?id=97537

        Reviewed by Mark Hahnenberg.

        No tests because if we use Arrayify then we also use PutByVal(BlankToXYZ), and the latter is
        already known to be side-effecting. So this bug shouldn't have had any symptoms, as far as I
        can tell.

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

2012-09-25  Gavin Barraclough  <barraclough@apple.com>

        Regression: put beyond vector length prefers prototype setters to sparse properties
        https://bugs.webkit.org/show_bug.cgi?id=97593

        Reviewed by Geoff Garen & Filip Pizlo.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLength):
            - Check for self properties in the sparse map - if present, don't examine the protochain.

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

        https://bugs.webkit.org/show_bug.cgi?id=97530
        Regression, freeze applied to numeric properties of non-array objects

        Reviewed by Filip Pizlo.

        Object.freeze has a fast implementation in JSObject, but this hasn't been updated to take into account numeric properties in butterflies.
        For now, just fall back to the generic implementation if the object has numeric properties.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorFreeze):
            - fallback if the object has a non-zero indexed property vector length.

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

        Bug in numeric accessors on global environment
        https://bugs.webkit.org/show_bug.cgi?id=97526

        Reviewed by Geoff Garen.

        I've hit this assert in test262 in browser, but haven't yet worked out how to repro in a test case :-/
        The sparsemap is failing to map back from the global object to the window shell.
        A test case would need to resolve a numeric property name against the global environment.

        (JSC::SparseArrayEntry::get):
        (JSC::SparseArrayEntry::put):
            - Add missing toThisObject calls.

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

        SerializedScriptValue isn't aware of indexed storage, but should be
        https://bugs.webkit.org/show_bug.cgi?id=97515
        <rdar://problem/12361874>

        Reviewed by Sam Weinig.

        Export a method that WebCore now uses.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * runtime/JSObject.h:
        (JSObject):

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

        Remove JSObject::unwrappedGlobalObject(), JSObject::unwrappedObject()
        https://bugs.webkit.org/show_bug.cgi?id=97519

        Reviewed by Geoff Garen.

        unwrappedGlobalObject() was only needed because globalObject() doesn't always return a helpful result -
        specifically for WebCore's window shell the structure's globalObject is set to null. We can fix this by
        simply keeping the structure up to date as the window navigates, obviating the need for this function.

        The only other use of unwrappedObject() came from globalFuncEval(), and this can be trivially removed
        by flipping the way we perform this globalObject check (which we may also be able to remove!) - instead
        of getting the globalObject from the provided this value & comparing to the expected globalObject, we
        can get the this value from the expected globalObject, and compare to that provided.

        * runtime/JSGlobalObject.cpp:
            - Call globalObject() instead of unwrappedGlobalObject().
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
            - Changed to compare this object values, instead of globalObjects -
              this means we only need to be able to map globalObject -> this,
              and not vice versa.
        * runtime/JSObject.cpp:
        (JSC::JSObject::allowsAccessFrom):
        (JSC::JSObject::createInheritorID):
            - Call globalObject() instead of unwrappedGlobalObject().
        * runtime/JSObject.h:
        (JSObject):
            - Removed unwrappedGlobalObject(), unwrappedObject().

2012-09-24  Mark Lam  <mark.lam@apple.com>

        Deleting the classic interpreter and cleaning up some build options.
        https://bugs.webkit.org/show_bug.cgi?id=96969.

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * interpreter/AbstractPC.cpp:
        (JSC::AbstractPC::AbstractPC):
        * interpreter/AbstractPC.h:
        (AbstractPC):
        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::~Interpreter):
        (JSC::Interpreter::initialize):
        (JSC::Interpreter::isOpcode):
        (JSC::Interpreter::unwindCallFrame):
        (JSC::getLineNumberForCallFrame):
        (JSC::getCallerInfo):
        (JSC::getSourceURLFromCallFrame):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::retrieveArgumentsFromVMCode):
        (JSC::Interpreter::retrieveCallerFromVMCode):
        (JSC::Interpreter::retrieveLastCaller):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::getOpcodeID):
        (Interpreter):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        * offlineasm/asm.rb:
        * offlineasm/offsets.rb:
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (JSC::NativeExecutable::create):
        (NativeExecutable):
        (JSC::NativeExecutable::finishCreation):
        * runtime/JSGlobalData.cpp:
        (JSC):
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::getHostFunction):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        (JSC::JSGlobalData::canUseJIT):
        (JSC::JSGlobalData::canUseRegExpJIT):
        * runtime/Options.cpp:
        (JSC::Options::initialize):

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

        Nested try/finally should not confuse the finally unpopper in BytecodeGenerator::emitComplexJumpScopes
        https://bugs.webkit.org/show_bug.cgi?id=97508
        <rdar://problem/12361132>

        Reviewed by Sam Weinig.

        We're reusing some vector for multiple iterations of a loop, but we were forgetting to clear its
        contents from one iteration to the next. Hence if you did multiple iterations of finally unpopping
        (like in a nested try/finally and a jump out of both of them) then you'd get a corrupted try
        context stack afterwards.

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

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

        ValueToInt32 bool case does bad things to registers
        https://bugs.webkit.org/show_bug.cgi?id=97505
        <rdar://problem/12356331>

        Reviewed by Mark Hahnenberg.

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

2012-09-24  Mark Lam  <mark.lam@apple.com>

        Add cloopDo instruction for debugging the llint C++ backend.
        https://bugs.webkit.org/show_bug.cgi?id=97502.

        Reviewed by Geoffrey Garen.

        * offlineasm/cloop.rb:
        * offlineasm/instructions.rb:
        * offlineasm/parser.rb:

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

        JSArray::putByIndex asserts with readonly property on prototype
        https://bugs.webkit.org/show_bug.cgi?id=97435
        <rdar://problem/12357084>

        Reviewed by Geoffrey Garen.

        Boy, there were some problems:
        
        - putDirectIndex() should know that it can set the index quickly even if it's a hole and we're
          in SlowPut mode, since that's the whole point of PutDirect.
        
        - We should have a fast path for putByIndex().
        
        - The LiteralParser should not use push(), since that may throw if we're having a bad time.

        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * runtime/JSObject.h:
        (JSC::JSObject::putByIndexInline):
        (JSObject):
        (JSC::JSObject::putDirectIndex):
        * runtime/LiteralParser.cpp:
        (JSC::::parse):

2012-09-24  Mark Lam  <mark.lam@apple.com>

        Added a missing "if VALUE_PROFILER" around an access to ArrayProfile record.
        https://bugs.webkit.org/show_bug.cgi?id=97496.

        Reviewed by Filip Pizlo.

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

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

        Inlined activation tear-off in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=97487

        Reviewed by Filip Pizlo.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h: Activation tear-off is always inlined now, so I
        removed its out-of-line implementation.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Inlined the variable copy and update
        of JSVariableObject::m_registers. This usually turns into < 10 instructions,
        which is close to pure win as compared to the operation function call.

        * runtime/JSActivation.h:
        (JSActivation):
        (JSC::JSActivation::registersOffset):
        (JSC::JSActivation::tearOff):
        (JSC::JSActivation::isTornOff):
        (JSC):
        (JSC::JSActivation::storageOffset):
        (JSC::JSActivation::storage): Tiny bit of refactoring so the JIT can
        share the pointer math helper functions we use internally.

2012-09-24  Balazs Kilvady  <kilvadyb@homejinni.com>

        MIPS: store8 functions added to MacroAssembler.

        MIPS store8 functions
        https://bugs.webkit.org/show_bug.cgi?id=97243

        Reviewed by Oliver Hunt.

        Add MIPS store8 functions.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::lhu): New function.
        (MIPSAssembler):
        (JSC::MIPSAssembler::sb): New function.
        (JSC::MIPSAssembler::sh): New function.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::store8): New function.
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::store16): New function.

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

        PutScopedVar should not be marked as clobbering the world
        https://bugs.webkit.org/show_bug.cgi?id=97416

        Reviewed by Filip Pizlo.

        No performance change.

        PutScopedVar doesn't have arbitrary side-effects, so it shouldn't be marked
        as such.

        * dfg/DFGNodeType.h:
        (DFG):

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

        I accidentally the whole 32-bit :(.

        Unbreak the DFG in 32-bit with the 32-bit path I forgot in my last patch.

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

2012-09-23  Byungwoo Lee  <bw80.lee@gmail.com>

        Fix build warnings : -Wunused-parameter, -Wparentheses, -Wuninitialized.
        https://bugs.webkit.org/show_bug.cgi?id=97306

        Reviewed by Benjamin Poulain.

        Fix build warning about -Wunused-parameter on MachineStackMarker.cpp,
        LLIntSlowPaths.cpp, DatePrototype.cpp, Options.cpp by using
        UNUSED_PARAM() macro or remove parameter name.

        * heap/MachineStackMarker.cpp:
        (JSC::pthreadSignalHandlerSuspendResume):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::entryOSR):
        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):
        * runtime/Options.cpp:
        (JSC::computeNumberOfGCMarkers):

2012-09-23  Gavin Barraclough  <barraclough@apple.com>

        Sorting a non-array creates propreties (spec-violation)
        https://bugs.webkit.org/show_bug.cgi?id=25477

        Reviewed by Oliver Hunt.

        We're just calling get() to get properties, which is converting missing properties to
        undefined. Hole values should be retained, and moved to the end of the array.

        * runtime/ArrayPrototype.cpp:
        (JSC::getOrHole):
            - Helper function, returns JSValue() instead of undefined for missing properties.
        (JSC::arrayProtoFuncSort):
            - Implemented per 15.4.4.11, see comments above.

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

        CSE for access to closure variables (get_/put_scoped_var)
        https://bugs.webkit.org/show_bug.cgi?id=97414

        Reviewed by Oliver Hunt.

        I separated loading a scope from loading its storage pointer, so we can
        CSE the storage pointer load. Then, I copied the global var CSE and adjusted
        it for closure vars.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute): Renamed GetScopeChain => GetScope to
        reflect renames from a few weeks ago.

        Added a case for the storage pointer load, similar to object storage pointer load.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Added an independent node for
        the storage pointer.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::scopedVarLoadElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::scopedVarStoreElimination):
        (JSC::DFG::CSEPhase::getScopeLoadElimination):
        (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination):
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE): Copied globalVarLoad/StoreElimination
        and adapted the same logic to closure vars.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasScopeChainDepth):
        (JSC::DFG::Node::scope):
        (Node):
        * dfg/DFGNodeType.h:
        (DFG): GetScopedVar and GetGlobalVar are no longer MustGenerate. I'm not
        sure why they ever were. But these are simple load operations so, if they're
        unused, they're truly dead.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Updated for renames and split-out
        node for getting the storage pointer.

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

        Unreviewed, rolled out a line I committed by accident.

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

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

        Optimized closures that capture arguments
        https://bugs.webkit.org/show_bug.cgi?id=97358

        Reviewed by Oliver Hunt.

        Previously, the activation object was responsible for capturing all
        arguments in a way that was convenient for the arguments object. Now,
        we move all captured variables into a contiguous region in the stack,
        allocate an activation for exactly that size, and make the arguments
        object responsible for knowing all the places to which arguments could
        have moved.

        This seems like the right tradeoff because

            (a) Closures are common and long-lived, so we want them to be small.

            (b) Our primary strategy for optimizing the arguments object is to make
            it go away. If you're allocating arguments objects, you're already having
            a bad time.

            (c) It's common to use either the arguments object or named argument
            closure, but not both.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::argumentsRegister):
        (JSC::CodeBlock::activationRegister):
        (JSC::CodeBlock::isCaptured):
        (JSC::CodeBlock::argumentIndexAfterCapture): m_numCapturedVars is gone
        now -- we have an explicit range instead.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Move captured arguments
        into the captured region of local variables for space efficiency. Record
        precise data about where they moved for the sake of the arguments object.

        Some of this data was previously wrong, but it didn't cause any problems
        because the arguments weren't actually moving.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): Don't
        assume that captured vars are in any particular location -- always ask
        the CodeBlock. This is better encapsulation.

        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): I rename things sometimes.

        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff): Account for a particularly nasty edge case.

        (JSC::Arguments::didTearOffActivation): Don't allocate our slow arguments
        data on tear-off. We need to allocate it eagerly instead, since we need
        to know about displaced, captured arguments during access before tear-off.

        * runtime/Arguments.h:
        (JSC::Arguments::allocateSlowArguments):
        (JSC::Arguments::argument): Tell our slow arguments array where all arguments
        are, even if they are not captured. This simplifies some things, so we don't
        have to account explicitly for the full matrix of (not torn off, torn off)
        * (captured, not captured).

        (JSC::Arguments::finishCreation): Allocate our slow arguments array eagerly
        because we need to know about displaced, captured arguments during access
        before tear-off.

        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::parameterCount):
        (FunctionExecutable):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::visitChildren):
        * runtime/JSActivation.h:
        (JSActivation):
        (JSC::JSActivation::create):
        (JSC::JSActivation::JSActivation):
        (JSC::JSActivation::registerOffset):
        (JSC::JSActivation::tearOff):
        (JSC::JSActivation::allocationSize):
        (JSC::JSActivation::isValid): This is really the point of the patch. All
        the pointer math in Activations basically boils away, since we always
        copy a contiguous region of captured variables now.

        * runtime/SymbolTable.h:
        (JSC::SlowArgument::SlowArgument):
        (SlowArgument):
        (SharedSymbolTable):
        (JSC::SharedSymbolTable::captureCount):
        (JSC::SharedSymbolTable::SharedSymbolTable): AllOfTheThings capture mode
        is gone now -- that's the point of the patch. indexIfCaptured gets renamed
        to index because we always have an index, even if not captured. (The only
        time when the index is meaningless is when we're Deleted.)

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Eeeep - broke early boyer in bug#97382
        https://bugs.webkit.org/show_bug.cgi?id=97383

        Rubber stamped by Sam Weinig.

        missed a child3 -> child2!

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

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Unreviewed windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Pedantic test in Mozilla's JavaScript test suite fails. function-001.js function-001-n.js
        https://bugs.webkit.org/show_bug.cgi?id=27219

        Reviewed by Sam Weinig.

        These tests are just wrong.
        See ECMA 262 A.5, FunctionDelcaration does not require a semicolon.

        * tests/mozilla/expected.html:
        * tests/mozilla/js1_2/function/function-001-n.js:
        * tests/mozilla/js1_3/Script/function-001-n.js:
        * tests/mozilla/js1_3/regress/function-001-n.js:

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Remove redundant argument to op_instanceof
        https://bugs.webkit.org/show_bug.cgi?id=97382

        Reviewed by Geoff Garen.

        No longer needed after my last change.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitInstanceOf):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Unreviewed windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        instanceof should not get the prototype for non-default HasInstance
        https://bugs.webkit.org/show_bug.cgi?id=68656

        Reviewed by Oliver Hunt.

        Instanceof is currently implemented as a sequance of three opcodes:
            check_has_instance
            get_by_id(prototype)
            op_instanceof
        There are three interesting types of base value that instanceof can be applied to:
            (A) Objects supporting default instanceof behaviour (functions, other than those created with bind)
            (B) Objects overriding the default instancecof behaviour with a custom one (API objects, bound functions)
            (C) Values that do not respond to the [[HasInstance]] trap.
        Currently check_has_instance handles case (C), leaving the op_instanceof opcode to handle (A) & (B). There are
        two problems with this apporach. Firstly, this is suboptimal for case (A), since we have to check for
        hasInstance support twice (once in check_has_instance, then for default behaviour in op_instanceof). Secondly,
        this means that in cases (B) we also perform the get_by_id, which is both suboptimal and an observable spec
        violation.

        The fix here is to move handing of non-default instanceof (cases (B)) to the check_has_instance op, leaving
        op_instanceof to handle only cases (A).

        * API/JSCallbackObject.h:
        (JSCallbackObject):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::customHasInstance):
        * API/JSValueRef.cpp:
        (JSValueIsInstanceOfConstructor):
            - renamed hasInstance to customHasInstance
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
            - added additional parameters to check_has_instance opcode
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
            - added additional parameters to check_has_instance opcode
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCheckHasInstance):
            - added additional parameters to check_has_instance opcode
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
            - added additional parameters to check_has_instance opcode
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
            - added additional parameters to check_has_instance opcode
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
            - added additional parameters to check_has_instance opcode
        * interpreter/Interpreter.cpp:
        (JSC::isInvalidParamForIn):
        (JSC::Interpreter::privateExecute):
            - Add handling for non-default instanceof to op_check_has_instance
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitArrayProfilingSiteForBytecodeIndex):
            - Fixed no-LLInt no_DFG build
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_check_has_instance):
        (JSC::JIT::emitSlow_op_check_has_instance):
            - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance.
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
            - no need to check for ImplementsDefaultHasInstance.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_check_has_instance):
        (JSC::JIT::emitSlow_op_check_has_instance):
            - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance.
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
            - no need to check for ImplementsDefaultHasInstance.
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:
            - Add handling for non-default instanceof to op_check_has_instance
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
            - move check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance.
        * runtime/ClassInfo.h:
        (MethodTable):
        (JSC):
            - renamed hasInstance to customHasInstance
        * runtime/CommonSlowPaths.h:
        (CommonSlowPaths):
            - removed opInstanceOfSlow (this was whittled down to one function call!)
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::customHasInstance):
        * runtime/JSBoundFunction.h:
        (JSBoundFunction):
            - renamed hasInstance to customHasInstance, reimplemented.
        * runtime/JSCell.cpp:
        (JSC::JSCell::customHasInstance):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        (JSC):
        (JSC::JSObject::defaultHasInstance):
        * runtime/JSObject.h:
        (JSObject):

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

        Unreviewed, fix ARM build.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (MacroAssemblerARMv7):
        * offlineasm/armv7.rb:

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

        REGRESSION (r128400): Opening Google Web Fonts page hangs or crashes
        https://bugs.webkit.org/show_bug.cgi?id=97328

        Reviewed by Mark Hahnenberg.

        It's a bad idea to emit stub code that reallocates property storage when we're in indexed
        storage mode. DFGRepatch.cpp knew this and had the appropriate check in one of the places,
        but it didn't have it in all of the places.
        
        This change also adds some more handy disassembly support, which I used to find the bug.

        * assembler/LinkBuffer.h:
        (JSC):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryCachePutByID):
        * jit/JITStubRoutine.h:
        (JSC):

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

        DFG CSE assumes that a holy PutByVal does not interfere with GetArrayLength, when it clearly does
        https://bugs.webkit.org/show_bug.cgi?id=97373

        Reviewed by Mark Hahnenberg.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::pureCSE):
        (JSC::DFG::CSEPhase::getArrayLengthElimination):
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGGraph.h:
        (Graph):

2012-09-21  Chris Rogers  <crogers@google.com>

        Add Web Audio support for deprecated/legacy APIs
        https://bugs.webkit.org/show_bug.cgi?id=97050

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Global Math object should be configurable but isn't
        https://bugs.webkit.org/show_bug.cgi?id=55343

        Reviewed by Oliver Hunt.

        This has no performance impact.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
            - Make 'Math' a regular property.

2012-09-21  Chao-ying Fu  <fu@mips.com>

        Add MIPS or32 function
        https://bugs.webkit.org/show_bug.cgi?id=97157

        Reviewed by Gavin Barraclough.

        Add a missing or32 function.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::or32): New function.
        (MacroAssemblerMIPS):

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

        CHECK_ARRAY_CONSISTENCY isn't being used or tested, so we should remove it
        https://bugs.webkit.org/show_bug.cgi?id=97260

        Rubber stamped by Geoffrey Garen.
        
        Supporting it will become difficult as we add more indexing types. It makes more
        sense to kill, especially since we don't appear to use it or test it, ever.

        * runtime/ArrayConventions.h:
        (JSC):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::copyHeaderFromDuringGC):
        (ArrayStorage):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/JSArray.cpp:
        (JSC::createArrayButterflyInDictionaryIndexingMode):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSArray):
        (JSC::createArrayButterfly):
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::constructArray):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC):
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        (JSObject):

2012-09-20  Mark Lam  <mark.lam@apple.com>

        Fixed a missing semicolon in the C++ llint backend.
        https://bugs.webkit.org/show_bug.cgi?id=97252.

        Reviewed by Geoff Garen.

        * offlineasm/cloop.rb:

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

        Refactored the interpreter and JIT so they don't dictate closure layout
        https://bugs.webkit.org/show_bug.cgi?id=97221

        Reviewed by Oliver Hunt.

        Capture may change the location of an argument for space efficiency. This
        patch removes static assumptions about argument location from the interpreter
        and JIT.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::argumentIndexAfterCapture):
        (JSC::ExecState::argumentAfterCapture): Factored out a helper function
        so the compiler could share this logic.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode): Don't emit optimized bracket
        access on arguments if a parameter has been captured by name. This case is
        rare and, where I've seen it in the wild, the optimization mostly failed
        anyway due to arguments escape, so I didn't feel like writing and testing
        five copies of the code that would handle it in the baseline engines.

        The DFG can still synthesize this optimization even if we don't emit the
        optimized bytecode for it.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::symbolTableFor):
        (AssemblyHelpers): Use the right helper function to account for the fact
        that a parameter may have been captured by name and moved.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): ASSERT that we haven't inlined
        a .apply on captured arguments. Once we do start inlining such things,
        we'll need to do a little bit of math here to get them right.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Added support for bracket access on
        an arguments object where arguments have also been captured by name. We
        load the true index of the argument from a side vector. Arguments elision
        is very powerful in the DFG, so I wanted to keep it working, even in this
        rare case.

        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs): Use the right helper function to account for the fact
        that a parameter may have been captured by name and moved.

        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileLoadVarargs): Don't use the inline copy loop if some
        of our arguments have moved, since it would copy stale values. (We still
        optimize the actual call, and elide the arguments object.)

2012-09-20  Gabor Rapcsanyi  <rgabor@webkit.org>

        [Qt] r129045 broke the ARM build
        https://bugs.webkit.org/show_bug.cgi?id=97195

        Reviewed by Zoltan Herczeg.

        Implementing missing store8 function.

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

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

        OSR exit sometimes neglects to create the arguments object
        https://bugs.webkit.org/show_bug.cgi?id=97162

        Reviewed by Filip Pizlo.

        No performance change.

        I don't know of any case where this is a real problem in TOT, but it
        will become a problem if we start compiling eval, with, or catch, and/or
        sometimes stop doing arguments optimizations in the bytecode.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run): Account for a
        CreateArguments that has transformed into PhantomArguments. We used to
        clear our reference to the CreateArguments node, but now we hold onto it, 
        so we need to account for it transforming.

        Don't replace a SetLocal(CreateArguments) with a SetLocal(JSValue())
        because that doesn't leave enough information behind for OSR exit to do
        the right thing. Instead, maintain our reference to CreateArguments, and
        rely on CreateArguments transforming into PhantomArguments after
        optimization. SetLocal(PhantomArguments) is efficient, and it's a marker
        for OSR exit to create the arguments object.

        Don't ASSERT that all PhantomArguments are unreferenced because we now
        leave them in the graph as SetLocal(PhantomArguments), and that's harmless.

        * dfg/DFGArgumentsSimplificationPhase.h:
        (NullableHashTraits):
        (JSC::DFG::NullableHashTraits::emptyValue): Export our special hash table
        for inline call frames so the OSR exit compiler can use it.

        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit): Don't load the 'arguments'
        register to decide if we need to create the arguments object. Optimization
        may have eliminated the initializing store to this register, in which
        case we'll load garbage. Instead, use the global knowledge that all call
        frames that optimized out 'arguments' now need to create it, and use a hash
        table to make sure we do so only once per call frame.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): SetLocal(PhantomArguments) is unique
        because we haven't just changed a value's format or elided a load or store;
        instead, we've replaced an object with JSValue(). We could try to account
        for this in a general way, but for now it's a special-case optimization,
        so we give it a specific OSR hint instead.

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

        REGRESSION(r128802): It made some JS tests crash
        https://bugs.webkit.org/show_bug.cgi?id=97001

        Reviewed by Mark Hahnenberg.

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

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

        DFG should not assume that a ByVal access is generic just because it was unprofiled
        https://bugs.webkit.org/show_bug.cgi?id=97088

        Reviewed by Geoffrey Garen.
        
        We were not disambiguating between "Undecided" in the sense that the array profile
        has no useful information versus "Undecided" in the sense that the array profile
        knows that the access has not executed. That's an important distinction, since
        the former form of "Undecided" means that we should consult value profiling, while
        the latter means that we should force exit unless the value profiling indicates
        that the access must be generic (base is not cell or property is not int).

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::refineArrayMode):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::modeIsSpecific):
        (JSC::DFG::modeSupportsLength):
        (JSC::DFG::benefitsFromStructureCheck):

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

        DFG should not emit PutByVal hole case unless it has to
        https://bugs.webkit.org/show_bug.cgi?id=97080

        Reviewed by Geoffrey Garen.

        This causes us to generate less code for typical PutByVal's. But if profiling tells us
        that the hole case is being hit, we generate the same code as we would have generated
        before. This seems like a slight speed-up across the board.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (MacroAssemblerARMv7):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::store8):
        * assembler/MacroAssemblerX86_64.h:
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::store8):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::movb_i8m):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (JSC::ArrayProfile::addressOfMayStoreToHole):
        (JSC::ArrayProfile::mayStoreToHole):
        (ArrayProfile):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::mayStoreToHole):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase):
        (JSC):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_by_val):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        DFG should not call out to C++ every time that it tries to put to an object that doesn't yet have array storage
        https://bugs.webkit.org/show_bug.cgi?id=96983

        Reviewed by Oliver Hunt.

        Introduce more polymorphism into the DFG's array mode support. Use that to
        introduce the notion of effectul array modes, where the check for the mode
        will perform actions necessary to ensure that we have the mode we want, if
        the object is not already in that mode. Also added profiling support for
        checking if an object is of a type that would not allow us to create array
        storage (like a typed array or a string for example).
        
        This is a ~2x speed-up on loops that transform an object that did not have
        indexed storage into one that does.

        * JSCTypedArrayStubs.h:
        (JSC):
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (JSC::ArrayProfile::mayInterceptIndexedAccesses):
        (ArrayProfile):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (DFG):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::modeUsesButterfly):
        (JSC::DFG::isSlowPutAccess):
        (JSC::DFG::benefitsFromStructureCheck):
        (JSC::DFG::isEffectful):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArrayMode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (DFG):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/Arguments.h:
        (Arguments):
        * runtime/JSNotAnObject.h:
        (JSNotAnObject):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::ensureArrayStorage):
        * runtime/JSString.h:
        (JSC::JSString::createStructure):

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

        Include PhantomArguments in DFGDisassembly
        https://bugs.webkit.org/show_bug.cgi?id=97043

        Reviewed by Geoffrey Garen.

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

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

        REGRESSION(r128802): It made some JS tests crash
        https://bugs.webkit.org/show_bug.cgi?id=97001

        Reviewed by Mark Hahnenberg.

        IndexingHeaderInlineMethods was incorrectly assuming that if the HasArrayStorage bit is clear, then that means that indexing payload capacity is zero.

        * runtime/IndexingHeaderInlineMethods.h:
        (JSC::IndexingHeader::preCapacity):
        (JSC::IndexingHeader::indexingPayloadSizeInBytes):

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

        Use WTF::HasTrivialDestructor instead of compiler-specific versions in JSC::NeedsDestructor
        https://bugs.webkit.org/show_bug.cgi?id=96980

        Reviewed by Benjamin Poulain.

        * runtime/JSCell.h:
        (JSC):
        (NeedsDestructor):

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

        DFGOperations doesn't use NativeCallFrameTracer in enough places
        https://bugs.webkit.org/show_bug.cgi?id=96987

        Reviewed by Mark Hahnenberg.

        Anything that can GC should use it.

        * dfg/DFGOperations.cpp:

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

        Not reviewed. Attempt at greening the WinCairo bot. Touching
        LowLevelInterpreter.asm to trigger a rebuild of LLIntDesiredOffsets.
        https://bugs.webkit.org/show_bug.cgi?id=96992.

        * llint/LowLevelInterpreter.asm:

2012-09-18  Peter Gal  <galpeter@inf.u-szeged.hu>

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

        Reviewed by Filip Pizlo.

        Implement the missing or32 method in the MacroAssemblerARM.h.

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

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

        Fix for WinCairo builds.
        https://bugs.webkit.org/show_bug.cgi?id=96992.

        Reviewed by Filip Pizlo.

        Adding additional vcproj build targets in LLIntDesiredOffsets.vcproj,
        LLIntOffsetsExtractor.vcproj, and LLIntAssembly.vcproj to match those
        in jsc.vcproj.

        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj:
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj:
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj:
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Added.

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

        Unreviewed, fix sloppy English in comment.

        * runtime/JSGlobalObject.cpp:
        (JSC):

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

        Unreviewed, rolling out r128826 and r128813.

        * API/JSCallbackConstructor.cpp:
        (JSC):
        (JSC::JSCallbackConstructor::JSCallbackConstructor):
        * API/JSCallbackConstructor.h:
        (JSCallbackConstructor):
        * API/JSCallbackObject.cpp:
        (JSC):
        (JSC::::createStructure):
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObject::create):
        (JSCallbackObject):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::prototype):
        * API/JSObjectRef.cpp:
        (JSObjectMake):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSValueRef.cpp:
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * GNUmakefile.list.am:
        * JSCTypedArrayStubs.h:
        (JSC):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject):
        * heap/Heap.cpp:
        (JSC::Heap::isSafeToSweepStructures):
        (JSC):
        * heap/Heap.h:
        (JSC::Heap::allocatorForObjectWithDestructor):
        (Heap):
        (JSC::Heap::allocateWithDestructor):
        (JSC::Heap::allocateStructure):
        (JSC):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::sweepNextBlock):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping):
        (JSC::IncrementalSweeper::structuresCanBeSwept):
        (JSC):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::cellsNeedDestruction):
        (JSC::MarkedAllocator::onlyContainsStructures):
        (MarkedAllocator):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedBlock.h:
        (JSC):
        (MarkedBlock):
        (JSC::MarkedBlock::cellsNeedDestruction):
        (JSC::MarkedBlock::onlyContainsStructures):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (Subspace):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateStructure):
        (JSC::MarkedSpace::forEachBlock):
        * heap/SlotVisitor.cpp:
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateJSFinalObject):
        (JSC::JIT::emitAllocateJSArray):
        * jsc.cpp:
        (GlobalObject::create):
        * runtime/Arguments.cpp:
        (JSC):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::Arguments):
        * runtime/ErrorPrototype.cpp:
        (JSC):
        * runtime/Executable.h:
        * runtime/InternalFunction.cpp:
        (JSC):
        (JSC::InternalFunction::InternalFunction):
        * runtime/InternalFunction.h:
        (InternalFunction):
        * runtime/JSCell.h:
        (JSC):
        (JSC::allocateCell):
        * runtime/JSDestructibleObject.h: Removed.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::createRareDataIfNeeded):
        (JSC::JSGlobalObject::create):
        * runtime/JSGlobalThis.h:
        (JSGlobalThis):
        (JSC::JSGlobalThis::JSGlobalThis):
        * runtime/JSPropertyNameIterator.h:
        * runtime/JSScope.cpp:
        (JSC):
        * runtime/JSString.h:
        (JSC):
        * runtime/JSWrapperObject.h:
        (JSWrapperObject):
        (JSC::JSWrapperObject::JSWrapperObject):
        * runtime/MathObject.cpp:
        (JSC):
        * runtime/NameInstance.h:
        (NameInstance):
        * runtime/RegExp.h:
        * runtime/RegExpObject.cpp:
        (JSC):
        * runtime/SparseArrayValueMap.h:
        * runtime/Structure.h:
        (JSC::Structure):
        (JSC::JSCell::classInfo):
        (JSC):
        * runtime/StructureChain.h:
        * runtime/SymbolTable.h:
        * testRegExp.cpp:
        (GlobalObject::create):

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

        Refactored the arguments object so it doesn't dictate closure layout
        https://bugs.webkit.org/show_bug.cgi?id=96955

        Reviewed by Oliver Hunt.

        * bytecode/CodeBlock.h:
        (JSC::ExecState::argumentAfterCapture): Helper function for accessing an
        argument that has been moved for capture.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Generate metadata for arguments
        that are captured. We don't move any arguments yet, but we do use this
        metadata to tell the arguments object if an argument is stored in the
        activation.

        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Updated for the arguments object not
        malloc'ing a separate backing store, and for a rename from deletedArguments
        to slowArguments.

        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::privateExecute):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Updated for small interface changes.

        * runtime/Arguments.cpp:
        (JSC::Arguments::visitChildren):
        (JSC::Arguments::copyToArguments):
        (JSC::Arguments::fillArgList):
        (JSC::Arguments::getOwnPropertySlotByIndex):
        (JSC::Arguments::createStrictModeCallerIfNecessary):
        (JSC::Arguments::createStrictModeCalleeIfNecessary):
        (JSC::Arguments::getOwnPropertySlot):
        (JSC::Arguments::getOwnPropertyDescriptor):
        (JSC::Arguments::getOwnPropertyNames):
        (JSC::Arguments::putByIndex):
        (JSC::Arguments::put):
        (JSC::Arguments::deletePropertyByIndex):
        (JSC::Arguments::deleteProperty):
        (JSC::Arguments::defineOwnProperty):
        (JSC::Arguments::tearOff): Moved all data inline into the object, for speed,
        and refactored all internal argument accesses to use helper functions, so
        we can change the implementation without changing lots of code.

        (JSC::Arguments::didTearOffActivation): This function needs to account
        for arguments that were moved by the activation object. We do this accounting
        through a side vector that tells us where our arguments will be in the
        activation.

        (JSC::Arguments::tearOffForInlineCallFrame):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::length):
        (JSC::Arguments::isTornOff):
        (JSC::Arguments::Arguments):
        (JSC::Arguments::allocateSlowArguments):
        (JSC::Arguments::tryDeleteArgument):
        (JSC::Arguments::trySetArgument):
        (JSC::Arguments::tryGetArgument):
        (JSC::Arguments::isDeletedArgument):
        (JSC::Arguments::isArgument):
        (JSC::Arguments::argument):
        (JSC::Arguments::finishCreation):

        * runtime/JSActivation.h:
        (JSC::JSActivation::create):
        (JSActivation):
        (JSC::JSActivation::captureStart):
        (JSC::JSActivation::storageSize):
        (JSC::JSActivation::registerOffset):
        (JSC::JSActivation::isValid): The activation object is no longer responsible
        for copying extra arguments provided by the caller. The argumnents object
        does this instead. This means we can allocate and initialize an activation
        without worrying about the call frame's argument count.

        * runtime/SymbolTable.h:
        (JSC::SlowArgument::SlowArgument):
        (SlowArgument):
        (JSC):
        (JSC::SharedSymbolTable::parameterCount):
        (SharedSymbolTable):
        (JSC::SharedSymbolTable::slowArguments):
        (JSC::SharedSymbolTable::setSlowArguments): Added data structures to back
        the algorithms above.

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

        32-bit LLInt get_by_val does vector length checks incorrectly
        https://bugs.webkit.org/show_bug.cgi?id=96893
        <rdar://problem/12311678>

        Reviewed by Mark Hahnenberg.

        * llint/LowLevelInterpreter32_64.asm:

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

        We don't have a bad enough time if an object's prototype chain crosses global objects
        https://bugs.webkit.org/show_bug.cgi?id=96962

        Reviewed by Geoffrey Garen.

        * runtime/JSGlobalObject.cpp:
        (JSC):

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

        Unreviewed, fix a broken assertion in offlineasm.

        * offlineasm/armv7.rb:
        * offlineasm/backends.rb:

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

        Delayed structure sweep can leak structures without bound
        https://bugs.webkit.org/show_bug.cgi?id=96546

        Reviewed by Gavin Barraclough.

        This patch gets rid of the separate Structure allocator in the MarkedSpace and adds two new destructor-only
        allocators. We now have separate allocators for our three types of objects: those objects with no destructors,
        those objects with destructors and with immortal structures, and those objects with destructors that don't have 
        immortal structures. All of the objects of the third type (destructors without immortal structures) now 
        inherit from a new class named JSDestructibleObject (which in turn is a subclass of JSNonFinalObject), which stores 
        the ClassInfo for these classes at a fixed offset for safe retrieval during sweeping/destruction.

        * API/JSCallbackConstructor.cpp: Use JSDestructibleObject for JSCallbackConstructor.
        (JSC):
        (JSC::JSCallbackConstructor::JSCallbackConstructor):
        * API/JSCallbackConstructor.h:
        (JSCallbackConstructor):
        * API/JSCallbackObject.cpp: Inherit from JSDestructibleObject for normal JSCallbackObjects and use a finalizer for 
        JSCallbackObject<JSGlobalObject>, since JSGlobalObject also uses a finalizer.
        (JSC):
        (JSC::::create): We need to move the create function for JSCallbackObject<JSGlobalObject> out of line so we can add 
        the finalizer for it. We don't want to add the finalizer is something like finishCreation in case somebody decides 
        to subclass this. We use this same technique for many other subclasses of JSGlobalObject.
        (JSC::::createStructure):
        * API/JSCallbackObject.h:
        (JSCallbackObject):
        (JSC):
        * API/JSClassRef.cpp: Change all the JSCallbackObject<JSNonFinalObject> to use JSDestructibleObject instead.
        (OpaqueJSClass::prototype):
        * API/JSObjectRef.cpp: Ditto.
        (JSObjectMake):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSValueRef.cpp: Ditto.
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp: Ditto.
        * JSCTypedArrayStubs.h:
        (JSC):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.h: Use the proper allocator type when doing inline allocation in the DFG.
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject):
        * heap/Heap.cpp:
        (JSC):
        * heap/Heap.h: Add accessors for the various types of allocators now. Also remove the isSafeToSweepStructures function 
        since it's always safe to sweep Structures now.
        (JSC::Heap::allocatorForObjectWithNormalDestructor): 
        (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor):
        (Heap):
        (JSC::Heap::allocateWithNormalDestructor):
        (JSC):
        (JSC::Heap::allocateWithImmortalStructureDestructor):
        * heap/IncrementalSweeper.cpp: Remove all the logic to detect when it's safe to sweep Structures from the 
        IncrementalSweeper since it's always safe to sweep Structures now.
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::sweepNextBlock):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping):
        (JSC):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp: Remove the logic that was preventing us from sweeping Structures if it wasn't safe. Add 
        tracking of the specific destructor type of allocator. 
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::destructorType):
        (MarkedAllocator):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        * heap/MarkedBlock.cpp: Add all the destructor type stuff to MarkedBlocks so that we do the right thing when sweeping. 
        We also use the stored destructor type to determine the right thing to do in all JSCell::classInfo() calls.
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedBlock.h:
        (JSC):
        (JSC::MarkedBlock::allocator):
        (JSC::MarkedBlock::destructorType):
        * heap/MarkedSpace.cpp: Add the new destructor allocators to MarkedSpace.
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor):
        (JSC::MarkedSpace::normalDestructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithImmortalStructureDestructor):
        (JSC::MarkedSpace::allocateWithNormalDestructor):
        (JSC::MarkedSpace::forEachBlock):
        * heap/SlotVisitor.cpp: Add include because the symbol was needed in an inlined function.
        * jit/JIT.h: Make sure we use the correct allocator when doing inline allocations in the baseline JIT.
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateJSFinalObject):
        (JSC::JIT::emitAllocateJSArray):
        * jsc.cpp: 
        (GlobalObject::create): Add finalizer here since JSGlobalObject needs to use a finalizer instead of inheriting from 
        JSDestructibleObject.
        * runtime/Arguments.cpp: Inherit from JSDestructibleObject.
        (JSC):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::Arguments):
        * runtime/ErrorPrototype.cpp: Added an assert to make sure we have a trivial destructor.
        (JSC):
        * runtime/Executable.h: Indicate that all of the Executable* classes have immortal Structures.
        (JSC):
        * runtime/InternalFunction.cpp: Inherit from JSDestructibleObject.
        (JSC):
        (JSC::InternalFunction::InternalFunction):
        * runtime/InternalFunction.h:
        (InternalFunction):
        * runtime/JSCell.h: Added the NEEDS_DESTRUCTOR  macro to make it easier for classes to indicate that instead of being 
        allocated in a destructor MarkedAllocator that they will handle their destruction themselves through the 
        use of a finalizer.
        (JSC):
        (HasImmortalStructure): New template to help us determine at compile-time if a particular class 
        should be allocated in the immortal structure MarkedAllocator. The default value is false. In order 
        to be allocated in the immortal structure allocator, classes must specialize this template. Also added 
        a macro to make it easier for classes to specialize the template.
        (JSC::allocateCell): Use the appropriate allocator depending on the destructor type.
        * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be 
        accessed safely when the object is being destroyed.
        (JSC):
        (JSDestructibleObject):
        (JSC::JSDestructibleObject::classInfo):
        (JSC::JSDestructibleObject::JSDestructibleObject):
        (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe.
        * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all 
        of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well.
        (JSC::JSGlobalObject::reset):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one 
        for the m_rareData field when it's created.
        (JSC::JSGlobalObject::create):
        (JSC):
        * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject.
        (JSGlobalThis):
        (JSC::JSGlobalThis::JSGlobalThis):
        * runtime/JSPropertyNameIterator.h: Has an immortal Structure.
        (JSC):
        * runtime/JSScope.cpp:
        (JSC):
        * runtime/JSString.h: Has an immortal Structure.
        (JSC):
        * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject.
        (JSWrapperObject):
        (JSC::JSWrapperObject::JSWrapperObject):
        * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff.
        (JSC):
        * runtime/NameInstance.h: Inherit from JSDestructibleObject.
        (NameInstance):
        * runtime/RegExp.h: Has immortal Structure.
        (JSC):
        * runtime/RegExpObject.cpp: Inheritance cleanup.
        (JSC):
        * runtime/SparseArrayValueMap.h: Has immortal Structure.
        (JSC):
        * runtime/Structure.h: Has immortal Structure.
        (JSC):
        * runtime/StructureChain.h: Ditto.
        (JSC):
        * runtime/SymbolTable.h: Ditto.
        (SharedSymbolTable):
        (JSC):

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

        If a prototype has indexed setters and its instances have indexed storage, then all put_by_val's should have a bad time
        https://bugs.webkit.org/show_bug.cgi?id=96596

        Reviewed by Gavin Barraclough.

        Added comprehensive support for accessors and read-only indexed properties on the
        prototype chain. This is done without any performance regression on benchmarks that
        we're aware of, by having the entire VM's strategy with respect to arrays tilted
        heavily in favor of:
        
        - The prototype chain of JSArrays never having any accessors or read-only indexed
          properties. If that changes, you're going to have a bad time.
        
        - Prototypes of non-JSArray objects either having no indexed accessors or read-only
          indexed properties, or, having those indexed accessor thingies inserted before
          any instance object (i.e. object with that prototype as its prototype) is created.
          If you add indexed accessors or read-only indexed properties to an object that is
          already used as a prototype, you're going to have a bad time.
        
        See below for the exact definition of having a bad time.
        
        Put another way, "fair" uses of indexed accessors and read-only indexed properties
        are:
        
        - Put indexed accessors and read-only indexed properties on an object that is never
          used as a prototype. This will slow down accesses to that object, but will not
          have any effect on any other object.
        
        - Put those indexed accessor thingies on an object before it is used as a prototype
          and then start instantiating objects that claim that object as their prototype.
          This will slightly slow down indexed stores to the instance objects, and greatly
          slow down all indexed accesses to the prototype, but will have no other effect.
        
        In short, "fair" uses only affect the object itself and any instance objects. But
        if you start using indexed accessors in more eclectic ways, you're going to have
        a bad time.
        
        Specifically, if an object that may be used as a prototype has an indexed accessor
        added, the VM performs a whole-heap scan to find all objects that belong to the
        same global object as the prototype you modified. If any of those objects has
        indexed storage, their indexed storage is put into slow-put mode, just as if their
        prototype chain had indexed accessors. This will happen even for objects that do
        not currently have indexed accessors in their prototype chain. As well, all JSArray
        allocations are caused to create arrays with slow-put storage, and all future
        allocations of indexed storage for non-JSArray objects are also flipped to slow-put
        mode. Note there are two aspects to having a bad time: (i) the whole-heap scan and
        (ii) the poisoning of all indexed storage in the entire global object. (i) is
        necessary for correctness. If we detect that an object that may be used as a
        prototype has had an indexed accessor or indexed read-only property inserted into
        it, then we need to ensure that henceforth all instances of that object inspect
        the prototype chain whenever an indexed hole is stored to. But by default, indexed
        stores do no such checking because doing so would be unnecessarily slow. So, we must
        find all instances of the affected object and flip them into a different array
        storage mode that omits all hole optimizations. Since prototypes never keep a list
        of instance objects, the only way to find those objects is a whole-heap scan. But
        (i) alone would be a potential disaster, if a program frequently allocated an
        object without indexed accessors, then allocated a bunch of objects that used that
        one as their prototype, and then added indexed accessors to the prototype. So, to
        prevent massive heap scan storms in such awkward programs, having a bad time also
        implies (ii): henceforth *all* objects belonging to that global object will use
        slow put indexed storage, so that we don't ever have to scan the heap again. Note
        that here we are using the global object as just an approximation of a program
        module; it may be worth investigating in the future if other approximations can be
        used instead.

        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::arrayModeFromStructure):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::isSlowPutAccess):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateJSArray):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncSort):
        * runtime/IndexingType.h:
        (JSC):
        (JSC::hasIndexedProperties):
        (JSC::hasIndexingHeader):
        (JSC::hasArrayStorage):
        (JSC::shouldUseSlowPut):
        * runtime/JSArray.cpp:
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::reset):
        (JSC):
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::addressOfArrayStructure):
        (JSC::JSGlobalObject::havingABadTimeWatchpoint):
        (JSC::JSGlobalObject::isHavingABadTime):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::put):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::resetInheritorID):
        (JSC::JSObject::inheritorID):
        (JSC::JSObject::allowsAccessFrom):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::unwrappedGlobalObject):
        (JSC::JSObject::notifyUsedAsPrototype):
        (JSC::JSObject::createInheritorID):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::mayBeUsedAsPrototype):
        (JSObject):
        (JSC::JSObject::mayInterceptIndexedAccesses):
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::completeInitialization):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::arrayStorage):
        (JSC::JSObject::arrayStorageOrNull):
        (JSC::JSObject::ensureArrayStorage):
        (JSC):
        (JSC::JSValue::putByIndex):
        * runtime/JSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        (JSC):
        * runtime/JSValue.h:
        (JSValue):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayEntry::put):
        (JSC):
        * runtime/SparseArrayValueMap.h:
        (JSC):
        (SparseArrayEntry):
        * runtime/Structure.cpp:
        (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses):
        (JSC):
        (JSC::Structure::suggestedIndexingTransition):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::mayInterceptIndexedAccesses):
        * runtime/StructureTransitionTable.h:
        (JSC::newIndexingType):

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

        Array profiling has convergence issues
        https://bugs.webkit.org/show_bug.cgi?id=96891

        Reviewed by Gavin Barraclough.

        Now each array profiling site merges in the indexing type it observed into
        the m_observedArrayModes bitset. The ArrayProfile also uses this to detect
        cases where the structure must have gone polymorphic (if the bitset is
        polymorphic then the structure must be). This achieves something like the
        best of both worlds: on the one hand, we get a probabilistic structure that
        we can use to optimize the monomorphic structure case, but on the other hand,
        we get an accurate view of the set of types that were encountered.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::or32):
        (MacroAssemblerARMv7):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::or32):
        (MacroAssemblerX86):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::or32):
        (MacroAssemblerX86_64):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::orl_rm):
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::addressOfArrayModes):
        (JSC::ArrayProfile::structureIsPolymorphic):
        * jit/JIT.h:
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC):
        (JSC::JIT::emitArrayProfilingSite):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2012-09-17  Mark Lam  <mark.lam@apple.com>

        Not reviewed. Added svn:eol-style native to unbreak some build bots.
        https://bugs.webkit.org/show_bug.cgi?id=96175.

        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added property svn:eol-style.

2012-09-16  Mark Lam  <mark.lam@apple.com>

        Added MSVC project changes to enable building the llint.
        https://bugs.webkit.org/show_bug.cgi?id=96175.

        Reviewed by Geoff Garen.

        This only adds the ability to build the llint, but currently, only the
        C++ backend is supported. By default, the Windows port will remain
        running with the baseline JIT.  The llint will not be enabled.

        * JavaScriptCore.vcproj/JavaScriptCore.sln:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcproj/LLIntAssembly: Added.
        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Added.
        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added.
        * JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added.

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

        JSObject.cpp and JSArray.cpp have inconsistent tests for the invalid array index case
        https://bugs.webkit.org/show_bug.cgi?id=96878

        Reviewed by Sam Weinig.

        Removed the uses of UNLIKELY() because I don't believe they are buying us anything,
        since we're already on the slow path. Also found other places where we're testing for
        the invalid array index case using unusual predicates rather than just using
        MAX_ARRAY_INDEX. With this change, I believe that all of our tests for invalid
        array indices (i.e. indices that should be treated as non-indexed properties)
        uniformly use MAX_ARRAY_INDEX and PropertyName::NotAnIndex.

        * runtime/JSArray.cpp:
        (JSC::JSArray::push):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::defineOwnIndexedProperty):

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

        Following the Butterfly refactoring, the comment for lastArraySize was not updated
        https://bugs.webkit.org/show_bug.cgi?id=96877

        Reviewed by Sam Weinig.

        * runtime/JSObject.cpp:
        (JSC):

2012-09-15  Mark Lam  <mark.lam@apple.com>

        Fixed JSLock to use the platform abstraction for Mutex instead of
        depending on pthreads.
        https://bugs.webkit.org/show_bug.cgi?id=96858.

        Reviewed by Filip Pizlo.

        This fixes a synchronization problem on the Windows port and makes
        it more reliable when running the layout tests.

        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/JSLock.cpp:
        (JSC):
        (JSC::GlobalJSLock::GlobalJSLock):
        (JSC::GlobalJSLock::~GlobalJSLock):
        (JSC::GlobalJSLock::initialize):
        * runtime/JSLock.h:
        (GlobalJSLock):
        (JSLock):

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

        Structure check hoisting fails to consider the possibility of conflicting checks on the source of the first assignment to the hoisted variable
        https://bugs.webkit.org/show_bug.cgi?id=96872

        Reviewed by Oliver Hunt.

        This does a few related things:
        
        - It turns off the use of ForceOSRExit for sure-to-fail CheckStructures, because
          I noticed that this would sometimes happen for a ForwardCheckStructure. The
          problem is that ForceOSRExit exits backwards, not forwards. Since the code that
          led to those ForceOSRExit's being inserted was written out of paranoia rather
          than need, I removed it. Specifically, I removed the m_isValid = false code
          for CheckStructure/StructureTransitionWatchpoint in AbstractState.
        
        - If a structure check causes a structure set to go empty, we don't want a
          PutStructure to revive the set. It should instead be smart enough to realize 
          that an empty set implies that the code can't execute. This was the only "bug"
          that the use of m_isValid = false was preventing.
        
        - Finally, the main change: structure check hoisting looks at the source of the
          SetLocals on structure-check-hoistable variables and ensures that the source
          is not checked with a conflicting structure. This is O(n^2) but it does not
          show up at all in performance tests.
        
        The first two parts of this change were auxiliary bugs that were revealed by
        the structure check hoister doing bad things.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

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

        All of the things in SparseArrayValueMap should be out-of-line
        https://bugs.webkit.org/show_bug.cgi?id=96854

        Reviewed by Andy Estes.

        Those inline methods were buying us nothing.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSArray.cpp:
        * runtime/JSGlobalData.cpp:
        * runtime/JSObject.cpp:
        * runtime/RegExpMatchesArray.cpp:
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::SparseArrayValueMap):
        (JSC):
        (JSC::SparseArrayValueMap::~SparseArrayValueMap):
        (JSC::SparseArrayValueMap::finishCreation):
        (JSC::SparseArrayValueMap::create):
        (JSC::SparseArrayValueMap::destroy):
        (JSC::SparseArrayValueMap::createStructure):
        (JSC::SparseArrayValueMap::add):
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayEntry::get):
        (JSC::SparseArrayEntry::getNonSparseMode):
        (JSC::SparseArrayValueMap::visitChildren):
        * runtime/SparseArrayValueMapInlineMethods.h: Removed.

2012-09-14  Mike West  <mkwst@chromium.org>

        JSC should throw a more descriptive exception when blocking 'eval' via CSP.
        https://bugs.webkit.org/show_bug.cgi?id=94331

        Reviewed by Geoffrey Garen.

        Unless explicitly whitelisted, the 'script-src' Content Security Policy
        directive blocks 'eval' and 'eval'-like constructs such as
        'new Function()'. When 'eval' is encountered in code, an 'EvalError' is
        thrown, but the associated message is poor: "Eval is disabled" doesn't
        give developers enough information about why their code isn't behaving
        as expected.

        This patch adds an 'errorMessage' parameter to the JavaScriptCore method
        used to disable 'eval'; ContentSecurityPolicy has the opportunity to
        pass in a more detailed and descriptive error that contains more context
        for the developer.

        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
            Drop the hard-coded "Eval is disabled" error message in favor of
            reading the error message off the global object.
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::getCallData):
            Drop the hard-coded "Function constructor is disabled" error message
            in favor of reading the error message off the global object.
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::evalEnabled):
            Making this accessor method const.
        (JSC::JSGlobalObject::evalDisabledErrorMessage):
            Accessor for the error message set via 'setEvalDisabled'.
        (JSC::JSGlobalObject::setEvalEnabled):
            Adding an 'errorMessage' parameter which is stored on the global
            object, and used when exceptions are thrown.

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

        bbc homepage crashes immediately
        https://bugs.webkit.org/show_bug.cgi?id=96812
        <rdar://problem/12081386>

        Reviewed by Oliver Hunt.

        If you use the old storage pointer to write to space you thought was newly allocated,
        you're going to have a bad time.

        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCount):

2012-09-14  Adam Barth  <abarth@webkit.org>

        Remove webkitPostMessage
        https://bugs.webkit.org/show_bug.cgi?id=96577

        Reviewed by Ojan Vafai.

        Add ENABLE_LEGACY_VENDOR_PREFIXES flag.

        * Configurations/FeatureDefines.xcconfig:

2012-09-14  Tor Arne Vestbø  <tor.arne.vestbo@nokia.com>

        [Qt] Make force_static_libs_as_shared work on Mac OS

        We had to move a few LIBS += around that were in the wrong place,
        and not caught when everything was just linked into the final
        QtWebKit library.

        Reviewed by Simon Hausmann.

        * jsc.pro: No need for AppKit, we get it from WTF.pri

2012-09-14  Kevin Funk  <kevin.funk@kdab.com>

        Fix interpreter build
        https://bugs.webkit.org/show_bug.cgi?id=96617

        Reviewed by Simon Hausmann.

        Make compile.

        * interpreter/Interpreter.cpp:

2012-09-14  Parth Patel  <parpatel@rim.com>

        [BlackBerry] Switching from Slogger to Slogger2 requires changes in CMakeList of 
        webkit in order to include libraries of slog2
        https://bugs.webkit.org/show_bug.cgi?id=96391

        Reviewed by Yong Li.

        Changes in Cmake files of JavaScriptCore of webkit to include slog2 libs in build 
        files of webkit in response to switching from Slogger to Slogger2.

        * shell/PlatformBlackBerry.cmake:

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

        Remove the Zapped BlockState
        https://bugs.webkit.org/show_bug.cgi?id=96708

        Reviewed by Geoffrey Garen.

        The Zapped block state is rather confusing. It indicates that a block is in one of two different states that we 
        can't tell the difference between:

        1) I have run all destructors of things that are zapped, and I have not allocated any more objects. This block 
           is ready for reclaiming if you so choose.
        2) I have run all the destructors of things that are zapped, but I have allocated more stuff since then, so it 
           is not safe to reclaim this block.

        This state adds a lot of complexity to our state transition model for MarkedBlocks. We should get rid of it. 
        We can replace this state by making sure mark bits represent all of the liveness information we need when running 
        our conservative stack scan. Instead of zapping the free list when canonicalizing cell liveness data prior to 
        a conservative scan, we can instead mark all objects in the block except for those in the free list. This should 
        incur no performance penalty since we're doing it on a very small O(1) number of blocks at the beginning of the collection. 

        For the time being we still need to use zapping to determine whether we have run an object's destructor or not.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): Renaming stuff.
        * heap/MarkedAllocator.h: Renamed zapFreeList to canonicalizeCellLivenessData to match.
        (MarkedAllocator):
        (JSC::MarkedAllocator::canonicalizeCellLivenessData): Same as old zapFreeList, but just call canonicalize instead.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::specializedSweep): Remove the check for Zapped block stuff. Also change the block state to Marked 
        instead of Zapped if we're not producing a FreeList since that's the only other state that really makes any sense.
        (JSC::MarkedBlock::sweepHelper): Remove Zapped related code.
        (SetAllMarksFunctor): Functor to set all the mark bits in the block since there's not a simple function to call on 
        the Bitmap itself.
        (JSC::SetAllMarksFunctor::operator()):
        (JSC):
        (JSC::MarkedBlock::canonicalizeCellLivenessData): Remove all the stuff for Zapped. For FreeListed, set all the mark bits
        and then clear the ones for the objects in the FreeList. This ensures that only the things that were in the FreeList 
        are considered to be dead by the conservative scan, just like if we were to have zapped the FreeList like before. 
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::clearMarked): Add function to clear individual mark bits, since we need that functionality now.
        (JSC):
        (JSC::MarkedBlock::isLive): Remove code for Zapped stuff. Marked handles all interesting cases now.
        (JSC::MarkedBlock::forEachCell): Add new iterator function that iterates over all cells in the block, regardless of 
        whether they're live or a dead.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::canonicalizeCellLivenessData): Change to call the renamed canonicalize function. 

2012-09-13  Kevin Funk  <kevin.funk@kdab.com>

        Make compile with both OS(WINCE) and PLATFORM(QT) support
        https://bugs.webkit.org/show_bug.cgi?id=95536

        Reviewed by Simon Hausmann.

        Do not link against advapi32 on wince

        * jsc.pro:

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

        Refactored the DFG to make fewer assumptions about variable capture
        https://bugs.webkit.org/show_bug.cgi?id=96680

        Reviewed by Gavin Barraclough.

        A variable capture optimization patch I'm working on broke DFG
        correctness and the arguments simplification optimization phase, so I've
        refactored both to make fewer assumptions about variable capture.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isCaptured): This is the new One True Way to find out
        if a variable was captured. This gives us a single point of maintenance
        as we chagne capture behavior.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::clobberCapturedVars): Don't assume that captured
        variables have any particular location. Instead, ask the One True Function.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): Mechanical
        changes to separate being captured from being 'arguments'. What used
        to be
                if (captured)
                        if (arguments)
                                x
                        y
        is now
                if (arguments)
                        x
                        y
                else if (captured)
                        y

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Use the One True Function.

2012-09-13  Benjamin Poulain  <bpoulain@apple.com>

        Improve the SourceProvider hierarchy
        https://bugs.webkit.org/show_bug.cgi?id=95635

        Reviewed by Geoffrey Garen.

        SourceProvider was designed to have subclasses magically handling the data without
        decoding all of it. The virtual methods length() and getRange() were based
        on these assumptions.

        In practice, the magic was in our head, there is no implementation that takes
        advantage of that.

        SourceProvider is modified to adopt WebCore's ScriptSourceProvider::source() and base
        everything on it.
        The code using SourceProvider is also simplified.

        * interpreter/Interpreter.cpp:
        (JSC::appendSourceToError): Keep a reference to the string instead of querying it for
        each time it is used.
        * parser/Lexer.cpp:
        (JSC::::setCode):
        (JSC::::sourceCode):
        * parser/Parser.h:
        (JSC::parse):
        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode):
        (JSC::SourceCode::subExpression):
        * parser/SourceProvider.h:
        (SourceProvider):
        (JSC::SourceProvider::getRange):

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

        DFG: Dead GetButterfly's shouldn't be subject to CSE
        https://bugs.webkit.org/show_bug.cgi?id=96707
        <rdar://problem/12296311>

        Reviewed by Oliver Hunt.
        
        There were a number of cases of this that creeped into the CSE: it would
        match something even though it was dead.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::checkArrayElimination):
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::getScopeChainLoadElimination):
        (JSC::DFG::CSEPhase::getLocalLoadElimination):

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

        Make global const initialisation explicit in the bytecode
        https://bugs.webkit.org/show_bug.cgi?id=96711

        Reviewed by Gavin Barraclough.

        Added op_init_global_const to make initialisation of global const
        fields explicit.  This will help us keep correct semantics in the
        upcoming variable resolution refactoring.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitInitGlobalConst):
        (JSC):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConstDeclNode::emitCodeSingle):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        Rename forEachCell to forEachLiveCell
        https://bugs.webkit.org/show_bug.cgi?id=96685

        Reviewed by Oliver Hunt.

        forEachCell actually only iterates over live cells. We should rename it to 
        reflect what it actually does. This is also helpful because we want to add a new 
        forEachCell that actually does iterate each and every cell in a MarkedBlock 
        regardless of whether or not it is live.

        * debugger/Debugger.cpp:
        (JSC::Debugger::recompileAllJSFunctions):
        * heap/Heap.cpp:
        (JSC::Heap::globalObjectCount):
        (JSC::Heap::objectTypeCounts):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::forEachLiveCell):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::forEachLiveCell):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::releaseExecutableMemory):

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

        [Qt][Win] REGRESSION(r128400): It broke the build
        https://bugs.webkit.org/show_bug.cgi?id=96617

        Reviewed by Simon Hausmann.

        Changed "JSC::Array" to "JSC::ArrayClass" because it's not used often enough
        for the brevity to be beneficial, and because "Array" causes too much namespace
        pollution.

        * runtime/IndexingType.h:
        (JSC):
        * runtime/JSArray.cpp:
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sort):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        (JSC::JSArray::compactForSorting):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::ensureArrayStorage):

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

        Testing whether indexing type is ArrayWithArrayStorage should not compare against ArrayWithArrayStorage
        https://bugs.webkit.org/show_bug.cgi?id=96611

        Reviewed by Gavin Barraclough.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        JSC should have property butterflies
        https://bugs.webkit.org/show_bug.cgi?id=91933

        Reviewed by Geoffrey Garen.

        This changes the JSC object model. Previously, all objects had fast lookup for
        named properties. Integer indexed properties were only fast if you used a
        JSArray. With this change, all objects have fast indexed properties. This is
        accomplished without any space overhead by using a bidirectional object layout,
        aka butterflies. Each JSObject has a m_butterfly pointer where previously it
        had a m_outOfLineStorage pointer. To the left of the location pointed to by
        m_butterfly, we place all named out-of-line properties. To the right, we place
        all indexed properties along with indexing meta-data. Though, some indexing
        meta-data is placed in the 8-byte word immediately left of the pointed-to
        location; this is in anticipation of the indexing meta-data being small enough
        in the common case that m_butterfly always points to the first indexed
        property.
        
        This is performance neutral, except on tests that use indexed properties on
        plain objects, where the speed-up is in excess of an order of magnitude.
        
        One notable aspect of what this change brings is that it allows indexing
        storage to morph over time. Currently this is only used to allow all non-array
        objects to start out without any indexed storage. But it could be used for
        some kinds of array type inference in the future.

        * API/JSCallbackObject.h:
        (JSCallbackObject):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertySlotByIndex):
        (JSC):
        (JSC::::getOwnNonIndexPropertyNames):
        * API/JSObjectRef.cpp:
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::arrayModeFromStructure):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAdjacencyList.h:
        (JSC::DFG::AdjacencyList::AdjacencyList):
        (AdjacencyList):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::modeUsesButterfly):
        (JSC::DFG::modeIsJSArray):
        (JSC::DFG::isInBoundsAccess):
        (JSC::DFG::modeSupportsLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::addNode):
        (FixupPhase):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (Node):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::putByVal):
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryBuildPutByIdList):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * heap/CopiedSpace.h:
        (CopiedSpace):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateBasicStorage):
        (JSC::JIT::emitAllocateJSArray):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emitSlow_op_new_array):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::compileGetDirectOffset):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::compileGetDirectOffset):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/Arguments.cpp:
        (JSC::Arguments::deletePropertyByIndex):
        (JSC::Arguments::defineOwnProperty):
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayConventions.h: Added.
        (JSC):
        (JSC::isDenseEnoughForVector):
        (JSC::indexingHeaderForArray):
        (JSC::baseIndexingHeaderForArray):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::create):
        (JSC):
        (JSC::ArrayPrototype::ArrayPrototype):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncJoin):
        (JSC::arrayProtoFuncSort):
        (JSC::arrayProtoFuncFilter):
        (JSC::arrayProtoFuncMap):
        (JSC::arrayProtoFuncEvery):
        (JSC::arrayProtoFuncForEach):
        (JSC::arrayProtoFuncSome):
        (JSC::arrayProtoFuncReduce):
        (JSC::arrayProtoFuncReduceRight):
        * runtime/ArrayPrototype.h:
        (ArrayPrototype):
        (JSC::ArrayPrototype::createStructure):
        * runtime/ArrayStorage.h: Added.
        (JSC):
        (ArrayStorage):
        (JSC::ArrayStorage::ArrayStorage):
        (JSC::ArrayStorage::from):
        (JSC::ArrayStorage::butterfly):
        (JSC::ArrayStorage::indexingHeader):
        (JSC::ArrayStorage::length):
        (JSC::ArrayStorage::setLength):
        (JSC::ArrayStorage::vectorLength):
        (JSC::ArrayStorage::setVectorLength):
        (JSC::ArrayStorage::copyHeaderFromDuringGC):
        (JSC::ArrayStorage::inSparseMode):
        (JSC::ArrayStorage::lengthOffset):
        (JSC::ArrayStorage::vectorLengthOffset):
        (JSC::ArrayStorage::numValuesInVectorOffset):
        (JSC::ArrayStorage::vectorOffset):
        (JSC::ArrayStorage::indexBiasOffset):
        (JSC::ArrayStorage::sparseMapOffset):
        (JSC::ArrayStorage::sizeFor):
        * runtime/Butterfly.h: Added.
        (JSC):
        (Butterfly):
        (JSC::Butterfly::Butterfly):
        (JSC::Butterfly::totalSize):
        (JSC::Butterfly::fromBase):
        (JSC::Butterfly::offsetOfIndexingHeader):
        (JSC::Butterfly::offsetOfPublicLength):
        (JSC::Butterfly::offsetOfVectorLength):
        (JSC::Butterfly::indexingHeader):
        (JSC::Butterfly::propertyStorage):
        (JSC::Butterfly::indexingPayload):
        (JSC::Butterfly::arrayStorage):
        (JSC::Butterfly::offsetOfPropertyStorage):
        (JSC::Butterfly::indexOfPropertyStorage):
        (JSC::Butterfly::base):
        * runtime/ButterflyInlineMethods.h: Added.
        (JSC):
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::create):
        (JSC::Butterfly::createUninitializedDuringCollection):
        (JSC::Butterfly::base):
        (JSC::Butterfly::growPropertyStorage):
        (JSC::Butterfly::growArrayRight):
        (JSC::Butterfly::resizeArray):
        (JSC::Butterfly::unshift):
        (JSC::Butterfly::shift):
        * runtime/ClassInfo.h:
        (MethodTable):
        (JSC):
        * runtime/IndexingHeader.h: Added.
        (JSC):
        (IndexingHeader):
        (JSC::IndexingHeader::offsetOfIndexingHeader):
        (JSC::IndexingHeader::offsetOfPublicLength):
        (JSC::IndexingHeader::offsetOfVectorLength):
        (JSC::IndexingHeader::IndexingHeader):
        (JSC::IndexingHeader::vectorLength):
        (JSC::IndexingHeader::setVectorLength):
        (JSC::IndexingHeader::publicLength):
        (JSC::IndexingHeader::setPublicLength):
        (JSC::IndexingHeader::from):
        (JSC::IndexingHeader::fromEndOf):
        (JSC::IndexingHeader::propertyStorage):
        (JSC::IndexingHeader::arrayStorage):
        (JSC::IndexingHeader::butterfly):
        * runtime/IndexingHeaderInlineMethods.h: Added.
        (JSC):
        (JSC::IndexingHeader::preCapacity):
        (JSC::IndexingHeader::indexingPayloadSizeInBytes):
        * runtime/IndexingType.h: Added.
        (JSC):
        (JSC::hasIndexingHeader):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::JSActivation):
        (JSC::JSActivation::visitChildren):
        (JSC::JSActivation::getOwnNonIndexPropertyNames):
        * runtime/JSActivation.h:
        (JSActivation):
        (JSC::JSActivation::tearOff):
        * runtime/JSArray.cpp:
        (JSC):
        (JSC::createArrayButterflyInDictionaryIndexingMode):
        (JSC::JSArray::setLengthWritable):
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::getOwnPropertySlot):
        (JSC::JSArray::getOwnPropertyDescriptor):
        (JSC::JSArray::put):
        (JSC::JSArray::deleteProperty):
        (JSC::JSArray::getOwnNonIndexPropertyNames):
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::shiftCount):
        (JSC::JSArray::unshiftCount):
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sort):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSC):
        (JSArray):
        (JSC::JSArray::JSArray):
        (JSC::JSArray::length):
        (JSC::JSArray::createStructure):
        (JSC::JSArray::isLengthWritable):
        (JSC::createArrayButterfly):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized):
        * runtime/JSBoundFunction.cpp:
        (JSC::boundFunctionCall):
        (JSC::boundFunctionConstruct):
        (JSC::JSBoundFunction::finishCreation):
        * runtime/JSCell.cpp:
        (JSC::JSCell::getOwnNonIndexPropertyNames):
        (JSC):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnPropertyDescriptor):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSFunction.h:
        (JSFunction):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC):
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::visitChildren):
        (JSC::JSFinalObject::visitChildren):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::put):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::createInitialArrayStorage):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::getOwnNonIndexPropertyNames):
        (JSC::JSObject::preventExtensions):
        (JSC::JSObject::fillGetterPropertySlot):
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::allocateSparseIndexMap):
        (JSC::JSObject::deallocateSparseIndexMap):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::checkIndexingConsistency):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::putDescriptor):
        (JSC::JSObject::putDirectMayBeIndex):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::defineOwnProperty):
        (JSC::JSObject::getOwnPropertySlotSlow):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength):
        (JSObject):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::putDirectIndex):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::completeInitialization):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::butterfly):
        (JSC::JSObject::outOfLineStorage):
        (JSC::JSObject::offsetForLocation):
        (JSC::JSObject::indexingShouldBeSparse):
        (JSC::JSObject::butterflyOffset):
        (JSC::JSObject::butterflyAddress):
        (JSC::JSObject::arrayStorage):
        (JSC::JSObject::arrayStorageOrZero):
        (JSC::JSObject::ensureArrayStorage):
        (JSC::JSObject::checkIndexingConsistency):
        (JSC::JSNonFinalObject::JSNonFinalObject):
        (JSC):
        (JSC::JSObject::setButterfly):
        (JSC::JSObject::setButterflyWithoutChangingStructure):
        (JSC::JSObject::JSObject):
        (JSC::JSObject::inlineGetOwnPropertySlot):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::putDirectWithoutTransition):
        (JSC::offsetInButterfly):
        (JSC::offsetRelativeToPatchedStorage):
        (JSC::indexRelativeToBase):
        (JSC::offsetRelativeToBase):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::create):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSSymbolTableObject):
        * runtime/JSTypeInfo.h:
        (JSC):
        (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
        (JSC::TypeInfo::overridesGetPropertyNames):
        * runtime/LiteralParser.cpp:
        (JSC::::parse):
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::ObjectPrototype):
        (JSC):
        * runtime/ObjectPrototype.h:
        (ObjectPrototype):
        * runtime/PropertyOffset.h:
        (JSC::offsetInOutOfLineStorage):
        * runtime/PropertyStorage.h: Added.
        (JSC):
        * runtime/PutDirectIndexMode.h: Added.
        (JSC):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::RegExpMatchesArray::RegExpMatchesArray):
        (JSC):
        (JSC::RegExpMatchesArray::create):
        (JSC::RegExpMatchesArray::finishCreation):
        * runtime/RegExpMatchesArray.h:
        (RegExpMatchesArray):
        (JSC::RegExpMatchesArray::createStructure):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::getOwnNonIndexPropertyNames):
        * runtime/RegExpObject.h:
        (RegExpObject):
        * runtime/Reject.h: Added.
        (JSC):
        (JSC::reject):
        * runtime/SparseArrayValueMap.cpp: Added.
        (JSC):
        * runtime/SparseArrayValueMap.h: Added.
        (JSC):
        (SparseArrayEntry):
        (JSC::SparseArrayEntry::SparseArrayEntry):
        (SparseArrayValueMap):
        (JSC::SparseArrayValueMap::sparseMode):
        (JSC::SparseArrayValueMap::setSparseMode):
        (JSC::SparseArrayValueMap::lengthIsReadOnly):
        (JSC::SparseArrayValueMap::setLengthIsReadOnly):
        (JSC::SparseArrayValueMap::find):
        (JSC::SparseArrayValueMap::remove):
        (JSC::SparseArrayValueMap::notFound):
        (JSC::SparseArrayValueMap::isEmpty):
        (JSC::SparseArrayValueMap::contains):
        (JSC::SparseArrayValueMap::size):
        (JSC::SparseArrayValueMap::begin):
        (JSC::SparseArrayValueMap::end):
        * runtime/SparseArrayValueMapInlineMethods.h: Added.
        (JSC):
        (JSC::SparseArrayValueMap::SparseArrayValueMap):
        (JSC::SparseArrayValueMap::~SparseArrayValueMap):
        (JSC::SparseArrayValueMap::finishCreation):
        (JSC::SparseArrayValueMap::create):
        (JSC::SparseArrayValueMap::destroy):
        (JSC::SparseArrayValueMap::createStructure):
        (JSC::SparseArrayValueMap::add):
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayEntry::get):
        (JSC::SparseArrayEntry::getNonSparseMode):
        (JSC::SparseArrayValueMap::visitChildren):
        * runtime/StorageBarrier.h: Removed.
        * runtime/StringObject.cpp:
        (JSC::StringObject::putByIndex):
        (JSC):
        (JSC::StringObject::deletePropertyByIndex):
        * runtime/StringObject.h:
        (StringObject):
        * runtime/StringPrototype.cpp:
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::materializePropertyMap):
        (JSC::Structure::nonPropertyTransition):
        (JSC):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::indexingType):
        (JSC::Structure::indexingTypeIncludingHistory):
        (JSC::Structure::indexingTypeOffset):
        (JSC::Structure::create):
        * runtime/StructureTransitionTable.h:
        (JSC):
        (JSC::toAttributes):
        (JSC::newIndexingType):
        (JSC::StructureTransitionTable::Hash::hash):
        * tests/mozilla/js1_6/Array/regress-304828.js:

2012-09-12  Mark Lam  <mark.lam@apple.com>

        Refactor Opcodes to distinguish between core and extension opcodes.
        https://bugs.webkit.org/show_bug.cgi?id=96466.

        Reviewed by Filip Pizlo.

        * bytecode/Opcode.h:
        (JSC): Added FOR_EACH_CORE_OPCODE_ID() macro.
        * llint/LowLevelInterpreter.h:
        (JSC): Auto-generate llint opcode aliases using the
            FOR_EACH_CORE_OPCODE_ID() macro.

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

        Second step to fixing the Windows build: Add new symbols.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        First step to fixing the Windows build: Remove old symbols.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Don't allocate a backing store just for a function's name
        https://bugs.webkit.org/show_bug.cgi?id=96468

        Reviewed by Oliver Hunt.

        Treat function.name like function.length etc., and use a custom getter.
        This saves space in closures.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::functionName):
        * debugger/DebuggerCallFrame.h:
        (DebuggerCallFrame): Updated for interface change.

        * runtime/Executable.h:
        (JSC::JSFunction::JSFunction): Do a little inlining.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation): Gone now. That's the point of the patch.

        (JSC::JSFunction::name):
        (JSC::JSFunction::displayName):
        (JSC::JSFunction::nameGetter):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::getOwnPropertyDescriptor):
        (JSC::JSFunction::getOwnPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::deleteProperty):
        (JSC::JSFunction::defineOwnProperty): Added custom accessors for .name
        just like .length and others.

        * runtime/JSFunction.h:
        (JSC::JSFunction::create):
        (JSFunction): Updated for interface changes.

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

        IncrementalSweeper should not sweep/free Zapped blocks
        https://bugs.webkit.org/show_bug.cgi?id=96464

        Reviewed by Filip Pizlo.

        This is not beneficial in terms of performance because there isn't any way a block can emerge
        in the Zapped state from a call to Heap::collect() unless we run an eager sweep on it, in which 
        case we've already run all the destructors we possibly can. This also causes bugs since we don't 
        take zapped-ness into account when determining whether or not a block is empty to free it. The 
        incremental sweeper can then accidentally free blocks that it thinks are empty but are in fact 
        zapped with still-live objects in them.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::needsSweeping): It is only valid to sweep a block if it is in the Marked state.

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

        JSActivation should inline allocate its registers, and eliminate
        'arguments' registers in the common case
        https://bugs.webkit.org/show_bug.cgi?id=96427

        Reviewed by Filip Pizlo.

        This cuts the size class for simple closures down to 64 bytes.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Set the usesNonStrictEval
        flag, which is new. Use a more specific test for whether a function
        uses 'arguments', so we can avoid allocating, initializing, and tearing
        off those registers in the common case. Distinguish between capturing
        arguments and not, so we can avoid allocating space for arguments in
        the torn-off object.

        We can make this even more general in the future, with some bytecode
        generator refactoring.

        (JSC::BytecodeGenerator::resolve): Updated for new interface.

        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        (JSC::BytecodeGenerator::symbolTable): Updated some types.

        * heap/Heap.cpp:
        (JSC::Heap::isValidAllocation): Allow large allocations, now that they
        are both supported and used.

        * heap/Heap.h:
        (Heap): Added a new form of allocateCell that specifies the full size
        of the allocation, to allow for extra space on the end.

        * interpreter/CallFrame.h:
        (JSC::ExecState::argumentOffset):
        (JSC::ExecState::argumentOffsetIncludingThis):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame): Refactored this code to be more
        specific about tearing off 'arguments' vs activations. This is something
        I forgot in my last patch, and it is required now that we can have
        acitvations without 'arguments' registers.

        * runtime/Arguments.h:
        (JSC::Arguments::setRegisters): No need for setRegisters anymore because
        the activation object's storage doesn't change.

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::JSActivation): Initialize our storage manually because
        it's not declared to the C++ compiler.

        (JSC::JSActivation::visitChildren): No copyAndAppend because our storage
        is not out-of-line anymore.

        (JSC::JSActivation::symbolTableGet):
        (JSC::JSActivation::symbolTablePut):
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        (JSC::JSActivation::getOwnPropertySlot):
        (JSC::JSActivation::getOwnPropertyDescriptor):
        (JSC::JSActivation::argumentsGetter): Refactored isTornOff() testing to
        avoid using a data member and to avoid hard-coding any offset assumptions.

        * runtime/JSActivation.h:
        (JSC):
        (JSActivation):
        (JSC::JSActivation::create):
        (JSC::JSActivation::isDynamicScope):
        (JSC::JSActivation::captureStart):
        (JSC::JSActivation::storageSize):
        (JSC::JSActivation::storageSizeInBytes):
        (JSC::JSActivation::registerOffset):
        (JSC::JSActivation::tearOff):
        (JSC::JSActivation::isTornOff):
        (JSC::JSActivation::storage):
        (JSC::JSActivation::allocationSize):
        (JSC::JSActivation::isValid): New helper functions for doing the math
        on our inline storage. Note that in the "AllOfTheThings" tear-off case,
        the number of things is not known at compile time, so we store the
        number in the argument count register. We can't just copy the raw contents
        of the register beacuse we need a value that is safe for precise marking,
        and the value in the register file has an invalid tag.

        * runtime/JSCell.h:
        (JSC::allocateCell): New function for allocating with extra storage
        on the end.

        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        (JSC::JSSymbolTableObject::finishCreation):
        * runtime/JSVariableObject.h:
        (JSC::JSVariableObject::JSVariableObject):
        (JSVariableObject): Make it easier for subclasses to use their symbol
        tables during construction, by passing the table as a constructor argument.

        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::usesNonStrictEval):
        (JSC::SharedSymbolTable::setUsesNonStrictEval):
        (SharedSymbolTable):
        (JSC::SharedSymbolTable::captureMode):
        (JSC::SharedSymbolTable::setCaptureMode):
        (JSC::SharedSymbolTable::captureStart):
        (JSC::SharedSymbolTable::setCaptureStart):
        (JSC::SharedSymbolTable::captureEnd):
        (JSC::SharedSymbolTable::setCaptureEnd):
        (JSC::SharedSymbolTable::parameterCountIncludingThis):
        (JSC::SharedSymbolTable::setParameterCountIncludingThis):
        (JSC::SharedSymbolTable::SharedSymbolTable): Added data members to more
        precisely describe what kind of capture is in play, and to avoid having
        data members in the activation. We expect N activations per symbol table,
        so this can be a big savings in heavy closure usage.

2012-09-11  Ryuan Choi  <ryuan.choi@samsung.com>

        Fix build break with LLINT on 32bit machine after r128219
        https://bugs.webkit.org/show_bug.cgi?id=96461

        Unreviewed build fix.

        * llint/LowLevelInterpreter32_64.asm: Fixed typo.

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

        Build fixed for http://trac.webkit.org/changeset/128243

        Rubber stamped by Stephanie Lewis.

        Added missing include file needed by 96422.

        * icu/unicode/unorm2.h: Added.

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

        Build fixed for http://trac.webkit.org/changeset/128243

        Rubber stamped by Stephanie Lewis.

        Added missing include file needed by 96422.

        * icu/unicode/ptypes.h: Added.

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

        Update ICU header files to more recent version
        https://bugs.webkit.org/show_bug.cgi?id=96422

        Reviewed by Geoff Garen.

        Updated ICU header files to 4.6.1.  Modifications made as part of the merge are:
        platform.h - Changed ifndef / define / endif for U_HAVE_UINT8_T, U_HAVE_UINT16_T, U_HAVE_UINT32_T,
            U_HAVE_UINT64_T, U_IS_BIG_ENDIAN and U_ENABLE_TRACING to match the existing platform.h
        putil.h (line 132) - Changes defined(U_WINDOWS) to defined(WIN32) || defined(OS2) to match existing putil.h
        ustring.h (line 945) - Wrapped macro argument cs with { (const UChar *)cs } to match existing ustring.h
        utypes.h (line 545) - Changed defined(U_WINDOWS) to defined(WIN32) to match existing utypes.h

        * icu/unicode/localpointer.h: Added.
        * icu/unicode/parseerr.h:
        * icu/unicode/platform.h:
        * icu/unicode/putil.h:
        * icu/unicode/uchar.h:
        * icu/unicode/ucnv.h:
        * icu/unicode/ucnv_err.h:
        * icu/unicode/ucol.h:
        * icu/unicode/uconfig.h:
        * icu/unicode/uenum.h:
        * icu/unicode/uiter.h:
        * icu/unicode/uloc.h:
        * icu/unicode/umachine.h:
        * icu/unicode/unorm.h:
        * icu/unicode/urename.h:
        * icu/unicode/uscript.h:
        * icu/unicode/uset.h:
        * icu/unicode/ustring.h:
        * icu/unicode/utf.h:
        * icu/unicode/utf16.h:
        * icu/unicode/utf8.h:
        * icu/unicode/utypes.h:
        * icu/unicode/uvernum.h: Added.
        * icu/unicode/uversion.h:

2012-09-11  Matt Lilek  <mrl@apple.com>

        OS X port should compile with newer versions of clang
        https://bugs.webkit.org/show_bug.cgi?id=96434

        m_identIsVarDecl is unused - remove it.

        Reviewed by Anders Carlsson.

        * parser/NodeConstructors.h:
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.h:
        (ForInNode):

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

        LLInt should optimize and profile array length accesses
        https://bugs.webkit.org/show_bug.cgi?id=96417

        Reviewed by Oliver Hunt.

        This fixes the following hole in our array profiling strategy, where the array
        is large (more than 1000 elements):
        
        for (var i = 0; i < array.length; ++i) ...
        
        The peeled use of array.length (in the array prologue) will execute only once
        before DFG optimization kicks in from the loop's OSR point. Since it executed
        only once, it executed in the LLInt. And prior to this patch, the LLInt did
        not profile array.length accesses - so the DFG will assume, based on the lack
        of profiling, that the access is in fact not an access to the JSArray length
        property. That could then impede our ability to hoist the array structure
        check, and may make us pessimistic in other ways as well, since the generic
        GetById used for the array length access will be viewed as a side-effecting
        operation.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::finalizeUnconditionally):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2012-09-11  Raphael Kubo da Costa  <rakuco@webkit.org>

        [EFL] Rewrite the EFL-related Find modules
        https://bugs.webkit.org/show_bug.cgi?id=95237

        Reviewed by Kenneth Rohde Christiansen.

        * CMakeLists.txt: Stop setting the LINK_FLAGS property.
        * PlatformEfl.cmake: Ditto.
        * shell/PlatformEfl.cmake: Ditto.

2012-09-11  Raphael Kubo da Costa  <rakuco@webkit.org>

        [EFL] Unreviewed build fix after r128065.

        * CMakeLists.txt: Link against WTF for FastMalloc symbols, which
        are needed when building with SYSTEM_MALLOC off.

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

        Remove m_classInfo from JSCell
        https://bugs.webkit.org/show_bug.cgi?id=96311

        Reviewed by Oliver Hunt.

        Now that no one is using the ClassInfo in JSCell, we can remove it for the greater good. This is a 1.5% win on v8v7 and 
        a 1.7% win on kraken, and is an overall performance progression.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Had to rearrange the order of when we take things off the free list 
        and when we store the Structure in the object because we would clobber the free list otherwise. This made it not okay for 
        the structure argument and the scratch register to alias one another. Also removed the store of the ClassInfo pointer in the
        object. Yay!
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp: Since it's no longer okay for for the scratch register and structure register to alias 
        one another as stated above, had to add an extra temporary for passing the Structure.
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp: Ditto.
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject): Similar changes to DFG's inline allocation except that it removed the object from 
        the free list first, so no changes were necessary there.
        * llint/LowLevelInterpreter.asm: Change the constants for amount of inline storage to match PropertyOffset.h and remove 
        the store of the ClassInfo pointer during inline allocation.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSCell.h: Remove the m_classInfo field and associated methods.
        (JSCell):
        * runtime/JSObject.h:
        (JSObject):
        * runtime/PropertyOffset.h: Expand the number of inline storage properties to take up the extra space that we're freeing 
        with the removal of the ClassInfo pointer.
        (JSC):
        * runtime/Structure.h:
        (JSC):
        (JSC::JSCell::JSCell):
        (JSC::JSCell::finishCreation):

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

        Added large allocation support to MarkedSpace
        https://bugs.webkit.org/show_bug.cgi?id=96214

        Originally reviewed by Oliver Hunt, then I added a design revision by
        suggested by Phil Pizlo.

        I expanded the imprecise size classes to cover up to 32KB, then added
        an mmap-based allocator for everything bigger. There's a lot of tuning
        we could do in these size classes, but currently they're almost
        completely unused, so I haven't done any tuning.

        Subtle point: the large allocator is a degenerate case of our free list
        logic. Its list only ever contains zero or one items.

        * heap/Heap.h:
        (JSC::Heap::allocateStructure): Pipe in size information.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): Handle the case where we
        find a free item in the sweep list but the item isn't big enough. This
        can happen in the large allocator because it mixes sizes.

        (JSC::MarkedAllocator::tryAllocate):
        (JSC::MarkedAllocator::allocateSlowCase): More piping.

        (JSC::MarkedAllocator::allocateBlock): Handle the oversize case.

        (JSC::MarkedAllocator::addBlock): I moved the call to didAddBlock here
        because it made more sense.

        * heap/MarkedAllocator.h:
        (MarkedAllocator):
        (JSC::MarkedAllocator::allocate):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithoutDestructor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateStructure):
        (JSC::MarkedSpace::forEachBlock):
        * runtime/Structure.h:
        (JSC::Structure): More piping.

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

        Try to fix the Windows (32-bit) build.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_tear_off_arguments):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_tear_off_arguments): Get operands 1 and 2, not 1 and 1. :(

        Also took this opportunity to rename to indicate that these values are
        not destinations anymore.

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

        DFG misses arguments tear-off for function.arguments if 'arguments' is used
        https://bugs.webkit.org/show_bug.cgi?id=96227

        Reviewed by Gavin Barraclough.

        We've decided not to allow function.arguments to alias the local
        'arguments' object, or a local var or function named 'arguments'.
        Aliasing complicates the implementation (cf, this bug) and can produce
        surprising behavior for web programmers.

        Eliminating the aliasing has the side-effect of fixing this bug.

        The compatibilty story: function.arguments is deprecated, was never
        specified, and throws an exception in strict mode, so we expect it to
        disappear over time. Firefox does not alias to 'arguments'; Chrome
        does, but not if you use eval or with; IE does; Safari did.

        * dfg/DFGByteCodeParser.cpp: Noticed a little cleanup while verifying
        this code. Use the CodeBlock method for better encapsulation.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::retrieveArgumentsFromVMCode): Behavior change: don't
        alias.

        * tests/mozilla/js1_4/Functions/function-001.js:
        (TestFunction_4): Updated test expectations for changed behavior.

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

        offlineasm has some impossible to implement, and unused, instructions
        https://bugs.webkit.org/show_bug.cgi?id=96310

        Reviewed by Mark Hahnenberg.

        * offlineasm/armv7.rb:
        * offlineasm/instructions.rb:
        * offlineasm/x86.rb:

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

        Refactored op_tear_off* to support activations that don't allocate space for 'arguments'
        https://bugs.webkit.org/show_bug.cgi?id=96231

        Reviewed by Gavin Barraclough.

        This is a step toward smaller activations.

        As a side-effect, this patch eliminates a load and branch from the hot path
        of activation tear-off by moving it to the cold path of arguments tear-off. Our
        optimizing assumptions are that activations are common and that reifying the
        arguments object is less common.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName): Updated for new opcode lengths.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::addConstantValue): Added support for JSValue()
        in the bytecode, which we use when we have 'arguments' but no activation.

        (JSC::BytecodeGenerator::emitReturn): Always emit tear_off_arguments
        if we've allocated the arguments registers. This allows tear_off_activation
        not to worry about the arguments object anymore.

        Also, pass the activation and arguments values directly to these opcodes
        instead of requiring the opcodes to infer the values through special
        registers. This gives us more flexibility to move or eliminate registers.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGNode.h:
        (Node): Updated for new opcode lengths.

        * dfg/DFGOperations.cpp: Activation tear-off doesn't worry about the
        arguments object anymore. If 'arguments' is in use and reified, it's
        responsible for aliasing back to the activation object in tear_off_arguments.

        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Don't pass the arguments object to
        activation tear-off; do pass the activation object to arguments tear-off.

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

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_tear_off_activation):
        (JSC::JIT::emit_op_tear_off_arguments):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_tear_off_activation):
        (JSC::JIT::emit_op_tear_off_arguments):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm: Same change in a few more execution engines.

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

        [JSC] Use StringBuilder::appendNumber() instead of String::number()
        https://bugs.webkit.org/show_bug.cgi?id=96236

        Reviewed by Benjamin Poulain.

        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):

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

        Combine MarkStack and SlotVisitor into single class
        https://bugs.webkit.org/show_bug.cgi?id=96043

        Reviewed by Geoff Garen.

        Move all of MarkStack into SlotVisitor. The remaining stuff in MarkStack.cpp actually has to do 
        with MarkStack management/allocation. Cleaned up a few of the header files while I was at it.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        * dfg/DFGCommon.h:
        * heap/GCThreadSharedData.cpp:
        * heap/GCThreadSharedData.h:
        (GCThreadSharedData):
        * heap/HeapRootVisitor.h:
        * heap/MarkStack.cpp:
        (JSC):
        * heap/MarkStack.h:
        (JSC):
        (MarkStackSegment):
        (JSC::MarkStackSegment::data):
        (JSC::MarkStackSegment::capacityFromSize):
        (JSC::MarkStackSegment::sizeFromCapacity):
        (MarkStackSegmentAllocator):
        (MarkStackArray):
        * heap/MarkStackInlineMethods.h:
        (JSC::MarkStackArray::postIncTop):
        (JSC):
        (JSC::MarkStackArray::preDecTop):
        (JSC::MarkStackArray::setTopForFullSegment):
        (JSC::MarkStackArray::setTopForEmptySegment):
        (JSC::MarkStackArray::top):
        (JSC::MarkStackArray::validatePrevious):
        (JSC::MarkStackArray::append):
        (JSC::MarkStackArray::canRemoveLast):
        (JSC::MarkStackArray::removeLast):
        (JSC::MarkStackArray::isEmpty):
        (JSC::MarkStackArray::size):
        * heap/SlotVisitor.cpp: Added.
        (JSC):
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::~SlotVisitor):
        (JSC::SlotVisitor::setup):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::append):
        (JSC::visitChildren):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::mergeOpaqueRoots):
        (JSC::SlotVisitor::startCopying):
        (JSC::SlotVisitor::allocateNewSpaceSlow):
        (JSC::SlotVisitor::allocateNewSpaceOrPin):
        (JSC::JSString::tryHashConstLock):
        (JSC::JSString::releaseHashConstLock):
        (JSC::JSString::shouldTryHashConst):
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::copyAndAppend):
        (JSC::SlotVisitor::doneCopying):
        (JSC::SlotVisitor::harvestWeakReferences):
        (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
        (JSC::SlotVisitor::validate):
        * heap/SlotVisitor.h:
        (JSC):
        (SlotVisitor):
        (JSC::SlotVisitor::sharedData):
        (JSC::SlotVisitor::isEmpty):
        (JSC::SlotVisitor::visitCount):
        (JSC::SlotVisitor::resetChildCount):
        (JSC::SlotVisitor::childCount):
        (JSC::SlotVisitor::incrementChildCount):
        (ParallelModeEnabler):
        (JSC::ParallelModeEnabler::ParallelModeEnabler):
        (JSC::ParallelModeEnabler::~ParallelModeEnabler):
        * heap/SlotVisitorInlineMethods.h:
        (JSC::SlotVisitor::append):
        (JSC):
        (JSC::SlotVisitor::appendUnbarrieredPointer):
        (JSC::SlotVisitor::appendUnbarrieredValue):
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::addWeakReferenceHarvester):
        (JSC::SlotVisitor::addUnconditionalFinalizer):
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRoot):
        (JSC::SlotVisitor::opaqueRootCount):
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
        (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable):
        (JSC::SlotVisitor::donate):
        (JSC::SlotVisitor::donateAndDrain):
        * jit/JITWriteBarrier.h:
        (JSC::SlotVisitor::append):
        * jit/JumpReplacementWatchpoint.cpp:
        * runtime/JSCell.h:
        * runtime/Structure.h:
        (JSC::SlotVisitor::internalAppend):
        * runtime/WriteBarrier.h:
        (JSC):
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendValues):
        * yarr/YarrJIT.cpp:

2012-09-10  Hojong Han  <hojong.han@samsung.com>

        [EFL] JIT memory usage is not retrieved
        https://bugs.webkit.org/show_bug.cgi?id=96095

        Reviewed by Geoffrey Garen.

        Fill JITBytes for EFL port.

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

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

        [CMake][EFL] Enable the LLInt
        https://bugs.webkit.org/show_bug.cgi?id=92682

        Reviewed by Csaba Osztrogonác.

        Generate the headers needed by LLint when LLint is enabled.

        * CMakeLists.txt:

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

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing files.

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

        Fixed a few llint C++ interpreter bugs.
        https://bugs.webkit.org/show_bug.cgi?id=96127.

        Reviewed by Geoffrey Garen.

        * llint/LLIntCLoop.h:
            CLoop::execute()'s bootstrapOpcodeId does not need a default
            value. There is no case when this function is called without
            that parameter being specified.
        * llint/LowLevelInterpreter.asm:
            Moved the dispatchAfterCall() call to where it is needed.
            For the C_LOOP back-end, it generates unreachable code. 
        * llint/LowLevelInterpreter.cpp:
            #include <wtf/Assertions.h> because LLIntAssembly.h needs it.
        (JSC):
            Fixed bug in SIGN_BIT32() macro.
            Placate a MSVC warning for t0, and t1 being uninitialized.
        (JSC::CLoop::execute):
            The bootstrapOpcodeId arg should always be specified.
            MSVC doesn't like UNUSED_PARAM() for labels. Switch to using
                the new UNUSED_LABEL() macro.
        * offlineasm/cloop.rb:
        * offlineasm/generate_offset_extractor.rb:
            Resolved a compiler warning found via MSVC.

2012-09-09  Patrick Gansterer  <paroga@webkit.org>

        Add StringBuilder::appendNumber() and use it
        https://bugs.webkit.org/show_bug.cgi?id=96030

        Reviewed by Eric Seidel.

        Also fix a bunch of append() vs. appendLiteral() issues in the surrounding code.

        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * interpreter/Interpreter.h:
        (JSC::StackFrame::toString):

2012-09-09  Patrick Gansterer  <paroga@webkit.org>

        Make the String initialization on the function side of String::number()
        https://bugs.webkit.org/show_bug.cgi?id=95940

        Reviewed by Benjamin Poulain.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Rolled out <http://trac.webkit.org/changeset/127939> because it broke
        fast/js/named-function-expression.html.

            Refactored bytecode generator initialization to support moving captured vars around
            https://bugs.webkit.org/show_bug.cgi?id=96159

            Reviewed by Gavin Barraclough.

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

        LLInt buildfix for case sensitive filesystems
        https://bugs.webkit.org/show_bug.cgi?id=96099

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter.cpp: Fix filenames.

2012-09-07  Benjamin Poulain  <bpoulain@apple.com>

        Rename the ustring() accessor to string()
        https://bugs.webkit.org/show_bug.cgi?id=95919

        Reviewed by Geoffrey Garen.

        Rename ustring() to string() to make the accessor name more logical after
        r127191.

        * API/JSBase.cpp:
        (JSEvaluateScript):
        (JSCheckScriptSyntax):
        * API/JSObjectRef.cpp:
        (JSObjectMakeFunctionWithCallback):
        (JSObjectMakeFunction):
        (JSObjectCopyPropertyNames):
        * API/JSProfilerPrivate.cpp:
        (JSStartProfiling):
        (JSEndProfiling):
        * API/JSValueRef.cpp:
        (JSValueMakeString):
        (JSValueMakeFromJSONString):
        * API/OpaqueJSString.cpp:
        (OpaqueJSString::string):
        * API/OpaqueJSString.h:
        (OpaqueJSString):
        * bytecode/CodeBlock.cpp:
        (JSC::idName):
        (JSC::CodeBlock::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::RegExpNode::emitBytecode):
        (JSC::processClauseList):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jsc.cpp:
        (GlobalObject::addFunction):
        (GlobalObject::addConstructableFunction):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createRegExp):
        * parser/Parser.cpp:
        (JSC::::parsePrimaryExpression):
        * parser/Parser.h:
        (JSC::Scope::declareVariable):
        (JSC::Scope::declareParameter):
        (JSC::Scope::useVariable):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createRegExp):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::paramString):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::addFunctionProperties):
        * runtime/Identifier.h:
        (JSC::Identifier::string):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::calculatedDisplayName):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSONObject.cpp:
        (JSC::PropertyNameForFunctionCall::value):
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSPropertyNameIterator.h:
        (JSC::JSPropertyNameIterator::finishCreation):
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolveBase):
        * runtime/JSString.h:
        (JSC::inlineJSValueNotStringtoString):
        * runtime/LiteralParser.cpp:
        (JSC::::parse):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorKeys):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):

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

        CALLFRAME_OFFSET and EXCEPTION_OFFSET are same in ctiTrampoline on ARM Thumb2
        https://bugs.webkit.org/show_bug.cgi?id=82013

        Reviewed by Geoff Garen.

        Neither of these values need to be stored. At all.

        * jit/JITStubs.cpp:
        (JSC):
        (JSC::ctiTrampoline):
        (JSC::JITThunks::JITThunks):
            - Nothing to see here. Move along.

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

        Unreviewed, rolling out r127938.
        http://trac.webkit.org/changeset/127938
        https://bugs.webkit.org/show_bug.cgi?id=96166

        It broke the build (Requested by smfr on #webkit).

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

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

        Refactored bytecode generator initialization to support moving captured vars around
        https://bugs.webkit.org/show_bug.cgi?id=96159

        Reviewed by Gavin Barraclough.

        This patch separates the stages of allocating registers, declaring identifiers
        in the symbol table, and initializing registers, so you can change
        allocation decisions without breaking the world.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Call a set of helper functions
        instead of inlining all the code, to help clarity.

        (JSC::BytecodeGenerator::allocateCapturedVars):
        (JSC::BytecodeGenerator::allocateUncapturedVars):
        (JSC::BytecodeGenerator::allocateActivationVar):
        (JSC::BytecodeGenerator::allocateArgumentsVars):
        (JSC::BytecodeGenerator::allocateCalleeVarUndeclared):
        (JSC::BytecodeGenerator::declareParameters):
        (JSC::BytecodeGenerator::declareCallee):
        (JSC::BytecodeGenerator::initCalleeVar):
        (JSC::BytecodeGenerator::initArgumentsVars):
        (JSC::BytecodeGenerator::initActivationVar):
        (JSC::BytecodeGenerator::initThisParameter):
        (JSC::BytecodeGenerator::initFunctionDeclarations):
        (JSC::BytecodeGenerator::declareParameter):
        (JSC::BytecodeGenerator::createLazyRegisterIfNecessary):
        (JSC::BytecodeGenerator::createActivationIfNecessary): Factored these
        helper functions out from pre-existing code.

        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::addVar):
        * parser/Nodes.h:
        (JSC::DeclarationStacks::VarDeclaration::VarDeclaration):
        (VarDeclaration):
        (JSC::DeclarationStacks::FunctionDeclaration::FunctionDeclaration):
        (FunctionDeclaration): Declaration stacks get a little more data now,
        to support allocating registers before putting things in the symbol
        table. I'm convinced that we should eventually just expand the symbol
        table to understand these things.

2012-09-07  Mark Lam  <mark.lam@apple.com>

        Fix a llint C++ interpreter bugs.
        https://bugs.webkit.org/show_bug.cgi?id=96127.

        Reviewed by Filip Pizlo.

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

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

        Object.prototype.__define{G,S}etter__ with non-callable second parameter should throw TypeError instead of SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=93873

        Reviewed by Sam Weinig.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
            - throw TypeError instead of SyntaxError
        (JSC::objectProtoFuncDefineSetter):
            - throw TypeError instead of SyntaxError

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

        JSC should have a zombie mode
        https://bugs.webkit.org/show_bug.cgi?id=96047

        Reviewed by Geoffrey Garen.

        To aid clients of JSC while they are debugging memory issues, we should add a zombie 
        mode that scribbles into objects in the MarkedSpace after they are found to be dead 
        to prevent a sort of "use after free" situation. As a first cut we should support a 
        mode that just scribbles on objects prior to their being reused (i.e. while they are 
        "zombies") and a mode in which, in addition to scribbling on zombies, once an object 
        has been marked its mark bit will never be cleared, thus giving us "immortal" zombies.

        These two modes will be enabled through the use of environment variables. For now these 
        will be "JSZombieEnabled" and "JSImmortalZombieEnabled". Setting them to any value will 
        result in the use of the appropriate mode.

        * heap/Heap.cpp:
        (JSC::Heap::collect): Zombifies dead objects at the end of collection if zombie mode is enabled.
        (ZombifyCellFunctor):
        (JSC::ZombifyCellFunctor::ZombifyCellFunctor): Sets marked bits for dead objects if in immortal mode and writes 0xbbadbeef into them.
        (JSC::ZombifyCellFunctor::operator()):
        (JSC):
        (ZombifyBlockFunctor):
        (JSC::ZombifyBlockFunctor::operator()):
        (JSC::Heap::zombifyDeadObjects): Eagerly sweeps so that we don't write garbage into an object before it 
        is finalized/destroyed.
        * heap/Heap.h:
        (Heap):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::forEachDeadCell): Used to iterate over dead cells at the end of collection if zombie mode is enabled.
        (JSC):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h:
        (JSC):

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

        Rolled back in <http://trac.webkit.org/changeset/127698> with a fix for
        fast/dom/HTMLScriptElement/script-reexecution-pretty-diff.html, which
        is to make sure that function declarations don't put their names in scope.

        Reviewed by Gavin Barraclough.

            Named functions should not allocate scope objects for their names
            https://bugs.webkit.org/show_bug.cgi?id=95659

            Reviewed by Oliver Hunt.

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

        16 bit JSRopeString up converts an 8 bit fibers to 16 bits during resolution
        https://bugs.webkit.org/show_bug.cgi?id=95810

        Reviewed by Benjamin Poulain.

        Added 8 bit path that copies the contents of an 8 bit fiber to the 16 bit buffer
        when resolving a 16 bit rope.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRopeSlowCase):

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

        JS test suite puts incorrect limitations on Function.toString()
        https://bugs.webkit.org/show_bug.cgi?id=3975

        Reviewed by Geoff Garen.

        The result of function toString is implementation defined;
        these test cases were looking for specific whitespace formatting
        that matches mozilla's, and for redundant braces to be inserted
        around if/else blocks. Stop that.

        * tests/mozilla/expected.html:
        * tests/mozilla/js1_2/function/tostring-1.js:
        (simplify):
            - reduce whitespace differences
        * tests/mozilla/js1_2/function/tostring-2.js:
        (simplify):
            - reduce whitespace differences
        (TestOr):
        (TestAnd):
            - added braces to match expected output

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

        Performance regressions on 32-bit platforms with revisions 125637 and 126387
        https://bugs.webkit.org/show_bug.cgi?id=95953

        Reviewed by Filip Pizlo.

        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val): Fix the typo.

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

        Rolled out <http://trac.webkit.org/changeset/127698> because it broke
        fast/dom/HTMLScriptElement/script-reexecution-pretty-diff.html

            Named functions should not allocate scope objects for their names
            https://bugs.webkit.org/show_bug.cgi?id=95659

            Reviewed by Oliver Hunt.

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

        Renamed useYarrJIT() option to useRegExpJIT(). Also fixed regression in
        which inadvertantly allows the ASM llint to use the baseline JIT when
        useRegExpJIT() is true.
        https://bugs.webkit.org/show_bug.cgi?id=95918.

        Reviewed by Geoffrey Garen.

        * runtime/JSGlobalData.cpp:
        (JSC::enableAssembler):
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSC::JSGlobalData::canUseJIT):
        (JSC::JSGlobalData::canUseRegExpJIT):
        (JSGlobalData):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h:
        (JSC):

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

        Build fix for Interpreter after r127698.

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

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

        Named functions should not allocate scope objects for their names
        https://bugs.webkit.org/show_bug.cgi?id=95659

        Reviewed by Oliver Hunt.

        In most cases, we can merge a function expression's name into its symbol
        table. This reduces memory footprint per closure from three objects
        (function + activation + name scope) to two (function + activation),
        speeds up closure allocation, and speeds up recursive calls.

        In the case of a named function expression that contains a non-strict
        eval, the rules are so bat-poop crazy that I don't know how to model
        them without an extra object. Since functions now default to not having
        such an object, this case needs to allocate the object on function
        entry.

        Therefore, this patch makes the slow case a bit slower so the fast case
        can be faster and more memory-efficient. (Note that the slow case already
        allocates an activation on entry, and until recently also allocated a
        scope chain node on entry, so adding one allocation on entry shouldn't
        break the bank.)

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Caught a missed initializer. No behavior change.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Put the callee in static scope
        during compilation so it doesn't need to be in dynamic scope at runtime.

        (JSC::BytecodeGenerator::resolveCallee):
        (JSC::BytecodeGenerator::addCallee): Helper functions for either statically
        resolving the callee or adding a dynamic scope that will resolve to it,
        depending on whether you're in the fast path.

        We move the callee into a var location if it's captured because activations
        prefer to have contiguous ranges of captured variables.

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

        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): This is the point of the patch: remove
        one allocation in the case of a named function expression.

        * parser/Parser.cpp:
        (JSC::::Parser):
        * parser/Parser.h:
        (JSC::Scope::declareCallee):
        (Scope):
        (Parser):
        (JSC::parse):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::checkSyntax):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::produceCodeBlockFor):
        (JSC::FunctionExecutable::fromGlobalCode): Pipe the callee's name through
        the parser so we get accurate information on whether the callee was captured.

        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::checkSyntax):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::produceCodeBlockFor):
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::create):
        (FunctionExecutable):
        (JSC::FunctionExecutable::finishCreation): I had to refactor function
        creation to support the following function constructor quirk: the function
        gets a name, but its name is not in lexical scope.

        To simplify this, FunctionExecutable now automatically extracts all the
        data it needs from the parsed node. The special "fromGlobalCode" path
        used by the function constructor creates an anonymous function, and then
        quirkily sets the value used by the .name property to be non-null, even
        though the parsed name is null.

        * runtime/JSNameScope.h:
        (JSC::JSNameScope::create):
        (JSC::JSNameScope::JSNameScope): Added support for explicitly specifying
        your container scope. The compiler uses this for named function expressions.

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

        a = data[a]++; sets the wrong key in data
        https://bugs.webkit.org/show_bug.cgi?id=91270

        Reviewed by Oliver Hunt.

        Postfix inc/dec is unsafely using finalDestination, can trample base/subscript prior to the result being put.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
            - Remove redundant parens.
        (JSC::PostfixNode::emitBracket):
        (JSC::PostfixNode::emitDot):
            - Refactored to use tempDestination instead of finalDestination.
        (JSC::PrefixNode::emitBracket):
        (JSC::PrefixNode::emitDot):
            - Should be using emitPreIncOrDec.

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

        Bug, assignment within subscript of prefix/postfix increment of bracket access
        https://bugs.webkit.org/show_bug.cgi?id=95913

        Reviewed by Oliver Hunt.

        javascript:alert((function(){ var a = { x:1 }; var b = { x:1 }; a[a=b,"x"]++; return a.x; })())

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitBracket):
        (JSC::PrefixNode::emitBracket):
            - Should check for assigments in the subscript when loading the base.
        * parser/Nodes.h:
        (JSC::BracketAccessorNode::subscriptHasAssignments):
        (BracketAccessorNode):
            - Used by emitBracket methods.

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

        Merge prefix/postfix nodes
        https://bugs.webkit.org/show_bug.cgi?id=95898

        Reviewed by Geoff Garen.

        Simplify the AST.
        This will also mean we have access to m_subscriptHasAssignments when generating a prefix/postfix op applied to a bracket access.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
            - was PostfixResolveNode::emitBytecode
        (JSC::PostfixNode::emitBracket):
            - was PostfixBracketNode::emitBytecode
        (JSC::PostfixNode::emitDot):
            - was PostfixDotNode::emitBytecode
        (JSC::PostfixNode::emitBytecode):
            - was PostfixErrorNode::emitBytecode, call resolve/bracket/dot version as appropriate.
        (JSC::PrefixNode::emitResolve):
            - was PrefixResolveNode::emitBytecode
        (JSC::PrefixNode::emitBracket):
            - was PrefixBracketNode::emitBytecode
        (JSC::PrefixNode::emitDot):
            - was PrefixDotNode::emitBytecode
        (JSC::PrefixNode::emitBytecode):
            - was PrefixErrorNode::emitBytecode, call resolve/bracket/dot version as appropriate.
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::makePrefixNode):
            - Just makes a PrefixNode!
        (JSC::ASTBuilder::makePostfixNode):
            - Just makes a PostfixNode!
        * parser/NodeConstructors.h:
        (JSC::PostfixNode::PostfixNode):
            - Added, merge of PostfixResolveNode/PostfixBracketNode/PostfixDotNode/PostfixErrorNode.
        (JSC::PrefixNode::PrefixNode):
            - Added, merge of PrefixResolveNode/PrefixBracketNode/PrefixDotNode/PrefixErrorNode.
        * parser/Nodes.h:
        (PostfixNode):
            - Added, merge of PostfixResolveNode/PostfixBracketNode/PostfixDotNode/PostfixErrorNode.
        (PrefixNode):
            - Added, merge of PrefixResolveNode/PrefixBracketNode/PrefixDotNode/PrefixErrorNode.

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

        Remove use of JSCell::classInfoOffset() from tryCacheGetByID
        https://bugs.webkit.org/show_bug.cgi?id=95860

        Reviewed by Oliver Hunt.

        We should just do the indirection through the Structure instead.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):

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

        Throw exceptions when assigning to const in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=95894

        Reviewed by Oliver Hunt.

        Currently, this never happens; but it will start happening once the
        callee is a local const register. In this patch, there's no change in
        behavior.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): Helper function
        for doing the throwing.
        * bytecompiler/BytecodeGenerator.h:

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixResolveNode::emitBytecode):
        (JSC::PrefixResolveNode::emitBytecode):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode): Call the helper function.

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

        Refactored callee access in the DFG to support it in the general case
        https://bugs.webkit.org/show_bug.cgi?id=95887

        Reviewed by Phil Pizlo and Gavin Barraclough.

        To support named function expressions, the DFG needs to understand the
        callee register being used in arbitrary expressions, and not just
        create_this.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getDirect): 
        (JSC::DFG::ByteCodeParser::getCallee): Remap access to the callee register
        into a GetCallee node. Otherwise, we get confused and think we have a
        negatively indexed argument.

        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): Inlining also
        needs to remap, but to the callee in the inline frame, and not the caller's
        callee.

        (JSC::DFG::ByteCodeParser::parseBlock): Since we support the callee in
        the general case now, there's no need to handle it in a special way for
        create_this.

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

        Remove use of JSCell::classInfoOffset() from virtualForThunkGenerator
        https://bugs.webkit.org/show_bug.cgi?id=95821

        Reviewed by Oliver Hunt.

        We can replace the load of the ClassInfo from the object with a load from the Structure.

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

2012-09-05  Benjamin Poulain  <bpoulain@apple.com>

        Fix the uses of String::operator+=() for Mac
        https://bugs.webkit.org/show_bug.cgi?id=95818

        Reviewed by Dan Bernstein.

        * jsc.cpp:
        (functionJSCStack): Use StringBuilder to create the stack dump, it is faster
        and avoid String::operator+=().

        * parser/Parser.h:
        (JSC::Parser::updateErrorMessageSpecialCase):
        (JSC::Parser::updateErrorMessage):
        (JSC::Parser::updateErrorWithNameAndMessage):
        Use the String operators (and makeString) to concatenate the strings.

2012-09-05  Gabor Rapcsanyi  <rgabor@webkit.org>

        DFG JIT doesn't work properly on ARM hardfp
        https://bugs.webkit.org/show_bug.cgi?id=95684

        Reviewed by Filip Pizlo.

        Add hardfp support to DFG JIT. The patch is created with the
        help of Zoltan Herczeg.

        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArguments):
        * dfg/DFGFPRInfo.h:
        (FPRInfo):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
        (JSC::DFG::SpeculativeJIT::appendCallSetResult):

2012-09-04  Mark Lam  <mark.lam@apple.com>

        Allow the YarrJIT to use the assembler even when useJIT() is false.
        Introduce the useYarrJIT() option.
        https://bugs.webkit.org/show_bug.cgi?id=95809.

        Reviewed by Geoffrey Garen.

        * runtime/JSGlobalData.cpp:
        (JSC::enableAssembler):
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h:
        (JSC):

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

        inc/dec behave incorrectly operating on a resolved const
        https://bugs.webkit.org/show_bug.cgi?id=95815

        Reviewed by Geoff Garen.

        There are two bugs here.

        (1) When the value being incremented is const, and the result is ignored, we assume this cannot be observed, and emit no code.
            However if the value being incremented is not a primitive & has a valueOf conversion, then this should be being called.

        (2) In the case of a pre-increment of a const value where the result is not ignored, we'll move +/-1 to the destination, then
            add the resolved const value being incremented to this. This is problematic if the destination is a local, and the const
            value being incremented has a valueOf conversion that throws - the destination will be modified erroneously. Instead, we
            need to use a temporary location.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixResolveNode::emitBytecode):
        (JSC::PrefixResolveNode::emitBytecode):
            - always at least perform a toNumber conversion, use tempDestination when reducing inc/dec to an add +/-1.

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

        DFG GetByVal for JSArrays shouldn't OSR exit every time that the index is out of bound
        https://bugs.webkit.org/show_bug.cgi?id=95717

        Reviewed by Oliver Hunt.
        
        Rolling back in after fixing the negative index case.

        Make GetByVal for JSArrayOutOfBounds do meaningful things. The profiling was already
        there so we should just use it!

        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * 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-09-04  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r127503.
        http://trac.webkit.org/changeset/127503
        https://bugs.webkit.org/show_bug.cgi?id=95788

        broke some tests (fast/js/dfg-negative-array-index, fast/js
        /dfg-put-by-val-setter-then-get-by-val) (Requested by thorton
        on #webkit).

        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * 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-09-04  Benjamin Poulain  <bpoulain@apple.com>

        Improve JSC use of Strings after the UString->String change
        https://bugs.webkit.org/show_bug.cgi?id=95633

        Reviewed by Geoffrey Garen.

        This patch improve the use of strings in the JSC runtime.

        The initialization of Identifier is left for future patches.

        The improvements are the following:
        -5% faster to raise one of the modified exception.
        -3 times faster to execute Boolean::toString()

        Most of the changes are just about using the new methods
        for string literals.

        With the changes, the binary on x86_64 gets 176 bytes smaller.

        * API/JSCallbackObjectFunctions.h:
        (JSC::::staticFunctionGetter):
        (JSC::::callbackGetter):
        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):
        * API/JSObjectRef.cpp:
        (JSObjectMakeFunctionWithCallback):
        * bytecode/CodeBlock.cpp:
        (JSC::valueToSourceString):
        (JSC::CodeBlock::nameForRegister):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::addStackTraceIfNecessary):
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/ArrayPrototype.cpp:
        (JSC::shift):
        (JSC::unshift):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoFuncReverse):
        * runtime/BooleanPrototype.cpp:
        (JSC::booleanProtoFuncToString): Instead of instanciating new strings, reuse the
        keywords available in SmallStrings. Avoiding the creation of the JSString and StringImpl
        makes the method significantly faster.

        * runtime/DateConversion.cpp:
        (JSC::formatDateTime):
        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):
        (JSC::formateDateInstance):
        (JSC::dateProtoFuncToISOString):
        Change the way we use snprintf() for clarity and performance.

        Instead of allocating one extra byte to put a zero "just in case", we use the size returned
        by snprintf().
        To prevent any overflow from a programming mistake, we explicitely test for overflow and
        return an empty string.

        (JSC::dateProtoFuncToJSON):
        * runtime/Error.cpp:
        (JSC::createNotEnoughArgumentsError):
        (JSC::throwTypeError):
        (JSC::throwSyntaxError):
        * runtime/Error.h:
        (JSC::StrictModeTypeErrorFunction::create):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        (JSC::errorProtoFuncToString):
        Using a null String is correct because (8) uses jsString(), (9) tests for a length of 0.

        * runtime/ExceptionHelpers.cpp:
        (JSC::InterruptedExecutionError::defaultValue):
        (JSC::TerminatedExecutionError::defaultValue):
        (JSC::createStackOverflowError):
        (JSC::createOutOfMemoryError):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
        (JSC::FunctionExecutable::paramString):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionPrototype.h:
        (JSC::FunctionPrototype::create):
        Using a null String for the name is correct because InternalFunction uses jsString()
        to create the name value.

        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        There is no need to create an empty string for a null string, jsString() handle both
        cases as empty JSString.

        * runtime/JSArray.cpp:
        (JSC::reject):
        (JSC::SparseArrayValueMap::put):
        (JSC::JSArray::put):
        (JSC::JSArray::putByIndexBeyondVectorLength):
        (JSC::JSArray::putDirectIndexBeyondVectorLength):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation): Same issue as InternalFunction::finishCreation.

        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGlobalData.cpp:
        (JSC::enableAssembler): Use CFSTR() instead of CFStringCreateWithCString().
        CFStringCreateWithCString() copy the content and may choose to decode the data.
        CFSTR() is much more efficient.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        JSFunction uses jsString() to create the name, we can use null strings instead
        of creating empty strings.

        (JSC::JSGlobalObject::createThrowTypeError): ditto.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):
        (JSC::decode):
        (JSC::globalFuncEval):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::JSONProtoFuncParse):
        (JSC::JSONProtoFuncStringify):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::defaultValue):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSString.cpp:
        Return an empty JSString to avoid the creation of a temporary empty String.

        (JSC::JSRopeString::getIndexSlowCase):
        * runtime/JSString.h:
        (JSC): Remove the versions of jsNontrivialString() taking a char*. All the callers
        have been replaced by calls using ASCIILiteral.

        * runtime/JSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/LiteralParser.cpp:
        (JSC::::Lexer::lex):
        (JSC::::Lexer::lexString):
        (JSC::::Lexer::lexNumber):
        (JSC::::parse):
        * runtime/LiteralParser.h:
        (JSC::LiteralParser::getErrorMessage):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToExponential):
        (JSC::numberProtoFuncToFixed):
        (JSC::numberProtoFuncToPrecision):
        (JSC::numberProtoFuncToString):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorKeys):
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorPreventExtensions):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
        (JSC::objectConstructorIsExtensible):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncToString):
        * runtime/RegExpConstructor.cpp:
        (JSC::constructRegExp):
        * runtime/RegExpObject.cpp:
        (JSC::reject):
        (JSC::regExpObjectSource):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):

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

        DFG GetByVal for JSArrays shouldn't OSR exit every time that the index is out of bound
        https://bugs.webkit.org/show_bug.cgi?id=95717

        Reviewed by Oliver Hunt.

        Make GetByVal for JSArrayOutOfBounds do meaningful things. The profiling was already
        there so we should just use it!

        * bytecode/DFGExitProfile.h:
        (JSC::DFG::exitKindToString):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * 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-09-04  Zoltan Horvath  <zoltan@webkit.org>

        Extend the coverage of the Custom Allocation Framework in WTF and in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=95737

        Reviewed by Eric Seidel.

        Add WTF_MAKE_FAST_ALLOCATED macro to the following class declarations because these are instantiated by operator new.

        * wtf/CryptographicallyRandomNumber.cpp: CryptographicallyRandomNumber is instantiated at wtf/CryptographicallyRandomNumber.cpp:162.

        * heap/MachineStackMarker.cpp:
        (MachineThreads::Thread): Thread is instantiated at heap/MachineStackMarker.cpp:196.
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (FixedVMPoolExecutableAllocator): FixedVMPoolExecutableAllocator is instantiated at jit/ExecutableAllocatorFixedVMPool.cpp:111
        * parser/SourceProviderCache.h:
        (SourceProviderCache): SourceProviderCache is instantiated at parser/SourceProvider.h:49.
        * parser/SourceProviderCacheItem.h:
        (SourceProviderCacheItem): SourceProviderCacheItem is instantiated at parser/Parser.cpp:843.
        * runtime/GCActivityCallback.h:
        (GCActivityCallback): GCActivityCallback is instantiated at runtime/GCActivityCallback.h:96.
        * tools/CodeProfile.h:
        (CodeProfile): CodeProfile is instantiated at JavaScriptCore/tools/CodeProfiling.cpp:140.

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

        Remove uses of ClassInfo from SpeculativeJIT::compileObjectOrOtherLogicalNot
        https://bugs.webkit.org/show_bug.cgi?id=95510

        Reviewed by Oliver Hunt.

        More refactoring to get rid of ClassInfo checks in the DFG.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):

2012-09-03  Patrick Gansterer  <paroga@webkit.org>

        Unreviewed. Build fix for ENABLE(CLASSIC_INTERPRETER) after r127393.

        * interpreter/Interpreter.h:

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

        Fixed failures seen on Linux bots.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h: push_*_scope doesn't have a destination operand anymore.
        Accordingly, update these places in the baseline JIT, which I missed in my last patch.

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

        Refactored scope chain opcodes to support optimization for named function expressions
        https://bugs.webkit.org/show_bug.cgi?id=95658

        Reviewed by Sam Weinig.

        Renamed
            push_scope => push_with_scope
            push_new_scope => push_name_scope
        to clarify the difference between them.

        Changed push_with_scope and push_name_scope not to save the new scope in
        a temporary register, since doing so made optimization harder.

        (The old behavior was a hold-over from when the scope chain wasn't
        a GC object, and wouldn't be marked otherwise. Now, the scope chain is
        marked because it is a GC object pointed to by the call frame.)

        Changed push_name_scope to accept an operand specifying the attributes
        for the named property, instead of assuming DontDelete, because a named
        function expression needs ReadOnly|DontDelete.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::highestUsedRegister): Removed this function,
        which used to be related to preserving saved scope object temporaries,
        because it had no callers.

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

        Rolled back out a piece of <http://trac.webkit.org/changeset/127293>
        because it broke inspector tests on Windows.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

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

        LLInt C loop backend.
        https://bugs.webkit.org/show_bug.cgi?id=91052.

        Reviewed by Filip Pizlo.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::bytecodeOffset):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC):
        * interpreter/Interpreter.h:
        * jit/JITStubs.h:
        (JITStackFrame):
        (JSC):
        * llint/LLIntCLoop.cpp: Added.
        (JSC):
        (LLInt):
        (JSC::LLInt::CLoop::initialize):
        (JSC::LLInt::CLoop::catchRoutineFor):
        (JSC::LLInt::CLoop::hostCodeEntryFor):
        (JSC::LLInt::CLoop::jsCodeEntryWithArityCheckFor):
        (JSC::LLInt::CLoop::jsCodeEntryFor):
        * llint/LLIntCLoop.h: Added.
        (JSC):
        (LLInt):
        (CLoop):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        * llint/LLIntData.h:
        (JSC):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntOpcode.h:
        * llint/LLIntThunks.cpp:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (LLInt):
        (JSC::LLInt::Ints2Double):
        (JSC):
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter.h:
        (JSC):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/asm.rb:
        * offlineasm/backends.rb:
        * offlineasm/cloop.rb: Added.
        * offlineasm/instructions.rb:
        * runtime/Executable.h:
        (ExecutableBase):
        (JSC::ExecutableBase::hostCodeEntryFor):
        (JSC::ExecutableBase::jsCodeEntryFor):
        (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
        (JSC::ExecutableBase::catchRoutineFor):
        (NativeExecutable):
        * runtime/JSValue.h:
        (JSC):
        (LLInt):
        (JSValue):
        * runtime/JSValueInlineMethods.h:
        (JSC):
        (JSC::JSValue::JSValue):
        * runtime/Options.cpp:
        (JSC::Options::initialize):

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

        Rolled back in a piece of <http://trac.webkit.org/changeset/127293>.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

        * runtime/JSActivation.h:
        (JSActivation):

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

        Rolled back in a piece of <http://trac.webkit.org/changeset/127293>.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::JSActivation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::setGlobalThis):
        (JSC):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSScope::globalThis):
        (JSC):
        (JSC::JSGlobalObject::globalThis):
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::JSNameScope):
        * runtime/JSScope.cpp:
        (JSC::JSScope::visitChildren):
        * runtime/JSScope.h:
        (JSScope):
        (JSC::JSScope::JSScope):
        (JSC::JSScope::globalObject):
        (JSC::JSScope::globalData):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        * runtime/JSVariableObject.h:
        (JSC::JSVariableObject::JSVariableObject):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::JSWithScope):
        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::StrictEvalActivation):

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

        Rolled back out a piece of <http://trac.webkit.org/changeset/127293>
        because it broke Window inspector tests.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

        * runtime/JSActivation.h:
        (JSActivation):

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

        Unreviewed, attempt to fix Windows, take two.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Unreviewed, attempt to fix Windows.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        JSArray::putDirectIndex should by default behave like JSObject::putDirect
        https://bugs.webkit.org/show_bug.cgi?id=95630

        Reviewed by Gavin Barraclough.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSArray.cpp:
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::JSArray::defineOwnNumericProperty):
        (JSC::JSArray::putDirectIndexBeyondVectorLength):
        * runtime/JSArray.h:
        (SparseArrayValueMap):
        (JSArray):
        (JSC::JSArray::putDirectIndex):
        * runtime/JSONObject.cpp:
        (JSC::Walker::walk):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::RegExpMatchesArray::reifyAllProperties):
        (JSC::RegExpMatchesArray::reifyMatchProperty):
        * runtime/StringPrototype.cpp:
        (JSC::splitStringByOneCharacterImpl):
        (JSC::stringProtoFuncSplit):

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

        Rolled back in a piece of <http://trac.webkit.org/changeset/127293>.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::JSNameScope):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::JSWithScope):
        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::StrictEvalActivation):

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

        Rolled back in a piece of <http://trac.webkit.org/changeset/127293>.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_resolve_global_dynamic):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::JSActivation):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::nameScopeStructure):

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

        Remove use of ClassInfo in SpeculativeJIT::emitBranch
        https://bugs.webkit.org/show_bug.cgi?id=95623

        Reviewed by Filip Pizlo.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):

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

        Rolled back in a piece of <http://trac.webkit.org/changeset/127293>.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::globalData):
        (JSC):
        * heap/WeakSet.cpp:
        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (WeakSet):
        (JSC::WeakSet::WeakSet):
        (JSC::WeakSet::globalData):
        * runtime/JSGlobalData.h:
        (JSC::WeakSet::heap):
        (JSC):

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

        Refactor LLInt and supporting code in preparation for the C Loop backend.
        https://bugs.webkit.org/show_bug.cgi?id=95531.

        Reviewed by Filip Pizlo.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * jit/JITExceptions.cpp:
        (JSC::genericThrow): Use ExecutableBase::catchRoutineFor() to fetch
            fetch the catch routine for a thrown exception.  This will allow
            us to redefine that for the C loop later, and still keep this
            code readable.
        * llint/LLIntOfflineAsmConfig.h: Moved ASM macros to
            LowLevelInterpreter.cpp which is the only place they are used. This
            will make it more convenient to redefine them for the C loop later.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall): Use ExecutableBase's hostCodeEntry()
            jsCodeEntryFor(), and jsCodeWithArityCheckEntryFor() for computing
            the entry points to functions being called.
        * llint/LLIntSlowPaths.h:
        (SlowPathReturnType):
        (JSC::LLInt::encodeResult):
        (LLInt):
        (JSC::LLInt::decodeResult): Added.  Needed by LLInt C Loop later.
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/asm.rb: Disambiguate between opcodes and other labels.
        * offlineasm/config.rb:
        * runtime/Executable.h:
        (JSC::ExecutableBase::hostCodeEntryFor): Added.
        (ExecutableBase):
        (JSC::ExecutableBase::jsCodeEntryFor): Added.
        (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): Added.
        (JSC::ExecutableBase::catchRoutineFor): Added.
        * runtime/JSValueInlineMethods.h:
        (JSC):

2012-08-31  Tony Chang  <tony@chromium.org>

        Remove ENABLE_CSS3_FLEXBOX compile time flag
        https://bugs.webkit.org/show_bug.cgi?id=95382

        Reviewed by Ojan Vafai.

        Everyone is already enabling this by default and the spec has stablized.

        * Configurations/FeatureDefines.xcconfig:

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

        Not reviewed.

        Rolled out http://trac.webkit.org/changeset/127293 because it broke
        inspector tests on Windows.

            Shrink activation objects by half
            https://bugs.webkit.org/show_bug.cgi?id=95591

            Reviewed by Sam Weinig.

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

        Shrink activation objects by half
        https://bugs.webkit.org/show_bug.cgi?id=95591

        Reviewed by Sam Weinig.

        Removed the global object, global data, and global this pointers from
        JSScope, and changed an int to a bitfield. This gets the JSActivation
        class down to 64 bytes, which in practice cuts it in half by getting it
        out of the 128 byte size class.

        Now, it's one extra indirection to get these pointers. These pointers
        aren't accessed by JIT code, so I thought there would be no cost to the
        extra indirection. However, some C++-heavy SunSpider tests regressed a
        bit in an early version of the patch, which added even more indirection.
        This suggests that calls to exec->globalData() and/or exec->lexicalGlobalObject()
        are common and probably duplicated in lots of places, and could stand
        further optimization in C++.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute): Test against the specific activation
        for our global object, since there's no VM-shared activation structure
        anymore. This is guaranteed to have the same success rate as the old test
        because activation scope is fixed at compile time.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::globalData):
        * heap/WeakSet.cpp:
        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (WeakSet):
        (JSC::WeakSet::WeakSet):
        (JSC::WeakSet::globalData): Store a JSGlobalData* instead of a Heap*
        because JSGlobalData->Heap is just a constant fold in the addressing
        mode, while Heap->JSGlobalData is an extra pointer dereference. (These
        objects should eventually just merge.)

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_resolve_global_dynamic): See DFGAbstractState.cpp.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm: Load the activation structure from
        the code block instead of the global data because the structure is not
        VM-shared anymore. (See DFGAbstractState.cpp.)

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::JSActivation):
        * runtime/JSActivation.h:
        (JSActivation): This is the point of the patch: Remove the data.

        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData): No longer VM-shared. (See DFGAbstractState.cpp.)

        (JSC::WeakSet::heap): (See WeakSet.h.)

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::setGlobalThis):
        (JSC::JSGlobalObject::reset):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::nameScopeStructure):
        (JSC::JSScope::globalThis):
        (JSC::JSGlobalObject::globalThis): Data that used to be in the JSScope
        class goes here now, so it's not duplicated across all activations.

        * runtime/JSNameScope.h:
        (JSC::JSNameScope::JSNameScope):
        * runtime/JSScope.cpp:
        (JSC::JSScope::visitChildren): This is the point of the patch: Remove the data.

        * runtime/JSScope.h:
        (JSScope):
        (JSC::JSScope::JSScope):
        (JSC::JSScope::globalObject):
        (JSC::JSScope::globalData):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        * runtime/JSVariableObject.h:
        (JSC::JSVariableObject::JSVariableObject):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::JSWithScope):
        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::StrictEvalActivation): Simplified now that
        we don't need to pass so much data to JSScope.

2012-08-31  Patrick Gansterer  <paroga@webkit.org>

        Build fix for WinCE after r127191.

        * bytecode/JumpTable.h:

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

        ASSERTION FAILURE in JSC::JSGlobalData::float32ArrayDescriptor when running fast/js/dfg-float64array.html
        https://bugs.webkit.org/show_bug.cgi?id=95398

        Reviewed by Mark Hahnenberg.

        Trying to get the build failure to be a bit more informative.

        * runtime/JSGlobalData.h:
        (JSGlobalData):

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

        Try to fix the Qt build: add some #includes that, for some reason, only the Qt linker requires.

        * runtime/BooleanObject.cpp:
        * runtime/ErrorInstance.cpp:
        * runtime/NameInstance.cpp:

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

        Fix the Qt build: Removed a now-dead variable.

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

2012-08-30  Benjamin Poulain  <bpoulain@apple.com>

        Ambiguous operator[]  after r127191 on some compiler
        https://bugs.webkit.org/show_bug.cgi?id=95509

        Reviewed by Simon Fraser.

        On some compilers, the operator[] conflicts with the Obj-C++ operators. This attempts to solve
        the issue.

        * runtime/JSString.h:
        (JSC::jsSingleCharacterSubstring):
        (JSC::jsString):
        (JSC::jsSubstring8):
        (JSC::jsSubstring):
        (JSC::jsOwnedString):

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

        Try to fix the Qt build: Remove the inline keyword at the declaration
        site. 

        The Qt compiler seems to be confused, complaining about these functions
        not being defined in a translation unit, even though no generated code
        in the unit calls these functions. Maybe removing the keyword at the
        declaration site will change its mind.

        This shouldn't change the inlining decision at all: the definition is
        still inline.

        * interpreter/CallFrame.h:
        (ExecState):

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

        Undo Qt build fix guess, since it breaks other builds.

        * runtime/JSArray.h:

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

        Try to fix the Qt build: add an #include to JSArray.h, since
        it's included by some of the files Qt complains about, and
        some of is functions call the functions Qt complains about.

        * runtime/JSArray.h:

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

        Second step toward fixing the Windows build: Add new symbols.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Try to fix the Qt build: add an #include.

        * bytecode/GetByIdStatus.cpp:

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

        First step toward fixing the Windows build: Remove old symbols.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Use one object instead of two for closures, eliminating ScopeChainNode
        https://bugs.webkit.org/show_bug.cgi?id=95501

        Reviewed by Filip Pizlo.

        This patch removes ScopeChainNode, and moves all the data and related
        functions that used to be in ScopeChainNode into JSScope.

        Most of this patch is mechanical changes to use a JSScope* where we used
        to use a ScopeChainNode*. I've only specifically commented about items
        that were non-mechanical.

        * runtime/Completion.cpp:
        (JSC::evaluate):
        * runtime/Completion.h: Don't require an explicit scope chain argument
        when evaluating code. Clients never wanted anything other than the
        global scope, and other arbitrary scopes probably wouldn't work
        correctly, anyway.

        * runtime/JSScope.cpp:
        * runtime/JSScope.h:
        (JSC::JSScope::JSScope): JSScope now requires the data we used to pass to
        ScopeChainNode, so it can link itself into the scope chain correctly.

        * runtime/JSWithScope.h:
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::JSWithScope): JSWithScope gets an extra constructor
        for specifically supplying your own scope chain. The DOM needs this
        interface for setting up the scope chain for certain event handlers.
        Other clients always just push the JSWithScope to the head of the current
        scope chain.

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

        Render unto #ifdef's that which belong to them.
        https://bugs.webkit.org/show_bug.cgi?id=95482.

        Reviewed by Filip Pizlo.

        Refining / disambiguating between #ifdefs and adding some. For
        example, ENABLE(JIT) is conflated with ENABLE(LLINT) in some places.
        Also, we need to add ENABLE(COMPUTED_GOTO_OPCODES) to indicate that we
        want interpreted opcodes to use COMPUTED GOTOs apart from ENABLE(LLINT)
        and ENABLE(COMPUTED_GOTO_CLASSIC_INTERPRETER). Also cleaned up #ifdefs
        in certain places which were previously incorrect.

        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::bytecodeOffset):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * config.h:
        * dfg/DFGOperations.cpp:
        * interpreter/AbstractPC.cpp:
        (JSC::AbstractPC::AbstractPC):
        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::~Interpreter):
        (JSC::Interpreter::initialize):
        (JSC::Interpreter::isOpcode):
        (JSC::Interpreter::unwindCallFrame):
        (JSC::getLineNumberForCallFrame):
        (JSC::getCallerInfo):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::privateExecute):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::getOpcode):
        (JSC::Interpreter::getOpcodeID):
        (Interpreter):
        * jit/HostCallReturnValue.h:
        * jit/JITCode.h:
        (JITCode):
        * jit/JITExceptions.cpp:
        * jit/JITExceptions.h:
        * jit/JSInterfaceJIT.h:
        * llint/LLIntData.h:
        (JSC::LLInt::getOpcode):
        * llint/LLIntEntrypoints.cpp:
        (JSC::LLInt::getFunctionEntrypoint):
        (JSC::LLInt::getEvalEntrypoint):
        (JSC::LLInt::getProgramEntrypoint):
        * llint/LLIntOffsetsExtractor.cpp:
        (JSC::LLIntOffsetsExtractor::dummy):
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        * runtime/JSGlobalData.cpp:
        (JSC):

2012-08-30  JungJik Lee  <jungjik.lee@samsung.com>

        [EFL][WK2] Add WebMemorySampler feature.
        https://bugs.webkit.org/show_bug.cgi?id=91214

        Reviewed by Kenneth Rohde Christiansen.

        WebMemorySampler collects Javascript stack and JIT memory usage in globalMemoryStatistics.

        * PlatformEfl.cmake:

2012-08-30  Benjamin Poulain  <bpoulain@apple.com>

        Replace JSC::UString by WTF::String
        https://bugs.webkit.org/show_bug.cgi?id=95271

        Reviewed by Geoffrey Garen.

        Having JSC::UString and WTF::String increase the complexity of working on WebKit, and
        add useless conversions in the bindings. It also cause some code bloat.

        The performance advantages of UString have been ported over in previous patches. This patch
        is the last step: getting rid of UString.

        In addition to the simplified code, this also reduce the binary size by 15kb on x86_64.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::ustring):
        * runtime/Identifier.h:
        (JSC::Identifier::ustring):
        To avoid changing everything at once, the function named ustring() were kept as is. They
        will be renamed in a follow up patch.

        * runtime/JSString.h:
        (JSC::JSString::string):
        (JSC::JSValue::toWTFString):
        (JSC::inlineJSValueNotStringtoString):
        (JSC::JSValue::toWTFStringInline):
        Since JSValue::toString() already exist (and return the JSString), the direct accessor is renamed
        to ::toWTFString(). We may change ::string() to ::jsString() and ::toWTFString() to ::toString()
        in the future.

        * runtime/StringPrototype.cpp:
        (JSC::substituteBackreferencesSlow): Replace the use of UString::getCharacters<>() by String::getCharactersWithUpconvert<>().

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

        Remove uses of ClassInfo in StrictEq and CompareEq in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=93401

        Reviewed by Filip Pizlo.

        Another incremental step in removing the dependence on ClassInfo pointers in object headers.

        * bytecode/SpeculatedType.h:
        (JSC::isCellOrOtherSpeculation):
        (JSC):
        * dfg/DFGAbstractState.cpp: Updated the CFA to reflect the changes to the backend.
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGNode.h:
        (Node):
        (JSC::DFG::Node::shouldSpeculateString): Added this new function since it was conspicuously absent.
        (JSC::DFG::Node::shouldSpeculateNonStringCellOrOther): Also add this function for use in the CFA.
        * dfg/DFGSpeculativeJIT.cpp: Refactored how we handle CompareEq and CompareStrictEq in the DFG. We now just 
        check for Strings by comparing the object's Structure to the global Structure for strings. We only 
        check for MasqueradesAsUndefined if the watchpoint has fired. These changes allow us to remove our 
        uses of the ClassInfo pointer for compiling these nodes.
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp: Same changes for 32 bit as for 64 bit.
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):

2012-08-30  Yong Li  <yoli@rim.com>

        [BlackBerry] Implement IncrementalSweeper for PLATFORM(BLACKBERRY)
        https://bugs.webkit.org/show_bug.cgi?id=95469

        Reviewed by Rob Buis.

        RIM PR# 200595.
        Share most code with USE(CF) and implement timer-related methods
        for PLATFORM(BLACKBERRY).

        * heap/IncrementalSweeper.cpp:
        (JSC):
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::create):
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::cancelTimer):
        (JSC::IncrementalSweeper::doSweep):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):

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

        Fix broken classic intrpreter build.
        https://bugs.webkit.org/show_bug.cgi?id=95484.

        Reviewed by Filip Pizlo.

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

2012-08-30  Byungwoo Lee  <bw80.lee@samsung.com>

        Build warning : -Wsign-compare on DFGByteCodeParser.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=95418

        Reviewed by Filip Pizlo.

        There is a build warning '-Wsign-compare' on
        findArgumentPositionForLocal() in DFGByteCodeParser.cpp.

        For removing this warning, casting statement is added explicitly.

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

2012-08-30  Yong Li  <yoli@rim.com>

        [BlackBerry] Set timer client on platform timer used in HeapTimer
        https://bugs.webkit.org/show_bug.cgi?id=95464

        Reviewed by Rob Buis.

        Otherwise the timer won't work.

        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::HeapTimer):

2012-08-30  Julien BRIANCEAU   <jbrianceau@nds.com>

        [sh4] Add missing implementation for JavaScriptCore JIT
        https://bugs.webkit.org/show_bug.cgi?id=95452

        Reviewed by Oliver Hunt.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::isCompactPtrAlignedAddressOffset):
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::add32):
        (JSC::MacroAssemblerSH4::convertibleLoadPtr):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::labelIgnoringWatchpoints):
        (SH4Assembler):
        (JSC::SH4Assembler::replaceWithLoad):
        (JSC::SH4Assembler::replaceWithAddressComputation):

2012-08-30  Charles Wei  <charles.wei@torchmobile.com.cn>

        [BlackBerry] Eliminate build warnings
        https://bugs.webkit.org/show_bug.cgi?id=95338

        Reviewed by Filip Pizlo.

        static_cast to the same type to eliminate the build time warnings.

        * assembler/AssemblerBufferWithConstantPool.h:
        (JSC::AssemblerBufferWithConstantPool::flushWithoutBarrier):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branch32):

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

        Remove use of ClassInfo from compileGetByValOnArguments and compileGetArgumentsLength
        https://bugs.webkit.org/show_bug.cgi?id=95131

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): We don't need this speculation check. We can replace it 
        with an assert to guarantee this.

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

        Refactoring LLInt::Data.
        https://bugs.webkit.org/show_bug.cgi?id=95316.

        Reviewed by Geoff Garen.

        This change allows its opcodeMap to be easily queried from any function
        without needing to go through a GlobalData object.  It also introduces
        the LLInt::getCodePtr() methods that will be used by the LLInt C loop
        later to redefine how llint symbols (opcodes and trampoline glue
        labels) get resolved.

        * assembler/MacroAssemblerCodeRef.h:
        (MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createLLIntCodePtr):
        (MacroAssemblerCodeRef):
        (JSC::MacroAssemblerCodeRef::createLLIntCodeRef):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::adjustPCIfAtCallSite):
        (JSC::CodeBlock::bytecodeOffset):
        * bytecode/Opcode.h:
            Remove the 'const' to simplify things and avoid having to do
            additional casts and #ifdefs in many places.
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForLLInt):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::initialize):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jit/JITExceptions.cpp:
        (JSC::genericThrow):
        * llint/LLIntData.cpp:
        (LLInt):
        (JSC::LLInt::initialize):
        * llint/LLIntData.h:
        (JSC):
        (LLInt):
        (Data):
        (JSC::LLInt::exceptionInstructions):
        (JSC::LLInt::opcodeMap):
        (JSC::LLInt::getOpcode):
        (JSC::LLInt::getCodePtr):
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::returnToThrowForThrownException):
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::handleHostCall):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce): Initialize the singleton LLInt data.
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData): Removed the now unneeded LLInt::Data instance in
            JSGlobalData.
        * runtime/JSValue.h:
        (JSValue):

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

        PutById uses DataLabel32, not DataLabelCompact
        https://bugs.webkit.org/show_bug.cgi?id=95245

        Reviewed by Geoff Garen.

        JIT::resetPatchPutById calls the the wrong thing on x86-64 – this is moot right now,
        since they currently both do the same thing, but if we were to ever make compact mean
        8-bit this could be a real problem. Also, relying on the object still being in eax
        on entry to the transition stub isn't very robust - added nonArgGPR1 to at least make
        this explicit.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_id):
            - copy regT0 to nonArgGPR1
        (JSC::JIT::privateCompilePutByIdTransition):
            - DataLabelCompact -> DataLabel32
        (JSC::JIT::resetPatchPutById):
            - reload regT0 from nonArgGPR1
        * jit/JSInterfaceJIT.h:
        (JSInterfaceJIT):
            - added nonArgGPR1

2012-08-28  Yong Li  <yoli@rim.com>

        ExecutableAllocator should be destructed after Heap
        https://bugs.webkit.org/show_bug.cgi?id=95244

        Reviewed by Rob Buis.

        RIM PR# 199364.
        Make ExecutableAllocator the first member in JSGlobalData.
        Existing Web Worker tests can show the issue.

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

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

        Try to fix the Windows build.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Export!

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

        Introduced JSWithScope, making all scope objects subclasses of JSScope
        https://bugs.webkit.org/show_bug.cgi?id=95295

        Reviewed by Filip Pizlo.

        This is a step toward removing ScopeChainNode. With a uniform representation
        for objects in the scope chain, we can move data from ScopeChainNode
        into JSScope.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri: Build!

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Use an explicit JSWithScope object
        for 'with' statements. Since 'with' can put any object in the scope
        chain, we'll need an adapter object to hold the data ScopeChainNode
        currently holds.

        (JSGlobalData): Support for JSWithScope.

        * runtime/JSScope.cpp:
        (JSC::JSScope::objectAtScope):
        * runtime/JSScope.h: Check for and unwrap JSWithScope.

        * runtime/JSType.h: Support for JSWithScope.

        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::StrictEvalActivation):
        * runtime/StrictEvalActivation.h:
        (StrictEvalActivation): Inherit from JSScope, to make the scope chain uniform.

        * runtime/JSWithScope.cpp: Added.
        (JSC::JSWithScope::visitChildren):
        * runtime/JSWithScope.h: Added.
        (JSWithScope):
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::object):
        (JSC::JSWithScope::createStructure):
        (JSC::JSWithScope::JSWithScope): New adapter object. Since this object
        is never exposed to scripts, it doesn't need any meaningful implementation
        of property access or other callbacks.

2012-08-29  Patrick Gansterer  <paroga@webkit.org>

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

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

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

        Added JSScope::objectInScope(), and refactored callers to use it
        https://bugs.webkit.org/show_bug.cgi?id=95281

        Reviewed by Gavin Barraclough.

        This is a step toward removing ScopeChainNode. We need a layer of
        indirection so that 'with' scopes can proxy for an object.
        JSScope::objectInScope() will be that layer.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl): . vs ->

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::execute):
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveSkip):
        (JSC::JSScope::resolveGlobalDynamic):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis): Added JSScope::objectAtScope() calls.

        * runtime/JSScope.h:
        (JSScope):
        (JSC::JSScope::objectAtScope):
        (JSC):
        (ScopeChainIterator):
        (JSC::ScopeChainIterator::ScopeChainIterator):
        (JSC::ScopeChainIterator::get):
        (JSC::ScopeChainIterator::operator->):
        (JSC::ScopeChainIterator::operator++):
        (JSC::ScopeChainIterator::operator==):
        (JSC::ScopeChainIterator::operator!=):
        (JSC::ScopeChainNode::begin):
        (JSC::ScopeChainNode::end): I moved ScopeChainIterator to this file
        to resolve a circular #include problem. Eventually, I'll probably rename
        it to JSScope::iterator, so I think it belongs here.

        * runtime/ScopeChain.cpp:
        (JSC::ScopeChainNode::print):
        (JSC::ScopeChainNode::localDepth): . vs ->

        * runtime/ScopeChain.h:
        (ScopeChainNode): I made the 'object' data member private because it's
        no longer safe to access -- you need to call JSScope::objectAtScope()
        instead.

        The JITs need to be friends because of the private declaration.

        Subtly, JIT/LLInt code is correct without any changes because JIT/LLInt
        code never compiles direct access to a with scope.

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

        Adding support for adding LLInt opcode extensions.  This will be needed
        by the LLInt C loop interpreter later.
        https://bugs.webkit.org/show_bug.cgi?id=95277.

        Reviewed by Geoffrey Garen.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Opcode.h:
        * llint/LLIntOpcode.h: Added.
        * llint/LowLevelInterpreter.h:

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

        Rolled out r126928, this broke stuff :'-(

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::resetPatchPutById):

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

        PutById uses DataLabel32, not DataLabelCompact
        https://bugs.webkit.org/show_bug.cgi?id=95245

        Reviewed by Geoff Garen.

        JIT::resetPatchPutById calls the the wrong thing on x86-64 – this is moot right now,
        since they currently both do the same thing, but if we were to ever make compact mean
        8-bit this could be a real problem. Also, don't rely on the object still being in eax
        on entry to the transition stub – this isn't very robust.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
            - DataLabelCompact -> DataLabel32
        (JSC::JIT::resetPatchPutById):
            - reload regT0 from the stack

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

        Unreviewed, rolling out r126914.
        http://trac.webkit.org/changeset/126914
        https://bugs.webkit.org/show_bug.cgi?id=95239

        it breaks everything and fixes nothing (Requested by pizlo on
        #webkit).

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertyNames):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::~OpaqueJSClass):
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        (OpaqueJSClass::contextData):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::EvalCodeCache::visitAggregate):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/JumpTable.h:
        (JSC::StringJumpTable::offsetForValue):
        (JSC::StringJumpTable::ctiForValue):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::LazyOperandValueProfileParser::getIfPresent):
        * bytecode/SamplingTool.cpp:
        (JSC::SamplingTool::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::addConstant):
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        (JSC::BytecodeGenerator::emitLazyNewFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * debugger/Debugger.cpp:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        * dfg/DFGByteCodeCache.h:
        (JSC::DFG::ByteCodeCache::~ByteCodeCache):
        (JSC::DFG::ByteCodeCache::get):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstant):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::StructureCheckHoistingPhase::noticeClobber):
        * heap/Heap.cpp:
        (JSC::Heap::markProtectedObjects):
        * heap/Heap.h:
        (JSC::Heap::forEachProtectedCell):
        * heap/JITStubRoutineSet.cpp:
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        * heap/MarkStack.cpp:
        (JSC::MarkStack::internalAppend):
        * heap/Weak.h:
        (JSC::weakRemove):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::ctiStub):
        * parser/Parser.cpp:
        (JSC::::parseStrictObjectLiteral):
        * profiler/Profile.cpp:
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintDataSampleStyle):
        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSArray.cpp:
        (JSC::SparseArrayValueMap::put):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayValueMap::visitChildren):
        (JSC::JSArray::enterDictionaryMode):
        (JSC::JSArray::defineOwnNumericProperty):
        (JSC::JSArray::getOwnPropertySlotByIndex):
        (JSC::JSArray::getOwnPropertyDescriptor):
        (JSC::JSArray::putByIndexBeyondVectorLength):
        (JSC::JSArray::putDirectIndexBeyondVectorLength):
        (JSC::JSArray::deletePropertyByIndex):
        (JSC::JSArray::getOwnPropertyNames):
        (JSC::JSArray::setLength):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        (JSC::JSArray::checkConsistency):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::invalidateCode):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::clear):
        (JSC::WeakGCMap::set):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::sampleChild):
        (JSC::ProfileTreeNode::childCount):
        (JSC::ProfileTreeNode::dumpInternal):
        (JSC::ProfileTreeNode::compareEntries):

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

        LLInt should not rely on ordering of global labels
        https://bugs.webkit.org/show_bug.cgi?id=95221

        Reviewed by Oliver Hunt.

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

2012-08-28  Caio Marcelo de Oliveira Filho  <caio.oliveira@openbossa.org>

        Rename first/second to key/value in HashMap iterators
        https://bugs.webkit.org/show_bug.cgi?id=82784

        Reviewed by Eric Seidel.

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertyNames):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::~OpaqueJSClass):
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        (OpaqueJSClass::contextData):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::EvalCodeCache::visitAggregate):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/JumpTable.h:
        (JSC::StringJumpTable::offsetForValue):
        (JSC::StringJumpTable::ctiForValue):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::LazyOperandValueProfileParser::getIfPresent):
        * bytecode/SamplingTool.cpp:
        (JSC::SamplingTool::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::addConstant):
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        (JSC::BytecodeGenerator::emitLazyNewFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * debugger/Debugger.cpp:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        * dfg/DFGByteCodeCache.h:
        (JSC::DFG::ByteCodeCache::~ByteCodeCache):
        (JSC::DFG::ByteCodeCache::get):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstant):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::StructureCheckHoistingPhase::noticeClobber):
        * heap/Heap.cpp:
        (JSC::Heap::markProtectedObjects):
        * heap/Heap.h:
        (JSC::Heap::forEachProtectedCell):
        * heap/JITStubRoutineSet.cpp:
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        * heap/MarkStack.cpp:
        (JSC::MarkStack::internalAppend):
        * heap/Weak.h:
        (JSC::weakRemove):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::ctiStub):
        * parser/Parser.cpp:
        (JSC::::parseStrictObjectLiteral):
        * profiler/Profile.cpp:
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintDataSampleStyle):
        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSArray.cpp:
        (JSC::SparseArrayValueMap::put):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayValueMap::visitChildren):
        (JSC::JSArray::enterDictionaryMode):
        (JSC::JSArray::defineOwnNumericProperty):
        (JSC::JSArray::getOwnPropertySlotByIndex):
        (JSC::JSArray::getOwnPropertyDescriptor):
        (JSC::JSArray::putByIndexBeyondVectorLength):
        (JSC::JSArray::putDirectIndexBeyondVectorLength):
        (JSC::JSArray::deletePropertyByIndex):
        (JSC::JSArray::getOwnPropertyNames):
        (JSC::JSArray::setLength):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        (JSC::JSArray::checkConsistency):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::invalidateCode):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::clear):
        (JSC::WeakGCMap::set):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::sampleChild):
        (JSC::ProfileTreeNode::childCount):
        (JSC::ProfileTreeNode::dumpInternal):
        (JSC::ProfileTreeNode::compareEntries):

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

        GCC warning in JSActivation is causing Mac EWS errors
        https://bugs.webkit.org/show_bug.cgi?id=95103

        Reviewed by Sam Weinig.

        Try to fix a strict aliasing violation by using bitwise_cast. The
        union in the cast should signal to the compiler that aliasing between
        types is happening.

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::visitChildren):

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

        Build fix: svn add two files I forgot in my last patch.

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

        Refactored and consolidated variable resolution functions
        https://bugs.webkit.org/show_bug.cgi?id=95166

        Reviewed by Filip Pizlo.

        This patch does a few things:

        (1) Introduces a new class, JSScope, which is the base class for all
        objects that represent a scope in the scope chain.

        (2) Refactors and consolidates duplicate implementations of variable
        resolution into the JSScope class.

        (3) Renames JSStaticScopeObject to JSNameScope because, as distinct from
        something like a 'let' scope, JSStaticScopeObject only has storage for a
        single name.

        These changes makes logical sense to me as-is. I will also use them in an
        upcoming optimization.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri: Build!

        * bytecode/CodeBlock.cpp:
        (JSC): Build fix for LLInt-only builds.

        * bytecode/GlobalResolveInfo.h:
        (GlobalResolveInfo): Use PropertyOffset to be consistent with other parts
        of the engine.

        * bytecompiler/NodesCodegen.cpp:
        * dfg/DFGOperations.cpp: Use the shared code in JSScope instead of rolling
        our own.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::createExceptionScope):
        (JSC::Interpreter::privateExecute):
        * interpreter/Interpreter.h: Use the shared code in JSScope instead of rolling
        our own.

        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION): Use the shared code in JSScope instead of rolling
        our own.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (LLInt): Use the shared code in JSScope instead of rolling our own. Note
        that one of these slow paths calls the wrong helper function. I left it
        that way to avoid a behavior change in a refactoring patch.

        * parser/Nodes.cpp: Updated for rename.

        * runtime/CommonSlowPaths.h:
        (CommonSlowPaths): Removed resolve slow paths because were duplicative.

        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData): Updated for renames.

        * runtime/JSNameScope.cpp: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.cpp.
        (JSC):
        (JSC::JSNameScope::visitChildren):
        (JSC::JSNameScope::toThisObject):
        (JSC::JSNameScope::put):
        (JSC::JSNameScope::getOwnPropertySlot):
        * runtime/JSNameScope.h: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.h.
        (JSC):
        (JSC::JSNameScope::create):
        (JSC::JSNameScope::createStructure):
        (JSNameScope):
        (JSC::JSNameScope::JSNameScope):
        (JSC::JSNameScope::isDynamicScope): Used do-webcore-rename script here.
        It is fabulous!

        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::isNameScopeObject): More rename.

        * runtime/JSScope.cpp: Added.
        (JSC):
        (JSC::JSScope::isDynamicScope):
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveSkip):
        (JSC::JSScope::resolveGlobal):
        (JSC::JSScope::resolveGlobalDynamic):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis):
        * runtime/JSScope.h: Added.
        (JSC):
        (JSScope):
        (JSC::JSScope::JSScope): All the code here is a port from the
        Interpreter.cpp implementations of this functionality.

        * runtime/JSStaticScopeObject.cpp: Removed.
        * runtime/JSStaticScopeObject.h: Removed.

        * runtime/JSSymbolTableObject.cpp:
        (JSC):
        * runtime/JSSymbolTableObject.h:
        (JSSymbolTableObject):
        * runtime/JSType.h: Updated for rename.

        * runtime/Operations.h:
        (JSC::resolveBase): Removed because it was duplicative.

2012-08-28  Alban Browaeys <prahal@yahoo.com>

        [GTK] LLint build fails with -g -02
        https://bugs.webkit.org/show_bug.cgi?id=90098

        Reviewed by Filip Pizlo.

        Avoid duplicate offsets for llint, discarding them.

        * offlineasm/offsets.rb:

2012-08-27  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r126836.
        http://trac.webkit.org/changeset/126836
        https://bugs.webkit.org/show_bug.cgi?id=95163

        Broke all Apple ports, EFL, and Qt. (Requested by tkent on
        #webkit).

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertyNames):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::~OpaqueJSClass):
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        (OpaqueJSClass::contextData):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::EvalCodeCache::visitAggregate):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/JumpTable.h:
        (JSC::StringJumpTable::offsetForValue):
        (JSC::StringJumpTable::ctiForValue):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::LazyOperandValueProfileParser::getIfPresent):
        * bytecode/SamplingTool.cpp:
        (JSC::SamplingTool::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::addConstant):
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        (JSC::BytecodeGenerator::emitLazyNewFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * debugger/Debugger.cpp:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        * dfg/DFGByteCodeCache.h:
        (JSC::DFG::ByteCodeCache::~ByteCodeCache):
        (JSC::DFG::ByteCodeCache::get):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstant):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::StructureCheckHoistingPhase::noticeClobber):
        * heap/Heap.cpp:
        (JSC::Heap::markProtectedObjects):
        * heap/Heap.h:
        (JSC::Heap::forEachProtectedCell):
        * heap/JITStubRoutineSet.cpp:
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        * heap/MarkStack.cpp:
        (JSC::MarkStack::internalAppend):
        * heap/Weak.h:
        (JSC::weakRemove):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::ctiStub):
        * parser/Parser.cpp:
        (JSC::::parseStrictObjectLiteral):
        * profiler/Profile.cpp:
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintDataSampleStyle):
        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSArray.cpp:
        (JSC::SparseArrayValueMap::put):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayValueMap::visitChildren):
        (JSC::JSArray::enterDictionaryMode):
        (JSC::JSArray::defineOwnNumericProperty):
        (JSC::JSArray::getOwnPropertySlotByIndex):
        (JSC::JSArray::getOwnPropertyDescriptor):
        (JSC::JSArray::putByIndexBeyondVectorLength):
        (JSC::JSArray::putDirectIndexBeyondVectorLength):
        (JSC::JSArray::deletePropertyByIndex):
        (JSC::JSArray::getOwnPropertyNames):
        (JSC::JSArray::setLength):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        (JSC::JSArray::checkConsistency):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::invalidateCode):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::clear):
        (JSC::WeakGCMap::set):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::sampleChild):
        (JSC::ProfileTreeNode::childCount):
        (JSC::ProfileTreeNode::dumpInternal):
        (JSC::ProfileTreeNode::compareEntries):

2012-08-27  Caio Marcelo de Oliveira Filho  <caio.oliveira@openbossa.org>

        Rename first/second to key/value in HashMap iterators
        https://bugs.webkit.org/show_bug.cgi?id=82784

        Reviewed by Eric Seidel.

        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
        (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertyNames):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::~OpaqueJSClass):
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        (OpaqueJSClass::contextData):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::EvalCodeCache::visitAggregate):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/JumpTable.h:
        (JSC::StringJumpTable::offsetForValue):
        (JSC::StringJumpTable::ctiForValue):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::LazyOperandValueProfileParser::getIfPresent):
        * bytecode/SamplingTool.cpp:
        (JSC::SamplingTool::dump):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::addGlobalVar):
        (JSC::BytecodeGenerator::addConstant):
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        (JSC::BytecodeGenerator::emitLazyNewFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * debugger/Debugger.cpp:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        * dfg/DFGByteCodeCache.h:
        (JSC::DFG::ByteCodeCache::~ByteCodeCache):
        (JSC::DFG::ByteCodeCache::get):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstant):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::StructureCheckHoistingPhase::noticeClobber):
        * heap/Heap.cpp:
        (JSC::Heap::markProtectedObjects):
        * heap/Heap.h:
        (JSC::Heap::forEachProtectedCell):
        * heap/JITStubRoutineSet.cpp:
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        * heap/MarkStack.cpp:
        (JSC::MarkStack::internalAppend):
        * heap/Weak.h:
        (JSC::weakRemove):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::ctiStub):
        * parser/Parser.cpp:
        (JSC::::parseStrictObjectLiteral):
        * profiler/Profile.cpp:
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintDataSampleStyle):
        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSArray.cpp:
        (JSC::SparseArrayValueMap::put):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayValueMap::visitChildren):
        (JSC::JSArray::enterDictionaryMode):
        (JSC::JSArray::defineOwnNumericProperty):
        (JSC::JSArray::getOwnPropertySlotByIndex):
        (JSC::JSArray::getOwnPropertyDescriptor):
        (JSC::JSArray::putByIndexBeyondVectorLength):
        (JSC::JSArray::putDirectIndexBeyondVectorLength):
        (JSC::JSArray::deletePropertyByIndex):
        (JSC::JSArray::getOwnPropertyNames):
        (JSC::JSArray::setLength):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        (JSC::JSArray::checkConsistency):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::invalidateCode):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::clear):
        (JSC::WeakGCMap::set):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::sampleChild):
        (JSC::ProfileTreeNode::childCount):
        (JSC::ProfileTreeNode::dumpInternal):
        (JSC::ProfileTreeNode::compareEntries):

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

        Structure check hoisting should abstain if the OSR entry's must-handle value for the respective variable has a different structure
        https://bugs.webkit.org/show_bug.cgi?id=95141
        <rdar://problem/12170401>

        Reviewed by Mark Hahnenberg.

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

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

        Remove use of ClassInfo from SpeculativeJIT::compileGetByValOnArguments
        https://bugs.webkit.org/show_bug.cgi?id=95131

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): We don't need this speculation check. We can replace it 
        with an assert to guarantee this.

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

        Remove opcode definition autogen for now
        https://bugs.webkit.org/show_bug.cgi?id=95148

        Reviewed by Mark Hahnenberg.

        This isn't worth doing at the moment.

        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/OpcodeDefinitions.h: Removed.
        * bytecode/opcodes: Removed.
        * opcode_definition_generator.py: Removed.
        * opcode_generator.py: Removed.
        * opcode_parser.py: Removed.

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

        Remove uses of TypedArray ClassInfo from SpeculativeJIT::checkArgumentTypes
        https://bugs.webkit.org/show_bug.cgi?id=95112

        Reviewed by Filip Pizlo.

        Removing these checks since we no longer need them.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):

2012-08-27  Benjamin Poulain  <benjamin@webkit.org>

        Add ECMAScript Number to String conversion to WTF::String
        https://bugs.webkit.org/show_bug.cgi?id=95016

        Reviewed by Geoffrey Garen.

        Rename UString::number(double) to UString::numberToStringECMAScript(double) to
        differenciate it from the fixed-width conversion performed by String::number().

        * parser/ParserArena.h:
        (JSC::IdentifierArena::makeNumericIdentifier):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToExponential):
        (JSC::numberProtoFuncToFixed):
        (JSC::numberProtoFuncToPrecision):
        (JSC::numberProtoFuncToString):
        * runtime/NumericStrings.h:
        (JSC::NumericStrings::add):
        * runtime/UString.cpp:
        (JSC::UString::numberToStringECMAScript):
        * runtime/UString.h:
        (UString):

2012-08-27  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>

        Rename RegisterProtocolHandler API to NavigatorContentUtils
        https://bugs.webkit.org/show_bug.cgi?id=94920

        Reviewed by Adam Barth.

        ENABLE_REGISTER_PROTOCOL_HANDLER is renamed to ENABLE_NAVIGATOR_CONTENT_UTILS.

        * Configurations/FeatureDefines.xcconfig:

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

        Unreviewed, fix for builds without VALUE_PROFILING. I had forgotten that shouldEmitProfiling()
        is designed to return true if DFG_JIT is disabled. I should be using canBeOptimized() instead.

        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):

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

        Don't allocate space for arguments and call frame if arguments aren't captured
        https://bugs.webkit.org/show_bug.cgi?id=95024

        Reviewed by Phil Pizlo.

        27% on v8-real-earley.

        * runtime/JSActivation.h:
        (JSC::JSActivation::registerOffset): The offset is zero if we're skipping
        the arguments and call frame because "offset" means space reserved for
        those things.

        (JSC::JSActivation::tearOff): Don't copy the scope chain and callee. We
        don't need them for anything, and we're no longer guaranteed to have
        space for them.

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

        Removed the NULL checks from visitChildren functions
        https://bugs.webkit.org/show_bug.cgi?id=95021

        Reviewed by Oliver Hunt.

        As of http://trac.webkit.org/changeset/126624, all values are NULL-checked
        during GC, so explicit NULL checks aren't needed anymore.

2011-08-26  Geoffrey Garen  <ggaren@apple.com>

        Removed a JSC-specific hack from the web inspector
        https://bugs.webkit.org/show_bug.cgi?id=95033

        Reviewed by Filip Pizlo.

        Added support for what the web inspector really wanted instead.

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::symbolTableGet):
        (JSC::JSActivation::symbolTablePut): Added some explanation for these
        checks, which were non-obvious to me.

        (JSC::JSActivation::getOwnPropertySlot): It's impossible to access the
        arguments property of an activation after it's been torn off, since the
        only way to tear off an activation is to instantiate a new function,
        which has its own arguments property in scope. However, the inspector
        get special access to activations, and may try to perform this access,
        so we need a special guard to maintain coherence and avoid crashing in
        case the activation optimized out the arguments property.

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::symbolTableGet):
        (JSC::JSActivation::symbolTablePut):
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::getOwnPropertyDescriptor): Provide getOwnPropertyNames
        and getOwnPropertyDescriptor implementations, to meet the web inspector's
        needs. (User code can never call these.)

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

        Finally inlining should correctly track the catch context
        https://bugs.webkit.org/show_bug.cgi?id=94986
        <rdar://problem/11753784>

        Reviewed by Sam Weinig.

        This fixes two behaviors:
        
        1) Throwing from a finally block. Previously, we would seem to reenter the finally
           block - though only once.
        
        2) Executing a finally block from some nested context, for example due to a
           'continue', 'break', or 'return' in the try. This would execute the finally
           block in the context of of the try block, which could lead to either scope depth
           mismatches or reexecutions of the finally block on throw, similarly to (1) but
           for different reasons.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC):
        (JSC::BytecodeGenerator::pushFinallyContext):
        (JSC::BytecodeGenerator::emitComplexJumpScopes):
        (JSC::BytecodeGenerator::pushTry):
        (JSC::BytecodeGenerator::popTryAndEmitCatch):
        * bytecompiler/BytecodeGenerator.h:
        (FinallyContext):
        (TryData):
        (JSC):
        (TryContext):
        (TryRange):
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):

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

        Array type checks and storage accesses should be uniformly represented and available to CSE
        https://bugs.webkit.org/show_bug.cgi?id=95013

        Reviewed by Oliver Hunt.

        This uniformly breaks up all array accesses into up to three parts:
        
        1) The type check, using a newly introduced CheckArray node, in addition to possibly
           a CheckStructure node. We were already inserting the CheckStructure prior to this
           patch. The CheckArray node will be automatically eliminated if the thing it was
           checking for had already been checked for, either intentionally (a CheckStructure
           inserted based on the array profile of this access) or accidentally (some checks,
           typically a CheckStructure, inserted for some unrelated operations). The
           CheckArray node may not be inserted if the array type is non-specific (Generic or
           ForceExit).
        
        2) The storage load using GetIndexedPropertyStorage. Previously, this only worked for
           GetByVal. Now it works for all array accesses. The storage load may not be
           inserted if the mode of array access does not permit CSE of storage loads (like
           non-specific modes or Arguments).
        
        3) The access itself: one of GetByVal, PutByVal, PutByValAlias, ArrayPush, ArrayPop,
           GetArrayLength, StringCharAt, or StringCharCodeAt.
        
        This means that the type check can be subjected to CSE even if the CFA isn't smart
        enough to reason about it (yet!). It also means that the storage load can always be
        subjected to CSE; previously CSE on storage load only worked for array loads and not
        other forms of access. Finally, it removes the bizarre behavior that
        GetIndexedPropertyStorage previously had: previously, it was responsible for the type
        check in some cases, but not others; this made reasoning about the CFA really
        confusing.
        
        This change also disables late refinement of array mode, since I decided that
        supporting that feature is both confusing and likely unprofitable. The array modes are
        now locked in in the first fixup run after prediction propagation. Of course,
        refinements from Generic to something else would not have been a problem; we could
        reenable those if we thought we really needed to.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromStructure):
        (DFG):
        (JSC::DFG::refineArrayMode):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::modeIsJSArray):
        (JSC::DFG::lengthNeedsStorage):
        (JSC::DFG::modeIsSpecific):
        (JSC::DFG::modeSupportsLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::CSEPhase):
        (JSC::DFG::CSEPhase::checkStructureElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::checkArrayElimination):
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        (JSC::DFG::performCSE):
        * dfg/DFGCSEPhase.h:
        (DFG):
        * dfg/DFGCommon.h:
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        (FixupPhase):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (DFG):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::collectGarbage):
        * dfg/DFGGraph.h:
        (Graph):
        (JSC::DFG::Graph::vote):
        (JSC::DFG::Graph::substitute):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArrayMode):
        (JSC::DFG::Node::setArrayMode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPhase.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::useChildren):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

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

        DFGGraph.h has a bogus comment about the nature of StorageAccessData
        https://bugs.webkit.org/show_bug.cgi?id=95035

        Reviewed by Oliver Hunt.

        The comment is both wrong (storage access instructions don't reference CheckStructure)
        and highly redundant: of course it's the case that two structures may have the same
        identifier. Our interference analyses currently don't care about this and make the
        conservative assumptions when necessary (same identifier, same object -> must be same
        property; same identifier, may be same object -> may be the same property). Better to
        remove the bogus comment since the code that operates over this data structure is
        fairly self-explanatory already.

        * dfg/DFGGraph.h:
        (StorageAccessData):

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

        Try a little harder to fix the Linux build.

        * runtime/JSActivation.cpp:
        * runtime/JSActivation.h:

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

        Try to fix the Linux build.

        * runtime/JSActivation.cpp:

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

        Don't use malloc / destructors for activation objects
        https://bugs.webkit.org/show_bug.cgi?id=94897

        Reviewed by Oliver Hunt.

        65% faster on v8-real-earley.

        Lots of boilerplate here, but the jist is this:

        (1) Use CopiedSpace instead of malloc to allocate the activation's
        backing store.

        (2) Use MarkedSpace instead of ref-counting to allocate the symbol table.

        (3) ==> No more destructor.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::symbolTable):
        (CodeBlock):
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
        (JSC::FunctionCodeBlock::FunctionCodeBlock):
        (FunctionCodeBlock): SymbolTable is a GC object now, so it gets a write
        barrier and visit calls instead of ref-counting. I changed all CodeBlocks
        to use shared symbol tables because the distinction between shared and
        unshared hurt my head.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::emitPutStaticVar):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Sometimes, a period just wants
        to be an arrow. And then C++ is there to accommodate.

        * jit/JITDriver.h:
        (JSC::jitCompileFunctionIfAppropriate):
        * runtime/Arguments.h:
        (ArgumentsData):
        (JSC::Arguments::setRegisters):
        (Arguments):
        (JSC::Arguments::argument):
        (JSC::Arguments::finishCreation):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        (JSC::FunctionExecutable::visitChildren):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::symbolTable):
        (FunctionExecutable):
        * runtime/ExecutionHarness.h:
        (JSC::prepareFunctionForExecution): I changed from WriteBarrier to
        WriteBarrierBase so activations could reuse StorageBarrier and PropertyStorage.

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::JSActivation):
        (JSC::JSActivation::finishCreation): Allocate the symbol table here,
        after we're fully constructed, to avoid GC during initialization.

        (JSC::JSActivation::visitChildren):
        (JSC::JSActivation::symbolTableGet):
        (JSC::JSActivation::symbolTablePut):
        (JSC::JSActivation::getOwnPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSActivation.h:
        (JSC::JSActivation::create):
        (JSActivation):
        (JSC::JSActivation::registerOffset):
        (JSC):
        (JSC::JSActivation::registerArraySize):
        (JSC::JSActivation::registerArraySizeInBytes):
        (JSC::JSActivation::tearOff): Tear-off zero-initializes all uncopied
        registers. This makes it safe to copyAndAppend the full buffer in
        visitChildren, without any extra checks.

        * runtime/JSCell.h:
        (JSCell): Moved a shared default set of flags into this base class, so
        I could use it in a few places.

        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData): New structure for symbol tables.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::addStaticGlobals):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::symbolTableHasProperty): We don't need an inline
        symbol table -- JSSymbolTableObject will GC allocate one for us.

        * runtime/JSObject.h:
        (JSObject):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
        * runtime/JSStaticScopeObject.cpp:
        (JSC):
        (JSC::JSStaticScopeObject::visitChildren): NULL check our register store
        because finishCreation allocates an object now, so we may get marked
        before we've assigned to our register store.

        * runtime/JSStaticScopeObject.h:
        (JSC::JSStaticScopeObject::finishCreation):
        (JSC::JSStaticScopeObject::JSStaticScopeObject):
        (JSStaticScopeObject): No more destructor for this object, either, since
        it no longer embeds a hash table.

        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::visitChildren):
        (JSC::JSSymbolTableObject::deleteProperty):
        (JSC::JSSymbolTableObject::getOwnPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::symbolTable):
        (JSSymbolTableObject):
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        (JSC::JSSymbolTableObject::finishCreation):
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes): SymbolTableObject allocates a symbol
        table automatically if one isn't provided. (Activations provide their
        own, which they get from compiled code.)

        * runtime/JSVariableObject.cpp:
        (JSC):
        * runtime/JSVariableObject.h:
        (JSC::JSVariableObject::registerAt):
        (JSC::JSVariableObject::addressOfRegisters):
        (JSVariableObject):
        (JSC::JSVariableObject::JSVariableObject):
        (JSC::JSVariableObject::finishCreation): Removed a bunch of obsolete code.
        Activations manage their registers directly now.

        * runtime/StorageBarrier.h:
        (StorageBarrier):
        (JSC::StorageBarrier::operator!):

        * runtime/SymbolTable.cpp:
        (JSC):
        (JSC::SharedSymbolTable::destroy):
        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::create):
        (SharedSymbolTable):
        (JSC::SharedSymbolTable::createStructure):
        (JSC::SharedSymbolTable::SharedSymbolTable): Boilerplat code to
        make shared symbol table GC-allocated.

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

        op_call should have ArrayProfiling for the benefit of array intrinsics
        https://bugs.webkit.org/show_bug.cgi?id=95014

        Reviewed by Sam Weinig.

        This is a performance-neutral change that just adds the profiling but does not
        use it, yet. If in the future we wanted to make this kind of profiling cheaper
        we could move it into specialized thunks for the relevant array intrinsics, but
        I figure that if this much simpler change gives us what we need without any
        discernable performance penalty then that's for the best.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCall):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        The redundant phi elimination phase is not used and should be removed
        https://bugs.webkit.org/show_bug.cgi?id=95006

        Reviewed by Dan Bernstein.

        Just removing dead code.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * dfg/DFGDriver.cpp:
        * dfg/DFGRedundantPhiEliminationPhase.cpp: Removed.
        * dfg/DFGRedundantPhiEliminationPhase.h: Removed.

2012-08-24  Benjamin Poulain  <bpoulain@apple.com>

        Unify Number to StringImpl conversion
        https://bugs.webkit.org/show_bug.cgi?id=94879

        Reviewed by Geoffrey Garen.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * runtime/UString.cpp:
        * runtime/UString.h:
        (JSC::UString::number):
        Update UString to directly use the common NumberToString implementation.

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

        Always null check cells before marking
        https://bugs.webkit.org/show_bug.cgi?id=94968

        Reviewed by Geoffrey Garen.

        Originally we tried to minimise null checks by only null checking values
        that we knew could be null, however given that we can't ever guarantee
        when a GC will happen, we're better off just always assuming that a null
        check will be necessary.  This results in a much less fragile code base
        as we can add GC allocations to object initialisers without having to
        subsequently worry about whether the object we are initialising will need
        to add a bunch of null checks in its visitChildren implementation.

        * heap/MarkStack.cpp:
        (JSC::MarkStack::internalAppend):
        * heap/MarkStackInlineMethods.h:
        (JSC::MarkStack::append):
        (JSC::MarkStack::appendUnbarrieredPointer):
        * runtime/Structure.h:
        (JSC::MarkStack::internalAppend):

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

        Autogenerate Opcode definitions
        https://bugs.webkit.org/show_bug.cgi?id=94840

        Reviewed by Gavin Barraclough.

        Start the process of autogenerating the code emission for the bytecode.
        We'll just start with automatic generation of the list of Opcodes as that
        requires the actual definition of the opcodes, and the logic for parsing
        them.

        Due to some rather annoying dependency cycles, this initial version has
        the OpcodeDefinitions.h file checked into the tree, although with some
        work I hope to be able to fix that.

        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Opcode.h:
          Include OpcodeDefinitions.h as our definitive source of info
          about the opcodes.
        * bytecode/OpcodeDefinitions.h: Added.
          Autogenerated file
        * bytecode/opcodes: Added.
          The new opcode definition file
        * opcode_definition_generator.py: Added.
        (generateOpcodeDefinition):
        (generate):
          Module that generates the content for OpcodeDefinitions.h
        * opcode_generator.py: Added.
        (printUsage):
        (main):
          Driver script
        * opcode_parser.py: Added.
          Simple parser for the opcode definitions.

2011-08-23  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling out r126505.
        http://trac.webkit.org/changeset/126505
        https://bugs.webkit.org/show_bug.cgi?id=94840

        Caused testapi to crash on launch

        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/OpcodeDefinitions.h: Removed.
        * bytecode/opcodes: Removed.
        * opcode_definition_generator.py: Removed.
        * opcode_generator.py: Removed.
        * opcode_parser.py: Removed.

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

        Autogenerate Opcode definitions
        https://bugs.webkit.org/show_bug.cgi?id=94840

        Reviewed by Gavin Barraclough.

        Start the process of autogenerating the code emission for the bytecode.
        We'll just start with automatic generation of the list of Opcodes as that
        requires the actual definition of the opcodes, and the logic for parsing
        them.

        Due to some rather annoying dependency cycles, this initial version has
        the OpcodeDefinitions.h file checked into the tree, although with some
        work I hope to be able to fix that.

        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Opcode.h:
          Include OpcodeDefinitions.h as our definitive source of info
          about the opcodes.
        * bytecode/OpcodeDefinitions.h: Added.
          Autogenerated file
        * bytecode/opcodes: Added.
          The new opcode definition file
        * opcode_definition_generator.py: Added.
        (generateOpcodeDefinition):
        (generate):
          Module that generates the content for OpcodeDefinitions.h
        * opcode_generator.py: Added.
        (printUsage):
        (main):
          Driver script
        * opcode_parser.py: Added.
          Simple parser for the opcode definitions.

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

        Change behavior of MasqueradesAsUndefined to better accommodate DFG changes
        https://bugs.webkit.org/show_bug.cgi?id=93884

        Reviewed by Filip Pizlo.

        With some upcoming changes to the DFG to remove uses of ClassInfo, we will be changing the behavior of  
        MasqueradesAsUndefined. In order to make this change consistent across all of our execution engines,  
        we will make this change to MasqueradesAsUndefined as a separate patch. After this patch, MasqueradesAsUndefined  
        objects will only masquerade as undefined in their original context (i.e. their original JSGlobalObject).  
        For example, if an object that masquerades as undefined in frame A is passed to frame B, it will not  
        masquerade as undefined within frame B, but it will continue to masquerade in frame A. 

        There are two primary changes that are taking place here. One is to thread the ExecState* through  
        JSValue::toBoolean and JSCell::toBoolean so that JSCell::toBoolean can check the object's  
        JSGlobalObject to compare it to the lexical JSGlobalObject of the currently running code. If the two  
        are distinct, then the object cannot MasqueradeAsUndefined. 

        The other change is to perform this comparison of JSGlobalObjects everywhere where the MasqueradesAsUndefined 
        flag in the Structure is checked. For C++ code, this check has been factored into its own function in  
        Structure::masqueradesAsUndefined. We only perform this check in the DFG if the current JSGlobalObject has  
        had a MasqueradesAsUndefined object allocated within its context. This conditional compilation is managed  
        through the use of a WatchpointSet in each JSGlobalObject and alternate create() functions for JS DOM wrappers 
        that are MasqueradesAsUndefined.

        * API/JSValueRef.cpp:
        (JSValueToBoolean):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * bytecode/Watchpoint.h:
        (WatchpointSet):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::callFrame):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::compile):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncFilter):
        (JSC::arrayProtoFuncEvery):
        (JSC::arrayProtoFuncSome):
        * runtime/BooleanConstructor.cpp:
        (JSC::constructBoolean):
        (JSC::callBooleanConstructor):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::masqueradesAsUndefinedWatchpoint):
        * runtime/JSString.h:
        (JSC::JSCell::toBoolean):
        (JSC::JSValue::toBoolean):
        * runtime/JSValue.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        (JSC::jsIsObjectType):
        * runtime/Operations.h:
        (JSC):
        (JSC::JSValue::equalSlowCaseInline):
        * runtime/RegExpConstructor.cpp:
        (JSC::setRegExpConstructorMultiline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncToString):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::globalObjectOffset):
        (JSC::Structure::masqueradesAsUndefined):
        (JSC):

2012-08-23  Mark Rowe  <mrowe@apple.com>

        Make JavaScriptCore build with the latest version of clang.

        Reviewed by Dan Bernstein.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads): The m_heap member is only used within
        assertions, so guard its initialization with !ASSERT_DISABLED.
        * heap/MachineStackMarker.h:
        (MachineThreads): Ditto for its declaration.
        * jit/JITStubCall.h:
        (JSC::JITStubCall::JITStubCall): The m_returnType member is only used within
        assertions or if we're using JSVALUE32_64, so guard its uses with the appropriate
        #if.
        (JITStubCall): Ditto.

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

        Serialization of JavaScript values does not appear to respect new HTML5 Structured Clone semantics
        https://bugs.webkit.org/show_bug.cgi?id=65292

        Reviewed by Oliver Hunt.

        Add function to construct a StringObject from a JSValue.
        Similar functions already exist for NumberObject and
        BooleanObject for example.

        Export several symbols so address linking errors in
        WebCore.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * runtime/BooleanObject.h:
        (BooleanObject):
        * runtime/NumberObject.h:
        (NumberObject):
        (JSC):
        * runtime/StringObject.cpp:
        (JSC::constructString):
        (JSC):
        * runtime/StringObject.h:
        (JSC):

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

        Array accesses should remember what kind of array they are predicted to access
        https://bugs.webkit.org/show_bug.cgi?id=94448

        Reviewed by Gavin Barraclough.

        Introduced the notion of DFG::Array::Mode, stored in node.arrayMode(), which allows nodes
        to remember how they decided to access arrays. This permits the bytecode parser to "lock in"
        the mode of access if it has profiling at its disposal, and it also allows the prediction
        propagator to do a fixup of the array mode later in the optimization fixpoint.
        
        This patch adds a healthy amount of new capability (specifically the ability of the parser
        to lock in an array mode regardless of type predictions) and it also blows away a lot of
        messy code.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGArrayMode.cpp: Added.
        (DFG):
        (JSC::DFG::fromObserved):
        (JSC::DFG::refineArrayMode):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h: Added.
        (DFG):
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::modeForPut):
        (JSC::DFG::modesCompatibleForStorageLoad):
        (JSC::DFG::modeSupportsLength):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::getArrayModeWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getByValLoadElimination):
        (JSC::DFG::CSEPhase::checkStructureLoadElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
        (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        (JSC::DFG::Graph::clobbersWorld):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArrayMode):
        (Node):
        (JSC::DFG::Node::arrayMode):
        (JSC::DFG::Node::setArrayMode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::typedArrayDescriptor):
        (DFG):
        (JSC::DFG::SpeculativeJIT::speculateArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

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

        ThreadRestrictionVerifier should be opt-in, not opt-out
        https://bugs.webkit.org/show_bug.cgi?id=94761

        Reviewed by Mark Hahnenberg.

        Removed explicit calls to disable the verifier, since it's off by default now.

        * parser/SourceProvider.h:
        (JSC::SourceProvider::SourceProvider):
        (SourceProvider):
        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::SharedSymbolTable):

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

        Separate MarkStackThreadSharedData from MarkStack
        https://bugs.webkit.org/show_bug.cgi?id=94294

        Reviewed by Filip Pizlo.

        MarkStackThreadSharedData is soon going to have data to allow for a parallel copying 
        mode too, so to separate our concerns we should split it out into its own set of files 
        and rename it to GCThreadSharedData. For now this is purely a cosmetic refactoring.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * heap/GCThreadSharedData.cpp: Added.
        (JSC):
        (JSC::GCThreadSharedData::resetChildren):
        (JSC::GCThreadSharedData::childVisitCount):
        (JSC::GCThreadSharedData::markingThreadMain):
        (JSC::GCThreadSharedData::markingThreadStartFunc):
        (JSC::GCThreadSharedData::GCThreadSharedData):
        (JSC::GCThreadSharedData::~GCThreadSharedData):
        (JSC::GCThreadSharedData::reset):
        * heap/GCThreadSharedData.h: Added.
        (JSC):
        (GCThreadSharedData):
        * heap/Heap.h:
        (Heap):
        * heap/ListableHandler.h:
        (ListableHandler):
        * heap/MarkStack.cpp:
        (JSC::MarkStack::MarkStack):
        (JSC::MarkStack::~MarkStack):
        * heap/MarkStack.h:
        (JSC):
        (MarkStack):
        (JSC::MarkStack::sharedData):
        * heap/MarkStackInlineMethods.h: Added.
        (JSC):
        (JSC::MarkStack::append):
        (JSC::MarkStack::appendUnbarrieredPointer):
        (JSC::MarkStack::appendUnbarrieredValue):
        (JSC::MarkStack::internalAppend):
        (JSC::MarkStack::addWeakReferenceHarvester):
        (JSC::MarkStack::addUnconditionalFinalizer):
        (JSC::MarkStack::addOpaqueRoot):
        (JSC::MarkStack::containsOpaqueRoot):
        (JSC::MarkStack::opaqueRootCount):
        * heap/SlotVisitor.h:
        (JSC):
        (SlotVisitor):
        (JSC::SlotVisitor::SlotVisitor):

2012-08-22  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        Fix JSC build when DFG-JIT is disabled
        https://bugs.webkit.org/show_bug.cgi?id=94694

        Reviewed by Csaba Osztrogonác.

        Adding an appropriate guard for fixing the build.

        * bytecode/ResolveGlobalStatus.cpp:
        (JSC):

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

        Introducing the VMInspector for VM debugging use.
        https://bugs.webkit.org/show_bug.cgi?id=94613.

        Reviewed by Filip Pizlo.

        Adding some utility functions for debugging the VM. This code is
        presently #ifdef'd out by default.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/VMInspector.cpp: Added.
        (JSC):
        (JSC::VMInspector::getTypeName):
        (JSC::VMInspector::dumpFrame0):
        (JSC::VMInspector::dumpFrame):
        (JSC::VMInspector::countFrames):
        * interpreter/VMInspector.h: Added.
        (JSC):
        (VMInspector):

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

        A patchable GetById right after a watchpoint should have the appropriate nop padding
        https://bugs.webkit.org/show_bug.cgi?id=94635

        Reviewed by Mark Hahnenberg.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::padBeforePatch):
        (AbstractMacroAssembler):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch):
        (JSC::MacroAssemblerARMv7::moveWithPatch):
        (JSC::MacroAssemblerARMv7::patchableJump):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::moveWithPatch):
        (JSC::MacroAssemblerX86::branchPtrWithPatch):
        (JSC::MacroAssemblerX86::storePtrWithPatch):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::load32WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86Common::load32WithCompactAddressOffsetPatch):
        (JSC::MacroAssemblerX86Common::loadCompactWithAddressOffsetPatch):
        (JSC::MacroAssemblerX86Common::store32WithAddressOffsetPatch):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::loadPtrWithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::loadPtrWithCompactAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::storePtrWithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::moveWithPatch):
        * jit/JumpReplacementWatchpoint.cpp:
        (JSC::JumpReplacementWatchpoint::fireInternal):

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

        Fix broken non-JIT build.
        https://bugs.webkit.org/show_bug.cgi?id=94564.

        Reviewed by Filip Pizlo.

        Added some UNUSED_PARAM() macros to make the compiler happy.

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

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

        Fixed erroneous line number for LLint frame when throwing exceptions.
        https://bugs.webkit.org/show_bug.cgi?id=94051.

        Reviewed by Filip Pizlo.

        For LLInt frames, before throwing an exception, adjust the PC from the
        return PC back to the call PC if we are indeed at a call site.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::adjustPCIfAtCallSite):
        (JSC):
        (JSC::CodeBlock::bytecodeOffset):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::fixupPCforExceptionIfNeeded):
        (LLInt):
        (JSC::LLInt::interpreterThrowInCaller):
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):

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

        fast/js/dfg-peephole-compare-final-object-to-final-object-or-other-when-both-proven-final-object.html on 32-bit
        https://bugs.webkit.org/show_bug.cgi?id=94538

        Reviewed by Mark Hahnenberg.

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

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

        fast/js/dfg-compare-final-object-to-final-object-or-other-when-both-proven-final-object.html crashes on 32-bit
        https://bugs.webkit.org/show_bug.cgi?id=94026

        Reviewed by Mark Hahnenberg.

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

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

        The relationship between abstract values and structure transition watchpoints should be rationalized
        https://bugs.webkit.org/show_bug.cgi?id=94205

        Reviewed by Geoffrey Garen.

        This patch does a number of things related to the handling of the abstract values
        arrising from values with structures known to be watchpointable:
        
        - This rationalizes the relationship between the structure that we know an object
          to have *right now* based on having executed a check against that structure, and
          the structure that we know the object could have *in the future* based on a type
          check executed in the past over a structure that was watchpointable.
        
        - We use the above to assert that structure transition watchpoints are being used
          soundly.
        
        - We use the above to strength reduce CheckStructure into StructureTransitionWatchpoint
          whenever possible.
        
        - This rationalizes the handling of CFA over constants that appeared in the bytecode.
          If at compile-time the constant has a watchpointable structure, then we can prove
          what structures it may have in the future. The analysis uses this to both assert
          that structure transition watchpoints are being used correctly, and to find
          opportunities for using them more aggressively.
        
        The net effect of all of these changes is that OSR entry should work more smoothly.
        It may also be a slight win due to strength reductions, though most of those strength
        reductions would have already been done by the parser and the structure check hoister.

        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::beginBasicBlock):
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (DFG):
        (JSC::DFG::AbstractValue::clear):
        (JSC::DFG::AbstractValue::isClear):
        (JSC::DFG::AbstractValue::makeTop):
        (JSC::DFG::AbstractValue::clobberStructures):
        (JSC::DFG::AbstractValue::isTop):
        (JSC::DFG::AbstractValue::setFuturePossibleStructure):
        (AbstractValue):
        (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
        (JSC::DFG::AbstractValue::setMostSpecific):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::operator==):
        (JSC::DFG::AbstractValue::merge):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::filterValueByType):
        (JSC::DFG::AbstractValue::validateType):
        (JSC::DFG::AbstractValue::validate):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::dump):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::checkStructureLoadElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToStructureTransitionWatchpoint):
        (Node):
        (JSC::DFG::Node::hasStructure):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationWatchpoint):
        (DFG):
        (JSC::DFG::SpeculativeJIT::speculationWatchpointWithConditionalDirection):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::speculateArray):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureAbstractValue.h: Added.
        (DFG):
        (StructureAbstractValue):
        (JSC::DFG::StructureAbstractValue::StructureAbstractValue):
        (JSC::DFG::StructureAbstractValue::clear):
        (JSC::DFG::StructureAbstractValue::makeTop):
        (JSC::DFG::StructureAbstractValue::top):
        (JSC::DFG::StructureAbstractValue::add):
        (JSC::DFG::StructureAbstractValue::addAll):
        (JSC::DFG::StructureAbstractValue::contains):
        (JSC::DFG::StructureAbstractValue::isSubsetOf):
        (JSC::DFG::StructureAbstractValue::doesNotContainAnyOtherThan):
        (JSC::DFG::StructureAbstractValue::isSupersetOf):
        (JSC::DFG::StructureAbstractValue::filter):
        (JSC::DFG::StructureAbstractValue::isClear):
        (JSC::DFG::StructureAbstractValue::isTop):
        (JSC::DFG::StructureAbstractValue::isClearOrTop):
        (JSC::DFG::StructureAbstractValue::isNeitherClearNorTop):
        (JSC::DFG::StructureAbstractValue::size):
        (JSC::DFG::StructureAbstractValue::at):
        (JSC::DFG::StructureAbstractValue::operator[]):
        (JSC::DFG::StructureAbstractValue::last):
        (JSC::DFG::StructureAbstractValue::speculationFromStructures):
        (JSC::DFG::StructureAbstractValue::hasSingleton):
        (JSC::DFG::StructureAbstractValue::singleton):
        (JSC::DFG::StructureAbstractValue::operator==):
        (JSC::DFG::StructureAbstractValue::dump):
        (JSC::DFG::StructureAbstractValue::topValue):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

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

        The current state of the call frame should be taken into account in the DFG for both predictions and proofs
        https://bugs.webkit.org/show_bug.cgi?id=94412

        Reviewed by Geoffrey Garen.

        This ensures that no matter how smart the DFG gets, it'll always know through
        which entrypoint OSR will try to enter, and with which values it will attempt
        to do so. For prologue OSR, this has no effect other than adding the current
        arguments to the argument predictions. For loop OSR, this makes our treatment
        of the loop slightly more conservative - just conservative enough to ensure
        that OSR succeeds.

        * bytecode/CodeBlock.cpp:
        (JSC::ProgramCodeBlock::compileOptimized):
        (JSC::EvalCodeBlock::compileOptimized):
        (JSC::FunctionCodeBlock::compileOptimized):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::setMostSpecific):
        (AbstractValue):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::fixVariableAccessPredictions):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGDriver.h:
        (DFG):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::Graph):
        (Graph):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileOptimized):
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::compileOptimized):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::compileOptimizedForCall):
        (JSC::FunctionExecutable::compileOptimizedForConstruct):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (EvalExecutable):
        (ProgramExecutable):
        (FunctionExecutable):
        (JSC::FunctionExecutable::compileOptimizedFor):
        * runtime/ExecutionHarness.h:
        (JSC::prepareForExecution):
        (JSC::prepareFunctionForExecution):

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

        DFG CSE should be more honest about when it changed the IR
        https://bugs.webkit.org/show_bug.cgi?id=94408

        Reviewed by Geoffrey Garen.

        The CSE phase now always returns true if it changed the IR.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::setReplacement):
        (JSC::DFG::CSEPhase::eliminate):
        (JSC::DFG::CSEPhase::performNodeCSE):

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

        DFG is still too pessimistic about what constitutes a side-effect on array accesses
        https://bugs.webkit.org/show_bug.cgi?id=94309

        Reviewed by Geoffrey Garen.

        This change means that even if structure transition watchpoints are not used for
        hoisting of clobbered structure checks, we still retain good performance on the
        benchmarks we care about. That's important, since butterflies will likely make
        most array structures not watchpointable.

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

2012-08-17  Milian Wolff  <milian.wolff@kdab.com>

        [Qt] QNX build fails due to ctype usage in system headers
        https://bugs.webkit.org/show_bug.cgi?id=93849

        Reviewed by Simon Hausmann.

        Move the check for whether DisallowCType should be active or not
        to the DisallowCType.h header. This way, we can update the list
        of platforms or OSes which do not work with this header in a
        central place. All users can now safely include the header
        and do not need to place custom guards around it.

        * config.h:

2012-08-16  Simon Hausmann  <simon.hausmann@nokia.com>

        [Qt] Replace use of internal Weak smart pointer with JSWeakObjectMap
        https://bugs.webkit.org/show_bug.cgi?id=93872

        Reviewed by Kenneth Rohde Christiansen.

        * Target.pri: Add missing JSWeakObjectMap file to build.

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

        Structure check hoisting should be less expensive
        https://bugs.webkit.org/show_bug.cgi?id=94201

        Reviewed by Mark Hahnenberg.

        This appears like a broad win on short-running programs.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::compareAndSwap):
        (Graph):
        (JSC::DFG::Graph::substitute):
        (JSC::DFG::Graph::substituteGetLocal):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

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

        All op_resolve_global instructions should end up in the list of global resolve instructions
        https://bugs.webkit.org/show_bug.cgi?id=94247
        <rdar://problem/12103500>

        Reviewed by Mark Hahnenberg.

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

2012-08-15  Bruno de Oliveira Abinader  <bruno.abinader@basyskom.com>

        [css3-text] Add CSS3 Text decoration compile flag
        https://bugs.webkit.org/show_bug.cgi?id=93863

        Reviewed by Julien Chaffraix.

        This patch handles the compile flag implementation, which will come disabled by
        default, thus not exposing the CSS3 text decoration features to the web, unless
        when explicitly enabling it with "--css3-text-decoration" build parameter.

        * Configurations/FeatureDefines.xcconfig:

2012-08-15  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r125687.
        http://trac.webkit.org/changeset/125687
        https://bugs.webkit.org/show_bug.cgi?id=94147

        It broke the whole world (Requested by Ossy_night on #webkit).

        * API/JSValueRef.cpp:
        (JSValueToBoolean):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * bytecode/Watchpoint.h:
        (WatchpointSet):
        * debugger/DebuggerCallFrame.h:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::compile):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncFilter):
        (JSC::arrayProtoFuncEvery):
        (JSC::arrayProtoFuncSome):
        * runtime/BooleanConstructor.cpp:
        (JSC::constructBoolean):
        (JSC::callBooleanConstructor):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        * runtime/JSString.h:
        (JSC::JSCell::toBoolean):
        (JSC::JSValue::toBoolean):
        * runtime/JSValue.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        (JSC::jsIsObjectType):
        * runtime/Operations.h:
        (JSC):
        (JSC::JSValue::equalSlowCaseInline):
        * runtime/RegExpConstructor.cpp:
        (JSC::setRegExpConstructorMultiline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncToString):
        * runtime/Structure.h:

2012-08-15  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        Buildfix after r125541
        https://bugs.webkit.org/show_bug.cgi?id=94097

        Reviewed by Filip Pizlo.

        r125541 has broken the traditional ARM port build of JSC.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::neg32):
        (JSC::MacroAssemblerARM::xor32):

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

        Change behavior of MasqueradesAsUndefined to better accommodate DFG changes
        https://bugs.webkit.org/show_bug.cgi?id=93884

        Reviewed by Geoffrey Garen.

        With some upcoming changes to the DFG to remove uses of ClassInfo, we will be changing the behavior of 
        MasqueradesAsUndefined. In order to make this change consistent across all of our execution engines, 
        we will make this change to MasqueradesAsUndefined as a separate patch. After this patch, MasqueradesAsUndefined 
        objects will only masquerade as undefined in their original context (i.e. their original JSGlobalObject). 
        For example, if an object that masquerades as undefined in frame A is passed to frame B, it will not 
        masquerade as undefined within frame B, but it will continue to masquerade in frame A.

        There are two primary changes that are taking place here. One is to thread the ExecState* through 
        JSValue::toBoolean and JSCell::toBoolean so that JSCell::toBoolean can check the object's 
        JSGlobalObject to compare it to the lexical JSGlobalObject of the currently running code. If the two 
        are distinct, then the object cannot MasqueradeAsUndefined.

        The other change is to perform this comparison of JSGlobalObjects everywhere where the MasqueradesAsUndefined
        flag in the Structure is checked. For C++ code, this check has been factored into its own function in 
        Structure::masqueradesAsUndefined. We only perform this check in the DFG if the current JSGlobalObject has 
        had a MasqueradesAsUndefined object allocated within its context. This conditional compilation is managed 
        through the use of a WatchpointSet in each JSGlobalObject and alternate create() functions for JS DOM wrappers
        that are MasqueradesAsUndefined.

        * API/JSValueRef.cpp:
        (JSValueToBoolean):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * bytecode/Watchpoint.h:
        (WatchpointSet):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::callFrame):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::compile):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncFilter):
        (JSC::arrayProtoFuncEvery):
        (JSC::arrayProtoFuncSome):
        * runtime/BooleanConstructor.cpp:
        (JSC::constructBoolean):
        (JSC::callBooleanConstructor):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::masqueradesAsUndefinedWatchpoint):
        * runtime/JSString.h:
        (JSC::JSCell::toBoolean):
        (JSC::JSValue::toBoolean):
        * runtime/JSValue.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        (JSC::jsIsObjectType):
        * runtime/Operations.h:
        (JSC):
        (JSC::JSValue::equalSlowCaseInline):
        * runtime/RegExpConstructor.cpp:
        (JSC::setRegExpConstructorMultiline):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncToString):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::globalObjectOffset):
        (JSC::Structure::masqueradesAsUndefined):
        (JSC):

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

        Unreviewed, build fix for !ENABLE(DFG_JIT)

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

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

        Array checks should use the structure, not the class info
        https://bugs.webkit.org/show_bug.cgi?id=93150

        Reviewed by Mark Hahnenberg.

        This changes all array checks used in array accesses (get, put, get length,
        push, pop) to use the structure, not the class info. Additionally, these
        checks in the LLInt and baseline JIT record the structure in an ArrayProfile,
        so that the DFG can know exactly what structure to check for.
        
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ArrayProfile.cpp: Added.
        (JSC):
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h: Added.
        (JSC):
        (JSC::arrayModeFromStructure):
        (ArrayProfile):
        (JSC::ArrayProfile::ArrayProfile):
        (JSC::ArrayProfile::bytecodeOffset):
        (JSC::ArrayProfile::addressOfLastSeenStructure):
        (JSC::ArrayProfile::observeStructure):
        (JSC::ArrayProfile::expectedStructure):
        (JSC::ArrayProfile::structureIsPolymorphic):
        (JSC::ArrayProfile::hasDefiniteStructure):
        (JSC::ArrayProfile::observedArrayModes):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::getArrayProfile):
        (JSC):
        (JSC::CodeBlock::getOrAddArrayProfile):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::executionEntryCount):
        (JSC::CodeBlock::numberOfArrayProfiles):
        (JSC::CodeBlock::arrayProfiles):
        (JSC::CodeBlock::addArrayProfile):
        (CodeBlock):
        * bytecode/Instruction.h:
        (JSC):
        (JSC::Instruction::Instruction):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetArgumentByVal):
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitPutByVal):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::hasSingleton):
        (StructureAbstractValue):
        (JSC::DFG::StructureAbstractValue::singleton):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateArray):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::classInfoOffset):

2012-08-14  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        Rename functions in the ARM port of DFG-JIT for better code readability.
        https://bugs.webkit.org/show_bug.cgi?id=93609

        Reviewed by Zoltan Herczeg.

        Rename functions in the ARM port of DFG-JIT for better code
        readability, and for following the WebKit coding style
        wherever it is possible.

        * assembler/ARMAssembler.cpp:
        (JSC::ARMAssembler::genInt):
        (JSC::ARMAssembler::getImm):
        (JSC::ARMAssembler::moveImm):
        (JSC::ARMAssembler::encodeComplexImm):
        (JSC::ARMAssembler::dataTransfer32):
        (JSC::ARMAssembler::baseIndexTransfer32):
        (JSC::ARMAssembler::dataTransfer16):
        (JSC::ARMAssembler::baseIndexTransfer16):
        (JSC::ARMAssembler::dataTransferFloat):
        (JSC::ARMAssembler::baseIndexTransferFloat):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::bitAnd):
        (JSC::ARMAssembler::bitAnds):
        (JSC::ARMAssembler::eor):
        (JSC::ARMAssembler::eors):
        (JSC::ARMAssembler::sub):
        (JSC::ARMAssembler::subs):
        (JSC::ARMAssembler::rsb):
        (JSC::ARMAssembler::rsbs):
        (JSC::ARMAssembler::add):
        (JSC::ARMAssembler::adds):
        (JSC::ARMAssembler::adc):
        (JSC::ARMAssembler::adcs):
        (JSC::ARMAssembler::sbc):
        (JSC::ARMAssembler::sbcs):
        (JSC::ARMAssembler::rsc):
        (JSC::ARMAssembler::rscs):
        (JSC::ARMAssembler::tst):
        (JSC::ARMAssembler::teq):
        (JSC::ARMAssembler::cmp):
        (JSC::ARMAssembler::cmn):
        (JSC::ARMAssembler::orr):
        (JSC::ARMAssembler::orrs):
        (JSC::ARMAssembler::mov):
        (JSC::ARMAssembler::movw):
        (JSC::ARMAssembler::movt):
        (JSC::ARMAssembler::movs):
        (JSC::ARMAssembler::bic):
        (JSC::ARMAssembler::bics):
        (JSC::ARMAssembler::mvn):
        (JSC::ARMAssembler::mvns):
        (JSC::ARMAssembler::mul):
        (JSC::ARMAssembler::muls):
        (JSC::ARMAssembler::mull):
        (JSC::ARMAssembler::vmov_f64):
        (JSC::ARMAssembler::vadd_f64):
        (JSC::ARMAssembler::vdiv_f64):
        (JSC::ARMAssembler::vsub_f64):
        (JSC::ARMAssembler::vmul_f64):
        (JSC::ARMAssembler::vcmp_f64):
        (JSC::ARMAssembler::vsqrt_f64):
        (JSC::ARMAssembler::vabs_f64):
        (JSC::ARMAssembler::vneg_f64):
        (JSC::ARMAssembler::ldrImmediate):
        (JSC::ARMAssembler::ldrUniqueImmediate):
        (JSC::ARMAssembler::dtrUp):
        (JSC::ARMAssembler::dtrUpRegister):
        (JSC::ARMAssembler::dtrDown):
        (JSC::ARMAssembler::dtrDownRegister):
        (JSC::ARMAssembler::halfDtrUp):
        (JSC::ARMAssembler::halfDtrUpRegister):
        (JSC::ARMAssembler::halfDtrDown):
        (JSC::ARMAssembler::halfDtrDownRegister):
        (JSC::ARMAssembler::doubleDtrUp):
        (JSC::ARMAssembler::doubleDtrDown):
        (JSC::ARMAssembler::push):
        (JSC::ARMAssembler::pop):
        (JSC::ARMAssembler::poke):
        (JSC::ARMAssembler::peek):
        (JSC::ARMAssembler::vmov_vfp64):
        (JSC::ARMAssembler::vmov_arm64):
        (JSC::ARMAssembler::vmov_vfp32):
        (JSC::ARMAssembler::vmov_arm32):
        (JSC::ARMAssembler::vcvt_f64_s32):
        (JSC::ARMAssembler::vcvt_s32_f64):
        (JSC::ARMAssembler::vcvt_u32_f64):
        (JSC::ARMAssembler::vcvt_f64_f32):
        (JSC::ARMAssembler::vcvt_f32_f64):
        (JSC::ARMAssembler::clz):
        (JSC::ARMAssembler::lslRegister):
        (JSC::ARMAssembler::lsrRegister):
        (JSC::ARMAssembler::asrRegister):
        (JSC::ARMAssembler::align):
        (JSC::ARMAssembler::loadBranchTarget):
        (JSC::ARMAssembler::vmov):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::add32):
        (JSC::MacroAssemblerARM::and32):
        (JSC::MacroAssemblerARM::lshift32):
        (JSC::MacroAssemblerARM::mul32):
        (JSC::MacroAssemblerARM::or32):
        (JSC::MacroAssemblerARM::rshift32):
        (JSC::MacroAssemblerARM::urshift32):
        (JSC::MacroAssemblerARM::sub32):
        (JSC::MacroAssemblerARM::xor32):
        (JSC::MacroAssemblerARM::countLeadingZeros32):
        (JSC::MacroAssemblerARM::convertibleLoadPtr):
        (JSC::MacroAssemblerARM::load32WithAddressOffsetPatch):
        (JSC::MacroAssemblerARM::load32WithCompactAddressOffsetPatch):
        (JSC::MacroAssemblerARM::store32WithAddressOffsetPatch):
        (JSC::MacroAssemblerARM::store32):
        (JSC::MacroAssemblerARM::pop):
        (JSC::MacroAssemblerARM::push):
        (JSC::MacroAssemblerARM::move):
        (JSC::MacroAssemblerARM::swap):
        (JSC::MacroAssemblerARM::branch32):
        (JSC::MacroAssemblerARM::branchTest32):
        (JSC::MacroAssemblerARM::mull32):
        (JSC::MacroAssemblerARM::branchSub32):
        (JSC::MacroAssemblerARM::compare32):
        (JSC::MacroAssemblerARM::test32):
        (JSC::MacroAssemblerARM::load32):
        (JSC::MacroAssemblerARM::relativeTableJump):
        (JSC::MacroAssemblerARM::moveWithPatch):
        (JSC::MacroAssemblerARM::loadDouble):
        (JSC::MacroAssemblerARM::moveDouble):
        (JSC::MacroAssemblerARM::addDouble):
        (JSC::MacroAssemblerARM::divDouble):
        (JSC::MacroAssemblerARM::subDouble):
        (JSC::MacroAssemblerARM::mulDouble):
        (JSC::MacroAssemblerARM::sqrtDouble):
        (JSC::MacroAssemblerARM::absDouble):
        (JSC::MacroAssemblerARM::negateDouble):
        (JSC::MacroAssemblerARM::convertInt32ToDouble):
        (JSC::MacroAssemblerARM::convertFloatToDouble):
        (JSC::MacroAssemblerARM::convertDoubleToFloat):
        (JSC::MacroAssemblerARM::branchDouble):
        (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32):
        (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32):
        (JSC::MacroAssemblerARM::truncateDoubleToInt32):
        (JSC::MacroAssemblerARM::truncateDoubleToUint32):
        (JSC::MacroAssemblerARM::branchConvertDoubleToInt32):
        (JSC::MacroAssemblerARM::branchDoubleNonZero):
        (JSC::MacroAssemblerARM::branchDoubleZeroOrNaN):

2012-08-13  Simon Hausmann  <simon.hausmann@nokia.com>

        Unreviewed, rolling out r125444.
        http://trac.webkit.org/changeset/125444
        https://bugs.webkit.org/show_bug.cgi?id=93872

        Broke some tests

        * Target.pri:

2012-08-13  Simon Hausmann  <simon.hausmann@nokia.com>

        [Qt] Replace use of internal Weak smart pointer with JSWeakObjectMap
        https://bugs.webkit.org/show_bug.cgi?id=93872

        Reviewed by Kenneth Rohde Christiansen.

        * Target.pri: Add missing JSWeakObjectMap file to build.

2012-08-13  Raphael Kubo da Costa  <rakuco@webkit.org>

        [CMake] Remove glib-related Find modules and write single new one instead.
        https://bugs.webkit.org/show_bug.cgi?id=93786

        Reviewed by Rob Buis.

        * shell/PlatformEfl.cmake: Use GLIB_* instead of Glib_*.

2012-08-12  Allan Sandfeld Jensen  <allan.jensen@nokia.com>

        Doesn't build with ENABLE_JIT=0
        https://bugs.webkit.org/show_bug.cgi?id=85042

        Reviewed by Eric Seidel.

        Include headers without which CallFrame.h does not build, and
        fix gcc warning about comparing unsigned int with 0.

        * dfg/DFGDriver.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::isOpcode):

2012-08-10  Yong Li  <yoli@rim.com>

        [BlackBerry] GCActivityCallback should always schedule GC even allocated bytes is a small number
        https://bugs.webkit.org/show_bug.cgi?id=93650

        Reviewed by Rob Buis.

        Even a small number of allocated JS objects could hold expensive resources.

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

2012-08-09  Yong Li  <yoli@rim.com>

        [QNX] Implement getCPUTime() for OS(QNX)
        https://bugs.webkit.org/show_bug.cgi?id=93516

        Reviewed by George Staikos.

        Implement getCPUTime() with CLOCK_THREAD_CPUTIME_ID so it will tell
        exactly how long the current thread has spent without being impacted
        by other things.

        * runtime/TimeoutChecker.cpp:
        (JSC::getCPUTime):

2012-08-08  Shane Stephens  <shanestephens@google.com>

        Compile flag for CSS Hierarchies
        https://bugs.webkit.org/show_bug.cgi?id=92433

        Reviewed by Tony Chang.

        * Configurations/FeatureDefines.xcconfig:

2012-08-08  Benjamin Poulain  <bpoulain@apple.com>

        Use char* instead of LChar* for the public interface of String construction from literals
        https://bugs.webkit.org/show_bug.cgi?id=93402

        Reviewed by Michael Saboff.

        Update JSC' Identifier to use StringImpl::createFromLiteral with a char*.

        * runtime/Identifier.cpp:
        (JSC::IdentifierASCIIStringTranslator::translate):

2012-08-08  Patrick Gansterer  <paroga@webkit.org>

        Remove ce_time.(cpp|h) from list of source files
        https://bugs.webkit.org/show_bug.cgi?id=93446

        Reviewed by Simon Hausmann.

        r125004 removed the last dependency on functions defined in ce_time.cpp.

        * Target.pri:

2012-08-08  Patrick Gansterer  <paroga@webkit.org>

        [WIN] Use GetTimeZoneInformation() for getting the timezone name
        https://bugs.webkit.org/show_bug.cgi?id=91936

        Reviewed by Ryosuke Niwa.

        The MS CRT implementation of strftime calls the same functions in the background.
        Using them directly avoids the overhead of parsing the format string and removes
        the dependency on strftime() for WinCE where this function does not exist.

        * runtime/DateConversion.cpp:
        (JSC::formatTime):

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

        Refactor magic numbers in the ARM port of DFG-JIT
        https://bugs.webkit.org/show_bug.cgi?id=93348

        Reviewed by Eric Seidel.

        Introduce new names for hard-coded magic numbers.
        Refactor constant with confusing names to more descriptive ones.

        * assembler/ARMAssembler.cpp:
        (JSC::ARMAssembler::patchConstantPoolLoad):
        (JSC::ARMAssembler::getOp2):
        (JSC::ARMAssembler::genInt):
        (JSC::ARMAssembler::getImm):
        (JSC::ARMAssembler::moveImm):
        (JSC::ARMAssembler::encodeComplexImm):
        (JSC::ARMAssembler::dataTransfer32):
        (JSC::ARMAssembler::dataTransfer16):
        (JSC::ARMAssembler::dataTransferFloat):
        (JSC::ARMAssembler::executableCopy):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::emitInstruction):
        (JSC::ARMAssembler::ands_r):
        (JSC::ARMAssembler::eors_r):
        (JSC::ARMAssembler::subs_r):
        (JSC::ARMAssembler::rsbs_r):
        (JSC::ARMAssembler::adds_r):
        (JSC::ARMAssembler::adcs_r):
        (JSC::ARMAssembler::sbcs_r):
        (JSC::ARMAssembler::rscs_r):
        (JSC::ARMAssembler::tst_r):
        (JSC::ARMAssembler::teq_r):
        (JSC::ARMAssembler::cmp_r):
        (JSC::ARMAssembler::cmn_r):
        (JSC::ARMAssembler::orrs_r):
        (JSC::ARMAssembler::movs_r):
        (JSC::ARMAssembler::bics_r):
        (JSC::ARMAssembler::mvns_r):
        (JSC::ARMAssembler::muls_r):
        (JSC::ARMAssembler::ldr_imm):
        (JSC::ARMAssembler::ldr_un_imm):
        (JSC::ARMAssembler::dtr_u):
        (JSC::ARMAssembler::dtr_ur):
        (JSC::ARMAssembler::dtr_dr):
        (JSC::ARMAssembler::dtrh_u):
        (JSC::ARMAssembler::dtrh_ur):
        (JSC::ARMAssembler::fdtr_u):
        (JSC::ARMAssembler::push_r):
        (JSC::ARMAssembler::pop_r):
        (JSC::ARMAssembler::getLdrImmAddress):
        (JSC::ARMAssembler::getLdrImmAddressOnPool):
        (JSC::ARMAssembler::patchConstantPoolLoad):
        (JSC::ARMAssembler::repatchCompact):
        (JSC::ARMAssembler::replaceWithJump):
        (JSC::ARMAssembler::replaceWithLoad):
        (JSC::ARMAssembler::replaceWithAddressComputation):
        (JSC::ARMAssembler::getOp2Byte):
        (JSC::ARMAssembler::getOp2Half):
        (JSC::ARMAssembler::getImm16Op2):
        (JSC::ARMAssembler::placeConstantPoolBarrier):
        (JSC::ARMAssembler::getConditionalField):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::and32):
        (JSC::MacroAssemblerARM::branch32):
        (JSC::MacroAssemblerARM::branchTest32):
        (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32):

2012-08-07  Benjamin Poulain  <benjamin@webkit.org>

        Use the initialization from literal for JSC's Identifiers
        https://bugs.webkit.org/show_bug.cgi?id=93193

        Reviewed by Geoffrey Garen.

        This patches modify Identifier ot take advantage of the new initialization from literal.

        In addition to the memory savings (~600bytes per instance), this gives us a 2% speed
        improvement on CommonIdentifiers on average.

        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers):
        Null and empty strings are forbidden for literal initialization. Use the most efficient constructors
        instead of a literal.

        * runtime/Identifier.cpp:
        (IdentifierASCIIStringTranslator):
        Rename IdentifierCStringTranslator to IdentifierASCIIStringTranslator to make the text encoding
        explicit.
        (JSC::IdentifierASCIIStringTranslator::hash):
        (JSC::IdentifierASCIIStringTranslator::equal):
        (JSC::IdentifierASCIIStringTranslator::translate): Use the fast initialization from literal.
        (JSC::Identifier::add):
        * runtime/Identifier.h:
        (JSC::Identifier::Identifier):

2012-08-07  Simon Hausmann  <simon.hausmann@nokia.com>

        [Qt][Win] Remove pthreads linkage

        Reviewed by Csaba Osztrogonác.

        After r124823 linkage to pthreads is not needed anymore for the Windows
        build.

        * JavaScriptCore.pri:

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

        Refactor emit*Inst functions and introduce toARMWord functions in DFG-JIT's traditional ARM port
        https://bugs.webkit.org/show_bug.cgi?id=93266

        Reviewed by Csaba Osztrogonác.

        First part of a bigger refactoring issue trying to make traditional
        ARM DFG-JIT port easier to read and understand.


        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::emitInstruction):
        (JSC::ARMAssembler::emitDoublePrecisionInstruction):
        (JSC::ARMAssembler::emitSinglePrecisionInstruction):
        (JSC::ARMAssembler::and_r):
        (JSC::ARMAssembler::ands_r):
        (JSC::ARMAssembler::eor_r):
        (JSC::ARMAssembler::eors_r):
        (JSC::ARMAssembler::sub_r):
        (JSC::ARMAssembler::subs_r):
        (JSC::ARMAssembler::rsb_r):
        (JSC::ARMAssembler::rsbs_r):
        (JSC::ARMAssembler::add_r):
        (JSC::ARMAssembler::adds_r):
        (JSC::ARMAssembler::adc_r):
        (JSC::ARMAssembler::adcs_r):
        (JSC::ARMAssembler::sbc_r):
        (JSC::ARMAssembler::sbcs_r):
        (JSC::ARMAssembler::rsc_r):
        (JSC::ARMAssembler::rscs_r):
        (JSC::ARMAssembler::tst_r):
        (JSC::ARMAssembler::teq_r):
        (JSC::ARMAssembler::cmp_r):
        (JSC::ARMAssembler::cmn_r):
        (JSC::ARMAssembler::orr_r):
        (JSC::ARMAssembler::orrs_r):
        (JSC::ARMAssembler::mov_r):
        (JSC::ARMAssembler::movw_r):
        (JSC::ARMAssembler::movt_r):
        (JSC::ARMAssembler::movs_r):
        (JSC::ARMAssembler::bic_r):
        (JSC::ARMAssembler::bics_r):
        (JSC::ARMAssembler::mvn_r):
        (JSC::ARMAssembler::mvns_r):
        (JSC::ARMAssembler::mul_r):
        (JSC::ARMAssembler::muls_r):
        (JSC::ARMAssembler::mull_r):
        (JSC::ARMAssembler::vmov_f64_r):
        (JSC::ARMAssembler::vadd_f64_r):
        (JSC::ARMAssembler::vdiv_f64_r):
        (JSC::ARMAssembler::vsub_f64_r):
        (JSC::ARMAssembler::vmul_f64_r):
        (JSC::ARMAssembler::vcmp_f64_r):
        (JSC::ARMAssembler::vsqrt_f64_r):
        (JSC::ARMAssembler::vabs_f64_r):
        (JSC::ARMAssembler::vneg_f64_r):
        (JSC::ARMAssembler::ldr_imm):
        (JSC::ARMAssembler::ldr_un_imm):
        (JSC::ARMAssembler::dtr_u):
        (JSC::ARMAssembler::dtr_ur):
        (JSC::ARMAssembler::dtr_d):
        (JSC::ARMAssembler::dtr_dr):
        (JSC::ARMAssembler::dtrh_u):
        (JSC::ARMAssembler::dtrh_ur):
        (JSC::ARMAssembler::dtrh_d):
        (JSC::ARMAssembler::dtrh_dr):
        (JSC::ARMAssembler::fdtr_u):
        (JSC::ARMAssembler::fdtr_d):
        (JSC::ARMAssembler::push_r):
        (JSC::ARMAssembler::pop_r):
        (JSC::ARMAssembler::vmov_vfp64_r):
        (JSC::ARMAssembler::vmov_arm64_r):
        (JSC::ARMAssembler::vmov_vfp32_r):
        (JSC::ARMAssembler::vmov_arm32_r):
        (JSC::ARMAssembler::vcvt_f64_s32_r):
        (JSC::ARMAssembler::vcvt_s32_f64_r):
        (JSC::ARMAssembler::vcvt_u32_f64_r):
        (JSC::ARMAssembler::vcvt_f64_f32_r):
        (JSC::ARMAssembler::vcvt_f32_f64_r):
        (JSC::ARMAssembler::vmrs_apsr):
        (JSC::ARMAssembler::clz_r):
        (JSC::ARMAssembler::bx):
        (JSC::ARMAssembler::blx):
        (JSC::ARMAssembler::linkJump):
        (JSC::ARMAssembler::toARMWord):
        (ARMAssembler):

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

        [WIN] Remove dependency on pthread from MachineStackMarker
        https://bugs.webkit.org/show_bug.cgi?id=68429

        Reviewed by Geoffrey Garen.

        Windows has no support for calling a destructor for thread specific data.
        Since we need more control over creating and deleting thread specific keys
        we can not simply extend WTF::ThreadSpecific with this functionality.

        All thread specific keys created via the new API get stored in a list.
        After a thread function finished we iterate over this list and call
        the registered destructor for every item if needed.

        * heap/MachineStackMarker.cpp:  Use the new functions instead of pthread directly.
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::makeUsableFromMultipleThreads):
        (JSC::MachineThreads::addCurrentThread):
        * heap/MachineStackMarker.h:
        (MachineThreads):

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

        Unify JSC date and time formating functions
        https://bugs.webkit.org/show_bug.cgi?id=92282

        Reviewed by Geoffrey Garen.

        Replace the existing functions for formating GregorianDateTime
        with one single function. This removes some code duplications
        in DatePrototype and is a preperation to fix encoding issues,
        since we can add UChar* values to the resulting string now.

        * runtime/DateConstructor.cpp:
        (JSC::callDate):
        * runtime/DateConversion.cpp:
        (JSC::formatDateTime):
        * runtime/DateConversion.h:
        (JSC):
        * runtime/DatePrototype.cpp:
        (JSC::formateDateInstance):
        (JSC::dateProtoFuncToString):
        (JSC::dateProtoFuncToUTCString):
        (JSC::dateProtoFuncToDateString):
        (JSC::dateProtoFuncToTimeString):
        (JSC::dateProtoFuncToGMTString):

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

        Unreviewed. Fix make distcheck.

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

2012-08-05  Peter Wang  <peter.wang@torchmobile.com.cn>

        Web Inspector: [JSC] implement setting breakpoints by line:column
        https://bugs.webkit.org/show_bug.cgi?id=53003

        Reviewed by Geoffrey Garen.

        Add a counter to Lexer to record the column info of each Token. Add a column parameter to
        op_debug, cti_op_debug, and _llint_op_debug byte-code command.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::emitDebugHook):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::toArgumentList):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::ConstStatementNode::emitBytecode):
        (JSC::EmptyStatementNode::emitBytecode):
        (JSC::DebuggerStatementNode::emitBytecode):
        (JSC::ExprStatementNode::emitBytecode):
        (JSC::VarStatementNode::emitBytecode):
        (JSC::IfNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::EvalNode::emitBytecode):
        (JSC::FunctionBodyNode::emitBytecode):
        * debugger/Debugger.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::debug):
        (JSC::Interpreter::privateExecute):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (ASTBuilder):
        (JSC::ASTBuilder::createCommaExpr):
        (JSC::ASTBuilder::createLogicalNot):
        (JSC::ASTBuilder::createUnaryPlus):
        (JSC::ASTBuilder::createVoid):
        (JSC::ASTBuilder::thisExpr):
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::createObjectLiteral):
        (JSC::ASTBuilder::createArray):
        (JSC::ASTBuilder::createNumberExpr):
        (JSC::ASTBuilder::createString):
        (JSC::ASTBuilder::createBoolean):
        (JSC::ASTBuilder::createNull):
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::createRegExp):
        (JSC::ASTBuilder::createNewExpr):
        (JSC::ASTBuilder::createConditionalExpr):
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArgumentsList):
        (JSC::ASTBuilder::createPropertyList):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createIfStatement):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createEmptyStatement):
        (JSC::ASTBuilder::createVarStatement):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::createWhileStatement):
        (JSC::ASTBuilder::createDoWhileStatement):
        (JSC::ASTBuilder::createLabelStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::createDebugger):
        (JSC::ASTBuilder::createConstStatement):
        (JSC::ASTBuilder::appendConstDecl):
        (JSC::ASTBuilder::combineCommaNodes):
        (JSC::ASTBuilder::appendBinaryOperation):
        (JSC::ASTBuilder::createAssignment):
        (JSC::ASTBuilder::createNumber):
        (JSC::ASTBuilder::makeTypeOfNode):
        (JSC::ASTBuilder::makeDeleteNode):
        (JSC::ASTBuilder::makeNegateNode):
        (JSC::ASTBuilder::makeBitwiseNotNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeAddNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeLeftShiftNode):
        (JSC::ASTBuilder::makeRightShiftNode):
        (JSC::ASTBuilder::makeURightShiftNode):
        (JSC::ASTBuilder::makeBitOrNode):
        (JSC::ASTBuilder::makeBitAndNode):
        (JSC::ASTBuilder::makeBitXOrNode):
        (JSC::ASTBuilder::makeFunctionCallNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):
        * parser/Lexer.cpp:
        (JSC::::setCode):
        (JSC::::internalShift):
        (JSC::::shift):
        (JSC::::lex):
        * parser/Lexer.h:
        (Lexer):
        (JSC::Lexer::currentColumnNumber):
        (JSC::::lexExpectIdentifier):
        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        (JSC::ExpressionNode::ExpressionNode):
        (JSC::StatementNode::StatementNode):
        (JSC::NullNode::NullNode):
        (JSC::BooleanNode::BooleanNode):
        (JSC::NumberNode::NumberNode):
        (JSC::StringNode::StringNode):
        (JSC::RegExpNode::RegExpNode):
        (JSC::ThisNode::ThisNode):
        (JSC::ResolveNode::ResolveNode):
        (JSC::ArrayNode::ArrayNode):
        (JSC::PropertyListNode::PropertyListNode):
        (JSC::ObjectLiteralNode::ObjectLiteralNode):
        (JSC::BracketAccessorNode::BracketAccessorNode):
        (JSC::DotAccessorNode::DotAccessorNode):
        (JSC::ArgumentListNode::ArgumentListNode):
        (JSC::NewExprNode::NewExprNode):
        (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
        (JSC::FunctionCallValueNode::FunctionCallValueNode):
        (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
        (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
        (JSC::FunctionCallDotNode::FunctionCallDotNode):
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        (JSC::PrePostResolveNode::PrePostResolveNode):
        (JSC::PostfixResolveNode::PostfixResolveNode):
        (JSC::PostfixBracketNode::PostfixBracketNode):
        (JSC::PostfixDotNode::PostfixDotNode):
        (JSC::PostfixErrorNode::PostfixErrorNode):
        (JSC::DeleteResolveNode::DeleteResolveNode):
        (JSC::DeleteBracketNode::DeleteBracketNode):
        (JSC::DeleteDotNode::DeleteDotNode):
        (JSC::DeleteValueNode::DeleteValueNode):
        (JSC::VoidNode::VoidNode):
        (JSC::TypeOfResolveNode::TypeOfResolveNode):
        (JSC::TypeOfValueNode::TypeOfValueNode):
        (JSC::PrefixResolveNode::PrefixResolveNode):
        (JSC::PrefixBracketNode::PrefixBracketNode):
        (JSC::PrefixDotNode::PrefixDotNode):
        (JSC::PrefixErrorNode::PrefixErrorNode):
        (JSC::UnaryOpNode::UnaryOpNode):
        (JSC::UnaryPlusNode::UnaryPlusNode):
        (JSC::NegateNode::NegateNode):
        (JSC::BitwiseNotNode::BitwiseNotNode):
        (JSC::LogicalNotNode::LogicalNotNode):
        (JSC::BinaryOpNode::BinaryOpNode):
        (JSC::MultNode::MultNode):
        (JSC::DivNode::DivNode):
        (JSC::ModNode::ModNode):
        (JSC::AddNode::AddNode):
        (JSC::SubNode::SubNode):
        (JSC::LeftShiftNode::LeftShiftNode):
        (JSC::RightShiftNode::RightShiftNode):
        (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode):
        (JSC::LessNode::LessNode):
        (JSC::GreaterNode::GreaterNode):
        (JSC::LessEqNode::LessEqNode):
        (JSC::GreaterEqNode::GreaterEqNode):
        (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode):
        (JSC::InstanceOfNode::InstanceOfNode):
        (JSC::InNode::InNode):
        (JSC::EqualNode::EqualNode):
        (JSC::NotEqualNode::NotEqualNode):
        (JSC::StrictEqualNode::StrictEqualNode):
        (JSC::NotStrictEqualNode::NotStrictEqualNode):
        (JSC::BitAndNode::BitAndNode):
        (JSC::BitOrNode::BitOrNode):
        (JSC::BitXOrNode::BitXOrNode):
        (JSC::LogicalOpNode::LogicalOpNode):
        (JSC::ConditionalNode::ConditionalNode):
        (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
        (JSC::AssignResolveNode::AssignResolveNode):
        (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
        (JSC::AssignBracketNode::AssignBracketNode):
        (JSC::AssignDotNode::AssignDotNode):
        (JSC::ReadModifyDotNode::ReadModifyDotNode):
        (JSC::AssignErrorNode::AssignErrorNode):
        (JSC::CommaNode::CommaNode):
        (JSC::ConstStatementNode::ConstStatementNode):
        (JSC::EmptyStatementNode::EmptyStatementNode):
        (JSC::DebuggerStatementNode::DebuggerStatementNode):
        (JSC::ExprStatementNode::ExprStatementNode):
        (JSC::VarStatementNode::VarStatementNode):
        (JSC::IfNode::IfNode):
        (JSC::IfElseNode::IfElseNode):
        (JSC::DoWhileNode::DoWhileNode):
        (JSC::WhileNode::WhileNode):
        (JSC::ForNode::ForNode):
        (JSC::ContinueNode::ContinueNode):
        (JSC::BreakNode::BreakNode):
        (JSC::ReturnNode::ReturnNode):
        (JSC::WithNode::WithNode):
        (JSC::LabelNode::LabelNode):
        (JSC::ThrowNode::ThrowNode):
        (JSC::TryNode::TryNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::SwitchNode::SwitchNode):
        (JSC::ConstDeclNode::ConstDeclNode):
        (JSC::BlockNode::BlockNode):
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.cpp:
        (JSC::StatementNode::setLoc):
        (JSC):
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ProgramNode::create):
        (JSC::EvalNode::EvalNode):
        (JSC::EvalNode::create):
        (JSC::FunctionBodyNode::FunctionBodyNode):
        (JSC::FunctionBodyNode::create):
        * parser/Nodes.h:
        (Node):
        (JSC::Node::columnNo):
        (ExpressionNode):
        (StatementNode):
        (JSC::StatementNode::column):
        (NullNode):
        (BooleanNode):
        (NumberNode):
        (StringNode):
        (RegExpNode):
        (ThisNode):
        (ResolveNode):
        (ArrayNode):
        (PropertyListNode):
        (ObjectLiteralNode):
        (BracketAccessorNode):
        (DotAccessorNode):
        (ArgumentListNode):
        (NewExprNode):
        (EvalFunctionCallNode):
        (FunctionCallValueNode):
        (FunctionCallResolveNode):
        (FunctionCallBracketNode):
        (FunctionCallDotNode):
        (CallFunctionCallDotNode):
        (ApplyFunctionCallDotNode):
        (PrePostResolveNode):
        (PostfixResolveNode):
        (PostfixBracketNode):
        (PostfixDotNode):
        (PostfixErrorNode):
        (DeleteResolveNode):
        (DeleteBracketNode):
        (DeleteDotNode):
        (DeleteValueNode):
        (VoidNode):
        (TypeOfResolveNode):
        (TypeOfValueNode):
        (PrefixResolveNode):
        (PrefixBracketNode):
        (PrefixDotNode):
        (PrefixErrorNode):
        (UnaryOpNode):
        (UnaryPlusNode):
        (NegateNode):
        (BitwiseNotNode):
        (LogicalNotNode):
        (BinaryOpNode):
        (MultNode):
        (DivNode):
        (ModNode):
        (AddNode):
        (SubNode):
        (LeftShiftNode):
        (RightShiftNode):
        (UnsignedRightShiftNode):
        (LessNode):
        (GreaterNode):
        (LessEqNode):
        (GreaterEqNode):
        (ThrowableBinaryOpNode):
        (InstanceOfNode):
        (InNode):
        (EqualNode):
        (NotEqualNode):
        (StrictEqualNode):
        (NotStrictEqualNode):
        (BitAndNode):
        (BitOrNode):
        (BitXOrNode):
        (LogicalOpNode):
        (ConditionalNode):
        (ReadModifyResolveNode):
        (AssignResolveNode):
        (ReadModifyBracketNode):
        (AssignBracketNode):
        (AssignDotNode):
        (ReadModifyDotNode):
        (AssignErrorNode):
        (CommaNode):
        (ConstDeclNode):
        (ConstStatementNode):
        (BlockNode):
        (EmptyStatementNode):
        (DebuggerStatementNode):
        (ExprStatementNode):
        (VarStatementNode):
        (IfNode):
        (IfElseNode):
        (DoWhileNode):
        (WhileNode):
        (ForNode):
        (ForInNode):
        (ContinueNode):
        (BreakNode):
        (ReturnNode):
        (WithNode):
        (LabelNode):
        (ThrowNode):
        (TryNode):
        (ScopeNode):
        (ProgramNode):
        (EvalNode):
        (FunctionBodyNode):
        (FuncExprNode):
        (FuncDeclNode):
        (SwitchNode):
        * parser/Parser.cpp:
        (JSC::::parseSourceElements):
        (JSC::::parseVarDeclaration):
        (JSC::::parseConstDeclaration):
        (JSC::::parseDoWhileStatement):
        (JSC::::parseWhileStatement):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseConstDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseBreakStatement):
        (JSC::::parseContinueStatement):
        (JSC::::parseReturnStatement):
        (JSC::::parseThrowStatement):
        (JSC::::parseWithStatement):
        (JSC::::parseSwitchStatement):
        (JSC::::parseTryStatement):
        (JSC::::parseDebuggerStatement):
        (JSC::::parseBlockStatement):
        (JSC::::parseStatement):
        (JSC::::parseFunctionBody):
        (JSC::::parseFunctionInfo):
        (JSC::::parseFunctionDeclaration):
        (JSC::::parseExpressionOrLabelStatement):
        (JSC::::parseExpressionStatement):
        (JSC::::parseIfStatement):
        (JSC::::parseExpression):
        (JSC::::parseAssignmentExpression):
        (JSC::::parseConditionalExpression):
        (JSC::::parseBinaryExpression):
        (JSC::::parseProperty):
        (JSC::::parseObjectLiteral):
        (JSC::::parseStrictObjectLiteral):
        (JSC::::parseArrayLiteral):
        (JSC::::parsePrimaryExpression):
        (JSC::::parseArguments):
        (JSC::::parseMemberExpression):
        (JSC::::parseUnaryExpression):
        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        (JSC::Parser::tokenStart):
        (JSC::Parser::tokenLine):
        (JSC::Parser::tokenEnd):
        (JSC::Parser::tokenLocation):
        (Parser):
        (JSC::Parser::getTokenName):
        (JSC::::parse):
        * parser/ParserTokens.h:
        (JSC::JSTokenLocation::JSTokenLocation):
        (JSTokenLocation):
        (JSToken):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::closeBraceToken):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):
        (JSC::SyntaxChecker::createCommaExpr):
        (JSC::SyntaxChecker::makeAssignNode):
        (JSC::SyntaxChecker::makePrefixNode):
        (JSC::SyntaxChecker::makePostfixNode):
        (JSC::SyntaxChecker::makeTypeOfNode):
        (JSC::SyntaxChecker::makeDeleteNode):
        (JSC::SyntaxChecker::makeNegateNode):
        (JSC::SyntaxChecker::makeBitwiseNotNode):
        (JSC::SyntaxChecker::createLogicalNot):
        (JSC::SyntaxChecker::createUnaryPlus):
        (JSC::SyntaxChecker::createVoid):
        (JSC::SyntaxChecker::thisExpr):
        (JSC::SyntaxChecker::createResolve):
        (JSC::SyntaxChecker::createObjectLiteral):
        (JSC::SyntaxChecker::createArray):
        (JSC::SyntaxChecker::createNumberExpr):
        (JSC::SyntaxChecker::createString):
        (JSC::SyntaxChecker::createBoolean):
        (JSC::SyntaxChecker::createNull):
        (JSC::SyntaxChecker::createBracketAccess):
        (JSC::SyntaxChecker::createDotAccess):
        (JSC::SyntaxChecker::createRegExp):
        (JSC::SyntaxChecker::createNewExpr):
        (JSC::SyntaxChecker::createConditionalExpr):
        (JSC::SyntaxChecker::createAssignResolve):
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createArgumentsList):
        (JSC::SyntaxChecker::createPropertyList):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createBlockStatement):
        (JSC::SyntaxChecker::createExprStatement):
        (JSC::SyntaxChecker::createIfStatement):
        (JSC::SyntaxChecker::createForLoop):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::createEmptyStatement):
        (JSC::SyntaxChecker::createVarStatement):
        (JSC::SyntaxChecker::createReturnStatement):
        (JSC::SyntaxChecker::createBreakStatement):
        (JSC::SyntaxChecker::createContinueStatement):
        (JSC::SyntaxChecker::createTryStatement):
        (JSC::SyntaxChecker::createSwitchStatement):
        (JSC::SyntaxChecker::createWhileStatement):
        (JSC::SyntaxChecker::createWithStatement):
        (JSC::SyntaxChecker::createDoWhileStatement):
        (JSC::SyntaxChecker::createLabelStatement):
        (JSC::SyntaxChecker::createThrowStatement):
        (JSC::SyntaxChecker::createDebugger):
        (JSC::SyntaxChecker::createConstStatement):
        (JSC::SyntaxChecker::appendConstDecl):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):
        (JSC::SyntaxChecker::combineCommaNodes):
        (JSC::SyntaxChecker::operatorStackPop):

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

        Crashes in dfgBuildPutByIdList when clicking on just about anything on Google Maps
        https://bugs.webkit.org/show_bug.cgi?id=92691

        Reviewed by Mark Hahnenberg.

        The state of the stubs was changing after we determined the type (by virtue of the slow path
        function that was called), since the get or put (in this case put) could cause arbitrary
        side effects. Perhaps a full-blown fix would be to eliminate our reliance of the slow path
        function to determine what to do, but an easier fix for now is to have the slow path give up
        if its assumptions were invalidated by a side effect.

        * dfg/DFGOperations.cpp:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):

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

        DFG handling of get_by_id should always inject a ForceOSRExit node if there is no prediction
        https://bugs.webkit.org/show_bug.cgi?id=93162

        Reviewed by Mark Hahnenberg.

        This simplifies the DFG IR by ensuring that all nodes that use value profiles will be preceded
        by a ForceOSRExit if the value profile had no data.

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

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

        DFG::StructureCheckHoistingPhase keeps a Node& around for too long
        https://bugs.webkit.org/show_bug.cgi?id=93157

        Reviewed by Mark Hahnenberg.

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

2012-08-02  Patrick Gansterer  <paroga@webkit.org>

        Move getLocalTime() as static inline function to DateMath
        https://bugs.webkit.org/show_bug.cgi?id=92955

        Reviewed by Ryosuke Niwa.

        getCurrentLocalTime() and getLocalTime() has been superseded with the
        GregorianDateTime class. So we can move it into DateMath.cpp as an static inline
        function. This allows us to remove the dependecy on time() and localtime()
        for Windows CE, where this functions require the ce_time library to work.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        ASSERTION FAILED: at(m_compileIndex).canExit() || m_isCheckingArgumentTypes
        https://bugs.webkit.org/show_bug.cgi?id=91074

        Reviewed by Mark Hahnenberg.

        Fixes a bug where the speculative JIT was performing an unnecessary speculation that the
        CFA had proven shouldn't be performed, leading to asserts that a node should not have
        exit sites. This is a debug-only assert with no release symptom - we were just emitting
        a check that was not reachable.
        
        Also found, and fixed, a bug where structure check hoisting was slightly confusing the
        CFA by inserting GetLocal's into the graph. CSE would clean the GetLocal's up, which
        would make the backend happy - but the CFA would produce subtly wrong results.

        * bytecode/SpeculatedType.h:
        (JSC::isOtherOrEmptySpeculation):
        (JSC):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):

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

        Unreviewed, build fix for DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE).

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

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

        Remove all uses of ClassInfo for JSStrings in JIT code
        https://bugs.webkit.org/show_bug.cgi?id=92935

        Reviewed by Geoffrey Garen.

        This is the first step in removing our dependence on in-object ClassInfo pointers
        in JIT code. Most of the changes are to check the Structure, which is unique for 
        JSString primitives.

        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromClassInfo):
        (JSC::speculationFromStructure): Changed to check the TypeInfo in the Structure
        since there wasn't a JSGlobalData immediately available to grab the JSString 
        Structure out of.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitLoadCharacterString):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileCTIMachineTrampolines):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_convert_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTIMachineTrampolines):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_convert_this):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        (JSC::JIT::emitSlow_op_get_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        (JSC::JIT::emitSlow_op_get_by_val):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadJSStringArgument):
        * jit/ThunkGenerators.cpp:
        (JSC::stringCharLoad):
        (JSC::charCodeAtThunkGenerator):
        (JSC::charAtThunkGenerator):

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

        Unreviewed, missed a style goof in the previous patch: "NodeIndex nodeIndex"
        in a method signature is painfully redundant.

        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):

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

        DFGSpeculativeJIT.h has too many inline method bodies
        https://bugs.webkit.org/show_bug.cgi?id=92957

        Reviewed by Antti Koivisto.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculationCheck):
        (DFG):
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::speculationCheckWithConditionalDirection):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):

2012-08-01  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r124406.
        http://trac.webkit.org/changeset/124406
        https://bugs.webkit.org/show_bug.cgi?id=92951

        it set the Mac bots on fire (Requested by pizlo on #webkit).

        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDebugHook):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::toArgumentList):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::ConditionalNode::emitBytecode):
        (JSC::ConstStatementNode::emitBytecode):
        (JSC::EmptyStatementNode::emitBytecode):
        (JSC::DebuggerStatementNode::emitBytecode):
        (JSC::ExprStatementNode::emitBytecode):
        (JSC::VarStatementNode::emitBytecode):
        (JSC::IfNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::EvalNode::emitBytecode):
        (JSC::FunctionBodyNode::emitBytecode):
        * debugger/Debugger.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::debug):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/ASTBuilder.h:
        (ASTBuilder):
        (JSC::ASTBuilder::createCommaExpr):
        (JSC::ASTBuilder::createLogicalNot):
        (JSC::ASTBuilder::createUnaryPlus):
        (JSC::ASTBuilder::createVoid):
        (JSC::ASTBuilder::thisExpr):
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::createObjectLiteral):
        (JSC::ASTBuilder::createArray):
        (JSC::ASTBuilder::createNumberExpr):
        (JSC::ASTBuilder::createString):
        (JSC::ASTBuilder::createBoolean):
        (JSC::ASTBuilder::createNull):
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::createRegExp):
        (JSC::ASTBuilder::createNewExpr):
        (JSC::ASTBuilder::createConditionalExpr):
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArgumentsList):
        (JSC::ASTBuilder::createPropertyList):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createIfStatement):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createEmptyStatement):
        (JSC::ASTBuilder::createVarStatement):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::createWhileStatement):
        (JSC::ASTBuilder::createDoWhileStatement):
        (JSC::ASTBuilder::createLabelStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::createDebugger):
        (JSC::ASTBuilder::createConstStatement):
        (JSC::ASTBuilder::appendConstDecl):
        (JSC::ASTBuilder::combineCommaNodes):
        (JSC::ASTBuilder::appendBinaryOperation):
        (JSC::ASTBuilder::createAssignment):
        (JSC::ASTBuilder::createNumber):
        (JSC::ASTBuilder::makeTypeOfNode):
        (JSC::ASTBuilder::makeDeleteNode):
        (JSC::ASTBuilder::makeNegateNode):
        (JSC::ASTBuilder::makeBitwiseNotNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeAddNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeLeftShiftNode):
        (JSC::ASTBuilder::makeRightShiftNode):
        (JSC::ASTBuilder::makeURightShiftNode):
        (JSC::ASTBuilder::makeBitOrNode):
        (JSC::ASTBuilder::makeBitAndNode):
        (JSC::ASTBuilder::makeBitXOrNode):
        (JSC::ASTBuilder::makeFunctionCallNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):
        * parser/Lexer.cpp:
        (JSC::::setCode):
        (JSC::::internalShift):
        (JSC::::shift):
        (JSC::::lex):
        * parser/Lexer.h:
        (Lexer):
        (JSC::::lexExpectIdentifier):
        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        (JSC::ExpressionNode::ExpressionNode):
        (JSC::StatementNode::StatementNode):
        (JSC::NullNode::NullNode):
        (JSC::BooleanNode::BooleanNode):
        (JSC::NumberNode::NumberNode):
        (JSC::StringNode::StringNode):
        (JSC::RegExpNode::RegExpNode):
        (JSC::ThisNode::ThisNode):
        (JSC::ResolveNode::ResolveNode):
        (JSC::ArrayNode::ArrayNode):
        (JSC::PropertyListNode::PropertyListNode):
        (JSC::ObjectLiteralNode::ObjectLiteralNode):
        (JSC::BracketAccessorNode::BracketAccessorNode):
        (JSC::DotAccessorNode::DotAccessorNode):
        (JSC::ArgumentListNode::ArgumentListNode):
        (JSC::NewExprNode::NewExprNode):
        (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
        (JSC::FunctionCallValueNode::FunctionCallValueNode):
        (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
        (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
        (JSC::FunctionCallDotNode::FunctionCallDotNode):
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        (JSC::PrePostResolveNode::PrePostResolveNode):
        (JSC::PostfixResolveNode::PostfixResolveNode):
        (JSC::PostfixBracketNode::PostfixBracketNode):
        (JSC::PostfixDotNode::PostfixDotNode):
        (JSC::PostfixErrorNode::PostfixErrorNode):
        (JSC::DeleteResolveNode::DeleteResolveNode):
        (JSC::DeleteBracketNode::DeleteBracketNode):
        (JSC::DeleteDotNode::DeleteDotNode):
        (JSC::DeleteValueNode::DeleteValueNode):
        (JSC::VoidNode::VoidNode):
        (JSC::TypeOfResolveNode::TypeOfResolveNode):
        (JSC::TypeOfValueNode::TypeOfValueNode):
        (JSC::PrefixResolveNode::PrefixResolveNode):
        (JSC::PrefixBracketNode::PrefixBracketNode):
        (JSC::PrefixDotNode::PrefixDotNode):
        (JSC::PrefixErrorNode::PrefixErrorNode):
        (JSC::UnaryOpNode::UnaryOpNode):
        (JSC::UnaryPlusNode::UnaryPlusNode):
        (JSC::NegateNode::NegateNode):
        (JSC::BitwiseNotNode::BitwiseNotNode):
        (JSC::LogicalNotNode::LogicalNotNode):
        (JSC::BinaryOpNode::BinaryOpNode):
        (JSC::MultNode::MultNode):
        (JSC::DivNode::DivNode):
        (JSC::ModNode::ModNode):
        (JSC::AddNode::AddNode):
        (JSC::SubNode::SubNode):
        (JSC::LeftShiftNode::LeftShiftNode):
        (JSC::RightShiftNode::RightShiftNode):
        (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode):
        (JSC::LessNode::LessNode):
        (JSC::GreaterNode::GreaterNode):
        (JSC::LessEqNode::LessEqNode):
        (JSC::GreaterEqNode::GreaterEqNode):
        (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode):
        (JSC::InstanceOfNode::InstanceOfNode):
        (JSC::InNode::InNode):
        (JSC::EqualNode::EqualNode):
        (JSC::NotEqualNode::NotEqualNode):
        (JSC::StrictEqualNode::StrictEqualNode):
        (JSC::NotStrictEqualNode::NotStrictEqualNode):
        (JSC::BitAndNode::BitAndNode):
        (JSC::BitOrNode::BitOrNode):
        (JSC::BitXOrNode::BitXOrNode):
        (JSC::LogicalOpNode::LogicalOpNode):
        (JSC::ConditionalNode::ConditionalNode):
        (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
        (JSC::AssignResolveNode::AssignResolveNode):
        (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
        (JSC::AssignBracketNode::AssignBracketNode):
        (JSC::AssignDotNode::AssignDotNode):
        (JSC::ReadModifyDotNode::ReadModifyDotNode):
        (JSC::AssignErrorNode::AssignErrorNode):
        (JSC::CommaNode::CommaNode):
        (JSC::ConstStatementNode::ConstStatementNode):
        (JSC::EmptyStatementNode::EmptyStatementNode):
        (JSC::DebuggerStatementNode::DebuggerStatementNode):
        (JSC::ExprStatementNode::ExprStatementNode):
        (JSC::VarStatementNode::VarStatementNode):
        (JSC::IfNode::IfNode):
        (JSC::IfElseNode::IfElseNode):
        (JSC::DoWhileNode::DoWhileNode):
        (JSC::WhileNode::WhileNode):
        (JSC::ForNode::ForNode):
        (JSC::ContinueNode::ContinueNode):
        (JSC::BreakNode::BreakNode):
        (JSC::ReturnNode::ReturnNode):
        (JSC::WithNode::WithNode):
        (JSC::LabelNode::LabelNode):
        (JSC::ThrowNode::ThrowNode):
        (JSC::TryNode::TryNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::SwitchNode::SwitchNode):
        (JSC::ConstDeclNode::ConstDeclNode):
        (JSC::BlockNode::BlockNode):
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.cpp:
        (JSC):
        (JSC::StatementNode::setLoc):
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ProgramNode::create):
        (JSC::EvalNode::EvalNode):
        (JSC::EvalNode::create):
        (JSC::FunctionBodyNode::FunctionBodyNode):
        (JSC::FunctionBodyNode::create):
        * parser/Nodes.h:
        (Node):
        (ExpressionNode):
        (StatementNode):
        (NullNode):
        (BooleanNode):
        (NumberNode):
        (StringNode):
        (RegExpNode):
        (ThisNode):
        (ResolveNode):
        (ArrayNode):
        (PropertyListNode):
        (ObjectLiteralNode):
        (BracketAccessorNode):
        (DotAccessorNode):
        (ArgumentListNode):
        (NewExprNode):
        (EvalFunctionCallNode):
        (FunctionCallValueNode):
        (FunctionCallResolveNode):
        (FunctionCallBracketNode):
        (FunctionCallDotNode):
        (CallFunctionCallDotNode):
        (ApplyFunctionCallDotNode):
        (PrePostResolveNode):
        (PostfixResolveNode):
        (PostfixBracketNode):
        (PostfixDotNode):
        (PostfixErrorNode):
        (DeleteResolveNode):
        (DeleteBracketNode):
        (DeleteDotNode):
        (DeleteValueNode):
        (VoidNode):
        (TypeOfResolveNode):
        (TypeOfValueNode):
        (PrefixResolveNode):
        (PrefixBracketNode):
        (PrefixDotNode):
        (PrefixErrorNode):
        (UnaryOpNode):
        (UnaryPlusNode):
        (NegateNode):
        (BitwiseNotNode):
        (LogicalNotNode):
        (BinaryOpNode):
        (MultNode):
        (DivNode):
        (ModNode):
        (AddNode):
        (SubNode):
        (LeftShiftNode):
        (RightShiftNode):
        (UnsignedRightShiftNode):
        (LessNode):
        (GreaterNode):
        (LessEqNode):
        (GreaterEqNode):
        (ThrowableBinaryOpNode):
        (InstanceOfNode):
        (InNode):
        (EqualNode):
        (NotEqualNode):
        (StrictEqualNode):
        (NotStrictEqualNode):
        (BitAndNode):
        (BitOrNode):
        (BitXOrNode):
        (LogicalOpNode):
        (ConditionalNode):
        (ReadModifyResolveNode):
        (AssignResolveNode):
        (ReadModifyBracketNode):
        (AssignBracketNode):
        (AssignDotNode):
        (ReadModifyDotNode):
        (AssignErrorNode):
        (CommaNode):
        (ConstDeclNode):
        (ConstStatementNode):
        (BlockNode):
        (EmptyStatementNode):
        (DebuggerStatementNode):
        (ExprStatementNode):
        (VarStatementNode):
        (IfNode):
        (IfElseNode):
        (DoWhileNode):
        (WhileNode):
        (ForNode):
        (ForInNode):
        (ContinueNode):
        (BreakNode):
        (ReturnNode):
        (WithNode):
        (LabelNode):
        (ThrowNode):
        (TryNode):
        (ScopeNode):
        (ProgramNode):
        (EvalNode):
        (FunctionBodyNode):
        (FuncExprNode):
        (FuncDeclNode):
        (SwitchNode):
        * parser/Parser.cpp:
        (JSC::::parseSourceElements):
        (JSC::::parseVarDeclaration):
        (JSC::::parseConstDeclaration):
        (JSC::::parseDoWhileStatement):
        (JSC::::parseWhileStatement):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseConstDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseBreakStatement):
        (JSC::::parseContinueStatement):
        (JSC::::parseReturnStatement):
        (JSC::::parseThrowStatement):
        (JSC::::parseWithStatement):
        (JSC::::parseSwitchStatement):
        (JSC::::parseTryStatement):
        (JSC::::parseDebuggerStatement):
        (JSC::::parseBlockStatement):
        (JSC::::parseStatement):
        (JSC::::parseFunctionBody):
        (JSC::::parseFunctionInfo):
        (JSC::::parseFunctionDeclaration):
        (JSC::::parseExpressionOrLabelStatement):
        (JSC::::parseExpressionStatement):
        (JSC::::parseIfStatement):
        (JSC::::parseExpression):
        (JSC::::parseAssignmentExpression):
        (JSC::::parseConditionalExpression):
        (JSC::::parseBinaryExpression):
        (JSC::::parseProperty):
        (JSC::::parseObjectLiteral):
        (JSC::::parseStrictObjectLiteral):
        (JSC::::parseArrayLiteral):
        (JSC::::parsePrimaryExpression):
        (JSC::::parseArguments):
        (JSC::::parseMemberExpression):
        (JSC::::parseUnaryExpression):
        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        (JSC::Parser::tokenStart):
        (JSC::Parser::tokenLine):
        (JSC::Parser::tokenEnd):
        (JSC::Parser::getTokenName):
        (JSC::::parse):
        * parser/ParserTokens.h:
        (JSC::JSTokenInfo::JSTokenInfo):
        (JSTokenInfo):
        (JSToken):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::closeBraceToken):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):
        (JSC::SyntaxChecker::createCommaExpr):
        (JSC::SyntaxChecker::makeAssignNode):
        (JSC::SyntaxChecker::makePrefixNode):
        (JSC::SyntaxChecker::makePostfixNode):
        (JSC::SyntaxChecker::makeTypeOfNode):
        (JSC::SyntaxChecker::makeDeleteNode):
        (JSC::SyntaxChecker::makeNegateNode):
        (JSC::SyntaxChecker::makeBitwiseNotNode):
        (JSC::SyntaxChecker::createLogicalNot):
        (JSC::SyntaxChecker::createUnaryPlus):
        (JSC::SyntaxChecker::createVoid):
        (JSC::SyntaxChecker::thisExpr):
        (JSC::SyntaxChecker::createResolve):
        (JSC::SyntaxChecker::createObjectLiteral):
        (JSC::SyntaxChecker::createArray):
        (JSC::SyntaxChecker::createNumberExpr):
        (JSC::SyntaxChecker::createString):
        (JSC::SyntaxChecker::createBoolean):
        (JSC::SyntaxChecker::createNull):
        (JSC::SyntaxChecker::createBracketAccess):
        (JSC::SyntaxChecker::createDotAccess):
        (JSC::SyntaxChecker::createRegExp):
        (JSC::SyntaxChecker::createNewExpr):
        (JSC::SyntaxChecker::createConditionalExpr):
        (JSC::SyntaxChecker::createAssignResolve):
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createArgumentsList):
        (JSC::SyntaxChecker::createPropertyList):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createBlockStatement):
        (JSC::SyntaxChecker::createExprStatement):
        (JSC::SyntaxChecker::createIfStatement):
        (JSC::SyntaxChecker::createForLoop):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::createEmptyStatement):
        (JSC::SyntaxChecker::createVarStatement):
        (JSC::SyntaxChecker::createReturnStatement):
        (JSC::SyntaxChecker::createBreakStatement):
        (JSC::SyntaxChecker::createContinueStatement):
        (JSC::SyntaxChecker::createTryStatement):
        (JSC::SyntaxChecker::createSwitchStatement):
        (JSC::SyntaxChecker::createWhileStatement):
        (JSC::SyntaxChecker::createWithStatement):
        (JSC::SyntaxChecker::createDoWhileStatement):
        (JSC::SyntaxChecker::createLabelStatement):
        (JSC::SyntaxChecker::createThrowStatement):
        (JSC::SyntaxChecker::createDebugger):
        (JSC::SyntaxChecker::createConstStatement):
        (JSC::SyntaxChecker::appendConstDecl):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):
        (JSC::SyntaxChecker::combineCommaNodes):
        (JSC::SyntaxChecker::operatorStackPop):

2012-08-01  Peter Wang  <peter.wang@torchmobile.com.cn>

        Web Inspector: [JSC] implement setting breakpoints by line:column
        https://bugs.webkit.org/show_bug.cgi?id=53003

        Reviewed by Geoffrey Garen.

        Add a counter in lexer to record the column of each token. Debugger will use column info
        in "Pretty Print" debug mode of Inspector.

        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDebugHook):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::toArgumentList):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::ConditionalNode::emitBytecode):
        (JSC::ConstStatementNode::emitBytecode):
        (JSC::EmptyStatementNode::emitBytecode):
        (JSC::DebuggerStatementNode::emitBytecode):
        (JSC::ExprStatementNode::emitBytecode):
        (JSC::VarStatementNode::emitBytecode):
        (JSC::IfNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::EvalNode::emitBytecode):
        (JSC::FunctionBodyNode::emitBytecode):
        * debugger/Debugger.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::debug):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/ASTBuilder.h:
        (ASTBuilder):
        (JSC::ASTBuilder::createCommaExpr):
        (JSC::ASTBuilder::createLogicalNot):
        (JSC::ASTBuilder::createUnaryPlus):
        (JSC::ASTBuilder::createVoid):
        (JSC::ASTBuilder::thisExpr):
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::createObjectLiteral):
        (JSC::ASTBuilder::createArray):
        (JSC::ASTBuilder::createNumberExpr):
        (JSC::ASTBuilder::createString):
        (JSC::ASTBuilder::createBoolean):
        (JSC::ASTBuilder::createNull):
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::createRegExp):
        (JSC::ASTBuilder::createNewExpr):
        (JSC::ASTBuilder::createConditionalExpr):
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArgumentsList):
        (JSC::ASTBuilder::createPropertyList):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createIfStatement):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createEmptyStatement):
        (JSC::ASTBuilder::createVarStatement):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::createWhileStatement):
        (JSC::ASTBuilder::createDoWhileStatement):
        (JSC::ASTBuilder::createLabelStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::createDebugger):
        (JSC::ASTBuilder::createConstStatement):
        (JSC::ASTBuilder::appendConstDecl):
        (JSC::ASTBuilder::combineCommaNodes):
        (JSC::ASTBuilder::appendBinaryOperation):
        (JSC::ASTBuilder::createAssignment):
        (JSC::ASTBuilder::createNumber):
        (JSC::ASTBuilder::makeTypeOfNode):
        (JSC::ASTBuilder::makeDeleteNode):
        (JSC::ASTBuilder::makeNegateNode):
        (JSC::ASTBuilder::makeBitwiseNotNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeAddNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeLeftShiftNode):
        (JSC::ASTBuilder::makeRightShiftNode):
        (JSC::ASTBuilder::makeURightShiftNode):
        (JSC::ASTBuilder::makeBitOrNode):
        (JSC::ASTBuilder::makeBitAndNode):
        (JSC::ASTBuilder::makeBitXOrNode):
        (JSC::ASTBuilder::makeFunctionCallNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):
        * parser/Lexer.cpp:
        (JSC::::setCode):
        (JSC::::internalShift):
        (JSC::::shift):
        (JSC::::lex):
        * parser/Lexer.h:
        (Lexer):
        (JSC::Lexer::currentColumnNumber):
        (JSC::::lexExpectIdentifier):
        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        (JSC::ExpressionNode::ExpressionNode):
        (JSC::StatementNode::StatementNode):
        (JSC::NullNode::NullNode):
        (JSC::BooleanNode::BooleanNode):
        (JSC::NumberNode::NumberNode):
        (JSC::StringNode::StringNode):
        (JSC::RegExpNode::RegExpNode):
        (JSC::ThisNode::ThisNode):
        (JSC::ResolveNode::ResolveNode):
        (JSC::ArrayNode::ArrayNode):
        (JSC::PropertyListNode::PropertyListNode):
        (JSC::ObjectLiteralNode::ObjectLiteralNode):
        (JSC::BracketAccessorNode::BracketAccessorNode):
        (JSC::DotAccessorNode::DotAccessorNode):
        (JSC::ArgumentListNode::ArgumentListNode):
        (JSC::NewExprNode::NewExprNode):
        (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
        (JSC::FunctionCallValueNode::FunctionCallValueNode):
        (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
        (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
        (JSC::FunctionCallDotNode::FunctionCallDotNode):
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        (JSC::PrePostResolveNode::PrePostResolveNode):
        (JSC::PostfixResolveNode::PostfixResolveNode):
        (JSC::PostfixBracketNode::PostfixBracketNode):
        (JSC::PostfixDotNode::PostfixDotNode):
        (JSC::PostfixErrorNode::PostfixErrorNode):
        (JSC::DeleteResolveNode::DeleteResolveNode):
        (JSC::DeleteBracketNode::DeleteBracketNode):
        (JSC::DeleteDotNode::DeleteDotNode):
        (JSC::DeleteValueNode::DeleteValueNode):
        (JSC::VoidNode::VoidNode):
        (JSC::TypeOfResolveNode::TypeOfResolveNode):
        (JSC::TypeOfValueNode::TypeOfValueNode):
        (JSC::PrefixResolveNode::PrefixResolveNode):
        (JSC::PrefixBracketNode::PrefixBracketNode):
        (JSC::PrefixDotNode::PrefixDotNode):
        (JSC::PrefixErrorNode::PrefixErrorNode):
        (JSC::UnaryOpNode::UnaryOpNode):
        (JSC::UnaryPlusNode::UnaryPlusNode):
        (JSC::NegateNode::NegateNode):
        (JSC::BitwiseNotNode::BitwiseNotNode):
        (JSC::LogicalNotNode::LogicalNotNode):
        (JSC::BinaryOpNode::BinaryOpNode):
        (JSC::MultNode::MultNode):
        (JSC::DivNode::DivNode):
        (JSC::ModNode::ModNode):
        (JSC::AddNode::AddNode):
        (JSC::SubNode::SubNode):
        (JSC::LeftShiftNode::LeftShiftNode):
        (JSC::RightShiftNode::RightShiftNode):
        (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode):
        (JSC::LessNode::LessNode):
        (JSC::GreaterNode::GreaterNode):
        (JSC::LessEqNode::LessEqNode):
        (JSC::GreaterEqNode::GreaterEqNode):
        (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode):
        (JSC::InstanceOfNode::InstanceOfNode):
        (JSC::InNode::InNode):
        (JSC::EqualNode::EqualNode):
        (JSC::NotEqualNode::NotEqualNode):
        (JSC::StrictEqualNode::StrictEqualNode):
        (JSC::NotStrictEqualNode::NotStrictEqualNode):
        (JSC::BitAndNode::BitAndNode):
        (JSC::BitOrNode::BitOrNode):
        (JSC::BitXOrNode::BitXOrNode):
        (JSC::LogicalOpNode::LogicalOpNode):
        (JSC::ConditionalNode::ConditionalNode):
        (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
        (JSC::AssignResolveNode::AssignResolveNode):
        (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
        (JSC::AssignBracketNode::AssignBracketNode):
        (JSC::AssignDotNode::AssignDotNode):
        (JSC::ReadModifyDotNode::ReadModifyDotNode):
        (JSC::AssignErrorNode::AssignErrorNode):
        (JSC::CommaNode::CommaNode):
        (JSC::ConstStatementNode::ConstStatementNode):
        (JSC::EmptyStatementNode::EmptyStatementNode):
        (JSC::DebuggerStatementNode::DebuggerStatementNode):
        (JSC::ExprStatementNode::ExprStatementNode):
        (JSC::VarStatementNode::VarStatementNode):
        (JSC::IfNode::IfNode):
        (JSC::IfElseNode::IfElseNode):
        (JSC::DoWhileNode::DoWhileNode):
        (JSC::WhileNode::WhileNode):
        (JSC::ForNode::ForNode):
        (JSC::ContinueNode::ContinueNode):
        (JSC::BreakNode::BreakNode):
        (JSC::ReturnNode::ReturnNode):
        (JSC::WithNode::WithNode):
        (JSC::LabelNode::LabelNode):
        (JSC::ThrowNode::ThrowNode):
        (JSC::TryNode::TryNode):
        (JSC::FuncExprNode::FuncExprNode):
        (JSC::FuncDeclNode::FuncDeclNode):
        (JSC::SwitchNode::SwitchNode):
        (JSC::ConstDeclNode::ConstDeclNode):
        (JSC::BlockNode::BlockNode):
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.cpp:
        (JSC::StatementNode::setLoc):
        (JSC):
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ProgramNode::create):
        (JSC::EvalNode::EvalNode):
        (JSC::EvalNode::create):
        (JSC::FunctionBodyNode::FunctionBodyNode):
        (JSC::FunctionBodyNode::create):
        * parser/Nodes.h:
        (Node):
        (JSC::Node::columnNo):
        (ExpressionNode):
        (StatementNode):
        (JSC::StatementNode::column):
        (NullNode):
        (BooleanNode):
        (NumberNode):
        (StringNode):
        (RegExpNode):
        (ThisNode):
        (ResolveNode):
        (ArrayNode):
        (PropertyListNode):
        (ObjectLiteralNode):
        (BracketAccessorNode):
        (DotAccessorNode):
        (ArgumentListNode):
        (NewExprNode):
        (EvalFunctionCallNode):
        (FunctionCallValueNode):
        (FunctionCallResolveNode):
        (FunctionCallBracketNode):
        (FunctionCallDotNode):
        (CallFunctionCallDotNode):
        (ApplyFunctionCallDotNode):
        (PrePostResolveNode):
        (PostfixResolveNode):
        (PostfixBracketNode):
        (PostfixDotNode):
        (PostfixErrorNode):
        (DeleteResolveNode):
        (DeleteBracketNode):
        (DeleteDotNode):
        (DeleteValueNode):
        (VoidNode):
        (TypeOfResolveNode):
        (TypeOfValueNode):
        (PrefixResolveNode):
        (PrefixBracketNode):
        (PrefixDotNode):
        (PrefixErrorNode):
        (UnaryOpNode):
        (UnaryPlusNode):
        (NegateNode):
        (BitwiseNotNode):
        (LogicalNotNode):
        (BinaryOpNode):
        (MultNode):
        (DivNode):
        (ModNode):
        (AddNode):
        (SubNode):
        (LeftShiftNode):
        (RightShiftNode):
        (UnsignedRightShiftNode):
        (LessNode):
        (GreaterNode):
        (LessEqNode):
        (GreaterEqNode):
        (ThrowableBinaryOpNode):
        (InstanceOfNode):
        (InNode):
        (EqualNode):
        (NotEqualNode):
        (StrictEqualNode):
        (NotStrictEqualNode):
        (BitAndNode):
        (BitOrNode):
        (BitXOrNode):
        (LogicalOpNode):
        (ConditionalNode):
        (ReadModifyResolveNode):
        (AssignResolveNode):
        (ReadModifyBracketNode):
        (AssignBracketNode):
        (AssignDotNode):
        (ReadModifyDotNode):
        (AssignErrorNode):
        (CommaNode):
        (ConstDeclNode):
        (ConstStatementNode):
        (BlockNode):
        (EmptyStatementNode):
        (DebuggerStatementNode):
        (ExprStatementNode):
        (VarStatementNode):
        (IfNode):
        (IfElseNode):
        (DoWhileNode):
        (WhileNode):
        (ForNode):
        (ForInNode):
        (ContinueNode):
        (BreakNode):
        (ReturnNode):
        (WithNode):
        (LabelNode):
        (ThrowNode):
        (TryNode):
        (ScopeNode):
        (ProgramNode):
        (EvalNode):
        (FunctionBodyNode):
        (FuncExprNode):
        (FuncDeclNode):
        (SwitchNode):
        * parser/Parser.cpp:
        (JSC::::parseSourceElements):
        (JSC::::parseVarDeclaration):
        (JSC::::parseConstDeclaration):
        (JSC::::parseDoWhileStatement):
        (JSC::::parseWhileStatement):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseConstDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseBreakStatement):
        (JSC::::parseContinueStatement):
        (JSC::::parseReturnStatement):
        (JSC::::parseThrowStatement):
        (JSC::::parseWithStatement):
        (JSC::::parseSwitchStatement):
        (JSC::::parseTryStatement):
        (JSC::::parseDebuggerStatement):
        (JSC::::parseBlockStatement):
        (JSC::::parseStatement):
        (JSC::::parseFunctionBody):
        (JSC::::parseFunctionInfo):
        (JSC::::parseFunctionDeclaration):
        (JSC::::parseExpressionOrLabelStatement):
        (JSC::::parseExpressionStatement):
        (JSC::::parseIfStatement):
        (JSC::::parseExpression):
        (JSC::::parseAssignmentExpression):
        (JSC::::parseConditionalExpression):
        (JSC::::parseBinaryExpression):
        (JSC::::parseProperty):
        (JSC::::parseObjectLiteral):
        (JSC::::parseStrictObjectLiteral):
        (JSC::::parseArrayLiteral):
        (JSC::::parsePrimaryExpression):
        (JSC::::parseArguments):
        (JSC::::parseMemberExpression):
        (JSC::::parseUnaryExpression):
        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        (JSC::Parser::tokenStart):
        (JSC::Parser::tokenLine):
        (JSC::Parser::tokenEnd):
        (JSC::Parser::tokenLocation):
        (Parser):
        (JSC::Parser::getTokenName):
        (JSC::::parse):
        * parser/ParserTokens.h:
        (JSC::JSTokenLocation::JSTokenLocation):
        (JSTokenLocation):
        (JSToken):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::closeBraceToken):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):
        (JSC::SyntaxChecker::createCommaExpr):
        (JSC::SyntaxChecker::makeAssignNode):
        (JSC::SyntaxChecker::makePrefixNode):
        (JSC::SyntaxChecker::makePostfixNode):
        (JSC::SyntaxChecker::makeTypeOfNode):
        (JSC::SyntaxChecker::makeDeleteNode):
        (JSC::SyntaxChecker::makeNegateNode):
        (JSC::SyntaxChecker::makeBitwiseNotNode):
        (JSC::SyntaxChecker::createLogicalNot):
        (JSC::SyntaxChecker::createUnaryPlus):
        (JSC::SyntaxChecker::createVoid):
        (JSC::SyntaxChecker::thisExpr):
        (JSC::SyntaxChecker::createResolve):
        (JSC::SyntaxChecker::createObjectLiteral):
        (JSC::SyntaxChecker::createArray):
        (JSC::SyntaxChecker::createNumberExpr):
        (JSC::SyntaxChecker::createString):
        (JSC::SyntaxChecker::createBoolean):
        (JSC::SyntaxChecker::createNull):
        (JSC::SyntaxChecker::createBracketAccess):
        (JSC::SyntaxChecker::createDotAccess):
        (JSC::SyntaxChecker::createRegExp):
        (JSC::SyntaxChecker::createNewExpr):
        (JSC::SyntaxChecker::createConditionalExpr):
        (JSC::SyntaxChecker::createAssignResolve):
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createArgumentsList):
        (JSC::SyntaxChecker::createPropertyList):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createBlockStatement):
        (JSC::SyntaxChecker::createExprStatement):
        (JSC::SyntaxChecker::createIfStatement):
        (JSC::SyntaxChecker::createForLoop):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::createEmptyStatement):
        (JSC::SyntaxChecker::createVarStatement):
        (JSC::SyntaxChecker::createReturnStatement):
        (JSC::SyntaxChecker::createBreakStatement):
        (JSC::SyntaxChecker::createContinueStatement):
        (JSC::SyntaxChecker::createTryStatement):
        (JSC::SyntaxChecker::createSwitchStatement):
        (JSC::SyntaxChecker::createWhileStatement):
        (JSC::SyntaxChecker::createWithStatement):
        (JSC::SyntaxChecker::createDoWhileStatement):
        (JSC::SyntaxChecker::createLabelStatement):
        (JSC::SyntaxChecker::createThrowStatement):
        (JSC::SyntaxChecker::createDebugger):
        (JSC::SyntaxChecker::createConstStatement):
        (JSC::SyntaxChecker::appendConstDecl):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):
        (JSC::SyntaxChecker::combineCommaNodes):
        (JSC::SyntaxChecker::operatorStackPop):

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

        DFG should hoist structure checks
        https://bugs.webkit.org/show_bug.cgi?id=92696

        Reviewed by Gavin Barraclough.

        This hoists structure checks in the same way that we would hoist array checks, but with added
        complexity to cope with the fact that the structure of an object may change. This is handled
        by performing a side effects analysis over the region in which the respective variable is
        live. If a structure clobbering side effect may happen then we either hoist the structure
        checks and fall back on structure transition watchpoints (if the watchpoint set is still
        valid), or we avoid hoisting altogether.
        
        Doing this required teaching the CFA that we may have an expectation that an object has a
        particular structure even after structure clobbering happens, in the sense that structure
        proofs that were cobbered can be revived using watchpoints. CFA must know about this so that
        OSR entry may know about it, since we cannot allow entry to happen if the variable has a
        clobbered structure proof, will have a watchpoint to revive the proof, and the variable in
        the baseline JIT has a completely unrelated structure.
        
        This is mostly performance neutral.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::isSet):
        (JSC::ValueRecovery::operator!):
        (ValueRecovery):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::clobberWorld):
        (DFG):
        (JSC::DFG::AbstractState::clobberCapturedVars):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::clear):
        (JSC::DFG::AbstractValue::isClear):
        (JSC::DFG::AbstractValue::makeTop):
        (JSC::DFG::AbstractValue::isTop):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::operator==):
        (JSC::DFG::AbstractValue::merge):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::validate):
        (JSC::DFG::AbstractValue::validateForEntry):
        (AbstractValue):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::dump):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::fixVariableAccessSpeculations):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::checkStructureLoadElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        (JSC::DFG::CSEPhase::getLocalLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::vote):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToStructureTransitionWatchpoint):
        (Node):
        (JSC::DFG::Node::hasStructureSet):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (PredictionPropagationPhase):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::speculationCheckWithConditionalDirection):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection):
        (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
        (JSC::DFG::SpeculateCellOperand::gpr):
        (SpeculateCellOperand):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp: Added.
        (DFG):
        (StructureCheckHoistingPhase):
        (JSC::DFG::StructureCheckHoistingPhase::StructureCheckHoistingPhase):
        (JSC::DFG::StructureCheckHoistingPhase::run):
        (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck):
        (JSC::DFG::StructureCheckHoistingPhase::noticeClobber):
        (JSC::DFG::StructureCheckHoistingPhase::clobber):
        (CheckData):
        (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData):
        (JSC::DFG::performStructureCheckHoisting):
        * dfg/DFGStructureCheckHoistingPhase.h: Added.
        (DFG):
        * dfg/DFGVariableAccessData.h:
        (VariableAccessData):
        (JSC::DFG::VariableAccessData::VariableAccessData):
        (JSC::DFG::VariableAccessData::mergeStructureCheckHoistingFailed):
        (JSC::DFG::VariableAccessData::structureCheckHoistingFailed):
        (JSC::DFG::VariableAccessData::clearVotes):
        (JSC::DFG::VariableAccessData::vote):
        (JSC::DFG::VariableAccessData::voteRatio):
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
        * runtime/Options.h:
        (JSC):

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

        DFG should distinguish between PutByVal's that clobber the world and ones that don't
        https://bugs.webkit.org/show_bug.cgi?id=92923

        Reviewed by Mark Hahnenberg.

        This is performance-neutral. I also confirmed that it's neutral if we make the
        clobbering variant (PutByValSafe) clobber all knowledge of what is an array,
        which should feed nicely into work on removing uses of ClassInfo.

        * bytecode/DFGExitProfile.h:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getByValLoadElimination):
        (JSC::DFG::CSEPhase::checkStructureLoadElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
        (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        (JSC::DFG::Graph::clobbersWorld):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-08-01  Jian Li  <jianli@chromium.org>

        Add new CSS property "-webkit-widget-region" to expose dashboard region support for other port
        https://bugs.webkit.org/show_bug.cgi?id=90298

        Reviewed by Adam Barth.

        * Configurations/FeatureDefines.xcconfig: Add ENABLE_WIDGET_REGION define.

2012-08-01  Patrick Gansterer  <paroga@webkit.org>

        Replace WTF::getCurrentLocalTime() with GregorianDateTime::setToCurrentLocalTime()
        https://bugs.webkit.org/show_bug.cgi?id=92286

        Reviewed by Geoffrey Garen.

        Add a method to GregorianDateTime to set its values to the current locale time.
        Replacing all occurrences of getCurrentLocalTime with the new function allows
        us to remove getCurrentLocalTime in a next step.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        C++ code should get ClassInfo from the Structure
        https://bugs.webkit.org/show_bug.cgi?id=92892

        Reviewed by Geoffrey Garen.

        In our march to remove ClassInfo from our JSCell object headers, we can switch 
        C++ code over to grabbing the ClassInfo from the Structure since it is finally 
        safe to do so now that Structure access is safe during finalization/destruction. 
        The remaining JIT code changes can be done in a separate patch.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::callDestructor): We don't want to clear the Structure any more 
        since the Structure should still be valid at this point.
        * heap/WeakSetInlines.h:
        (JSC::WeakBlock::finalize): Ditto.
        * runtime/JSCell.h:
        (JSC):
        * runtime/Structure.h:
        (JSC::JSCell::classInfo): Move JSCell's classInfo() to Structure.h so it can be 
        inline. Use a different method of getting the JSCell's Structure based on 
        whether we're in GC_VALIDATION mode or not, since always using get() will cause 
        infinite recursion in GC_VALIDATION mode.
        (JSC):

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

        MarkedBlock::sweep() should sweep another block if it can't sweep a Structure block
        https://bugs.webkit.org/show_bug.cgi?id=92819

        Reviewed by Geoffrey Garen.

        If we are forced to allocate a new block for Structures because we are unable to safely 
        sweep our pre-existing Structure blocks, we should sweep another random block so that we 
        can start sweeping Structure blocks sooner.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep): Change to use sweepNextBlock.
        (JSC):
        (JSC::IncrementalSweeper::sweepNextBlock): 
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): When we can't safely sweep 
        our Structure blocks, call sweepNextBlock instead.

2012-07-31  Sam Weinig  <sam@webkit.org>

        Fix the Windows build.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-07-31  Geoffrey Garen  <ggaren@apple.com>

        Maybe fix the GCC build.

        * heap/HeapBlock.h:
        (HeapBlock): Accommodate incorrect parsing in GCC.

2012-07-31  Sam Weinig  <sam@webkit.org>

        Stop masking 8 bits off of the visited link hash. We need all the bits!
        https://bugs.webkit.org/show_bug.cgi?id=92799

        Reviewed by Anders Carlsson.

        * runtime/Identifier.cpp:
        (JSC::IdentifierCStringTranslator::hash):
        (JSC::IdentifierLCharFromUCharTranslator::hash):
        * runtime/Identifier.h:
        (JSC::IdentifierCharBufferTranslator::hash):
        Update for new function names.

2012-07-31  Geoffrey Garen  <ggaren@apple.com>

        Maybe break the Windows build.

        Reviewed by Anders Carlsson.

        Formally objected to by Sam Weinig.

        * heap/HeapBlock.h:
        (HeapBlock): Try to slightly improve this because we don't want Windows to control our lives.

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

        Structures should be swept after all other objects
        https://bugs.webkit.org/show_bug.cgi?id=92679

        Reviewed by Filip Pizlo.

        In order to get rid of ClassInfo from our objects, we need to be able to safely get the 
        ClassInfo during the destruction of objects. We'd like to get the ClassInfo out of the 
        Structure, but currently it is not safe to do so because the order of destruction of objects 
        is not guaranteed to sweep objects before their corresponding Structure. We can fix this by 
        sweeping Structures after everything else.

        * heap/Heap.cpp:
        (JSC::Heap::isSafeToSweepStructures): Add a function that checks if it is safe to sweep Structures.
        If the Heap's IncrementalSweeper member is null, that means we're shutting down this VM and it is 
        safe to sweep structures since we'll always do Structures last anyways due to the ordering of 
        MarkedSpace::forEachBlock.
        (JSC):
        (JSC::Heap::didStartVMShutdown): Add this intermediate function to the Heap that ~JSGlobalData now
        calls rather than calling the two HeapTimer objects individually. This allows the Heap to null out 
        these pointers after it has invalidated them to prevent accidental use-after-free in the sweep() 
        calls during lastChanceToFinalize().
        * heap/Heap.h:
        (Heap):
        * heap/HeapTimer.h:
        (HeapTimer):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::structuresCanBeSwept): Determines if it is currently safe to sweep Structures.
        This decision is based on whether we have gotten to the end of the vector of blocks that need sweeping
        the first time.
        (JSC):
        (JSC::IncrementalSweeper::doSweep): We add a second pass over the vector to sweep Structures after we 
        make our first pass. We now null out the slots as we sweep them so that we can quickly find the 
        Structures during the second pass.
        (JSC::IncrementalSweeper::startSweeping): Initialize our new Structure sweeping index.
        (JSC::IncrementalSweeper::willFinishSweeping): Callback that is called by MarkedSpace::sweep to notify 
        the IncrementalSweeper that we are going to sweep all of the remaining blocks in the Heap so it can 
        assume that everything is taken care of in the correct order. Since MarkedSpace::forEachBlock 
        iterates over the Structure blocks after all other blocks, the ordering property for sweeping Structures holds.
        (JSC::IncrementalSweeper::IncrementalSweeper): Initialize Structure sweeping index.
        * heap/IncrementalSweeper.h: Add declarations for new stuff.
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): We now check if the current block only contains structures and 
        if so and it isn't safe to sweep Structures according to the Heap, we just return early instead of doing 
        the normal lazy sweep. If this proves to be too much of a waste in the future we can add an extra clause that 
        will sweep some number of other blocks in place of the current block to mitigate the cost of the floating 
        Structure garbage.
        (JSC::MarkedAllocator::addBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::zapFreeList): When we zap the free list in the MarkedAllocator, the current block is no 
        longer valid to allocate from, so we set the current block to null.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper): Added a couple assertions to make sure that we weren't trying to sweep Structures
        at an unsafe time.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::sweep): Notify the IncrementalSweeper that the MarkedSpace will finish all currently remaining sweeping.
        (JSC): 
        * heap/MarkedSpace.h:
        (JSC):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::~JSGlobalData): Call the new Heap::didStartVMShutdown.

2012-07-31  Geoffrey Garen  <ggaren@apple.com>

        Fix all the other builds I just broke. Maybe fix the Windows build.

        * heap/HeapBlock.h:
        (HeapBlock): WTF?

2012-07-31  Geoffrey Garen  <ggaren@apple.com>

        Maybe fix the Windows build.

        * heap/HeapBlock.h:
        (HeapBlock): WTF?

2012-07-31  Geoffrey Garen  <ggaren@apple.com>

        Maybe fix the Windows build.

        * heap/HeapBlock.h:
        (HeapBlock): WTF?

2012-07-31  Geoffrey Garen  <ggaren@apple.com>

        Removed some public data and casting from the Heap
        https://bugs.webkit.org/show_bug.cgi?id=92777

        Reviewed by Oliver Hunt.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::releaseFreeBlocks):
        (JSC::BlockAllocator::blockFreeingThreadMain): Use the DeadBlock class
        since HeapBlock is a template, and not a class, now. Call destroy()
        instead of monkeying around with DeadBlock's internal data because
        encapsulation is good.

        * heap/BlockAllocator.h:
        (DeadBlock): Added a class to represent a dead block, since HeapBlock is
        a template now, and can't be instantiated directly.

        (JSC::DeadBlock::DeadBlock):
        (JSC::DeadBlock::create):
        (BlockAllocator):
        (JSC::BlockAllocator::allocate):
        (JSC::BlockAllocator::deallocate): Use the DeadBlock class because
        encapsulation is good.

        * heap/CopiedBlock.h:
        (CopiedBlock::destroy): No need for a destroy() function, since we
        inherit one now.

        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::payloadEnd):
        (JSC::CopiedBlock::capacity): Updated for some encapsulation inside
        HeapBlock.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::doneCopying):
        (JSC::CopiedSpace::size):
        (JSC::CopiedSpace::capacity):
        (JSC::isBlockListPagedOut): Removed a bunch of casting. This is no longer
        necessary, now that our list and its nodes have the right type.

        * heap/CopiedSpace.h: Use the right type in our data structures because
        it improves clarity.

        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::startedCopying): Use swap to avoid duplicating it.

        * heap/HeapBlock.h:
        (HeapBlock): Made this a class template so we can return the right type
        in linked list operations. Made our data private because encapsulation
        is good.

        (JSC::HeapBlock::destroy): Since we know our type, we can also eliminate
        duplicate destroy() functions in our subclasses.

        (JSC::HeapBlock::allocation): Added an accessor so we can hide our data.
        By using const, this accessor prevents clients from accidentally deleting
        our allocation.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::isPagedOut):
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::removeBlock): Removed a bunch of casting. This is
        no longer necessary, now that our list and its nodes have the right type.

        * heap/MarkedAllocator.h:
        (MarkedAllocator):
        (JSC::MarkedAllocator::reset):
        (JSC::MarkedAllocator::forEachBlock): Use the right type, do less casting.

        * heap/MarkedBlock.cpp: 
        (JSC::MarkedBlock::destroy): Removed this function because our parent
        class provides it for us now.

        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::capacity): Updated for encapsulation.

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

        DFG OSR exit profiling has unusual oversights
        https://bugs.webkit.org/show_bug.cgi?id=92728

        Reviewed by Geoffrey Garen.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2012-07-31  Chao-ying Fu  <fu@mips.com>

        Add MIPS add32 function
        https://bugs.webkit.org/show_bug.cgi?id=91522

        Reviewed by Oliver Hunt.

        Add isCompactPtrAlignedAddressOffset.
        Add a new version of add32 that accepts AbsoluteAddress as inputs.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::isCompactPtrAlignedAddressOffset): New.
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::add32): Support AbsoluteAddress as inputs.

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

        Unreviewed, rolling out r124123.
        http://trac.webkit.org/changeset/124123
        https://bugs.webkit.org/show_bug.cgi?id=92700

        ASSERT crashes terminate webkit Layout tests (Requested by
        msaboff on #webkit).

        * heap/Heap.cpp:
        * heap/Heap.h:
        (Heap):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::addBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::zapFreeList):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedSpace.cpp:
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::sweep):
        (JSC):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::~JSGlobalData):

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

        Structures should be swept after all other objects
        https://bugs.webkit.org/show_bug.cgi?id=92679

        Reviewed by Filip Pizlo.

        In order to get rid of ClassInfo from our objects, we need to be able to safely get the 
        ClassInfo during the destruction of objects. We'd like to get the ClassInfo out of the 
        Structure, but currently it is not safe to do so because the order of destruction of objects 
        is not guaranteed to sweep objects before their corresponding Structure. We can fix this by 
        sweeping Structures after everything else.

        * heap/Heap.cpp:
        (JSC::Heap::isSafeToSweepStructures): Add a function that checks if it is safe to sweep Structures.
        If the Heap's IncrementalSweeper member is null, that means we're shutting down this VM and it is 
        safe to sweep structures since we'll always do Structures last anyways due to the ordering of 
        MarkedSpace::forEachBlock.
        (JSC):
        (JSC::Heap::didStartVMShutdown): Add this intermediate function to the Heap that ~JSGlobalData now
        calls rather than calling the two HeapTimer objects individually. This allows the Heap to null out 
        these pointers after it has invalidated them to prevent accidental use-after-free in the sweep() 
        calls during lastChanceToFinalize().
        * heap/Heap.h:
        (Heap):
        * heap/HeapTimer.h:
        (HeapTimer):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::structuresCanBeSwept): Determines if it is currently safe to sweep Structures.
        This decision is based on whether we have gotten to the end of the vector of blocks that need sweeping
        the first time.
        (JSC):
        (JSC::IncrementalSweeper::doSweep): We add a second pass over the vector to sweep Structures after we 
        make our first pass. We now null out the slots as we sweep them so that we can quickly find the 
        Structures during the second pass.
        (JSC::IncrementalSweeper::startSweeping): Initialize our new Structure sweeping index.
        (JSC::IncrementalSweeper::willFinishSweeping): Callback that is called by MarkedSpace::sweep to notify 
        the IncrementalSweeper that we are going to sweep all of the remaining blocks in the Heap so it can 
        assume that everything is taken care of in the correct order. Since MarkedSpace::forEachBlock 
        iterates over the Structure blocks after all other blocks, the ordering property for sweeping Structures holds.
        (JSC::IncrementalSweeper::IncrementalSweeper): Initialize Structure sweeping index.
        * heap/IncrementalSweeper.h: Add declarations for new stuff.
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): We now check if the current block only contains structures and 
        if so and it isn't safe to sweep Structures according to the Heap, we just return early instead of doing 
        the normal lazy sweep. If this proves to be too much of a waste in the future we can add an extra clause that 
        will sweep some number of other blocks in place of the current block to mitigate the cost of the floating 
        Structure garbage.
        (JSC::MarkedAllocator::addBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::zapFreeList): When we zap the free list in the MarkedAllocator, the current block is no 
        longer valid to allocate from, so we set the current block to null.
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweepHelper): Added a couple assertions to make sure that we weren't trying to sweep Structures
        at an unsafe time.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::sweep): Notify the IncrementalSweeper that the MarkedSpace will finish all currently remaining sweeping.
        (JSC): 
        * heap/MarkedSpace.h:
        (JSC):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::~JSGlobalData): Call the new Heap::didStartVMShutdown.

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

        PropertyNameArray::m_shouldCache is only assigned and never used
        https://bugs.webkit.org/show_bug.cgi?id=92598

        Reviewed by Dan Bernstein.

        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::PropertyNameArray):
        (PropertyNameArray):

2012-07-29  Rik Cabanier  <cabanier@adobe.com>

        Add ENABLE_CSS_COMPOSITING flag
        https://bugs.webkit.org/show_bug.cgi?id=92553

        Reviewed by Dirk Schulze.

        Adds compiler flag CSS_COMPOSITING to build systems to enable CSS blending and compositing. See spec https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html

        * Configurations/FeatureDefines.xcconfig:

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

        Split functionality of MarkedAllocator::m_currentBlock
        https://bugs.webkit.org/show_bug.cgi?id=92550

        Reviewed by Filip Pizlo.

        MarkedAllocator::m_currentBlock serves two purposes right now; it indicates the block that is currently 
        being used for allocation and the beginning of the list of blocks that need to be swept. We should split 
        these two functionalities into two separate fields.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): Use m_blocksToSweep instead of m_currentBlock as the 
        initializer/reference of the loop. Only change m_currentBlock when we know what the result will be.
        (JSC::MarkedAllocator::addBlock): When we add a new block we know that both m_blocksToSweep and 
        m_currentBlock are null. In order to preserve the invariant that m_currentBlock <= m_blocksToSweep, 
        we assign both of them to point to the new block.
        (JSC::MarkedAllocator::removeBlock): We need a separate check to see if the block we're removing is 
        m_blocksToSweep and if so, advance it to the next block in the list.
        * heap/MarkedAllocator.h:
        (MarkedAllocator): Initialize m_blocksToSweep.
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::reset): We set m_blocksToSweep to be the head of our list. This function is called
        at the end of a collection, so all of the blocks in our allocator need to be swept. We need to sweep a 
        block before we can start allocating, so m_currentBlock is set to null. We also set the freeList to 
        the empty FreeList to emphasize the fact that we can't start allocating until we do some sweeping.

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

        Increase inline storage for JSFinalObjects by one
        https://bugs.webkit.org/show_bug.cgi?id=92526

        Reviewed by Geoffrey Garen.

        Now that we've removed the inheritorID from objects, we can increase our inline storage for JSFinalObjects on 
        64-bit platforms by 1.

        * llint/LowLevelInterpreter.asm: Change the constant.
        * runtime/PropertyOffset.h: Change the constant.
        (JSC):

2012-07-27  Jer Noble  <jer.noble@apple.com>

        Support a rational time class for use by media elements.
        https://bugs.webkit.org/show_bug.cgi?id=88787

        Re-export WTF::MediaTime from JavaScriptCore.

        Reviewed by Eric Carlson.

        * JavaScriptCore.order:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        JSObject::reallocateStorageIfNecessary is neither used nor defined
        https://bugs.webkit.org/show_bug.cgi?id=92417

        Reviewed by Mark Rowe.

        * runtime/JSObject.h:
        (JSObject):

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

        Allocate Structures in a separate part of the Heap
        https://bugs.webkit.org/show_bug.cgi?id=92420

        Reviewed by Filip Pizlo.

        To fix our issue with destruction/finalization of Structures before their objects, we can move Structures to a separate 
        part of the Heap that will be swept after all other objects. This first patch will just be separating Structures 
        out into their own separate MarkedAllocator. Everything else will behave identically.

        * heap/Heap.h: New function to allocate Structures in the Heap.
        (Heap):
        (JSC):
        (JSC::Heap::allocateStructure):
        * heap/MarkedAllocator.cpp: Pass whether or not we're allocated Structures to the MarkedBlock.
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h: Add tracking for whether or not we're allocating only Structures.
        (JSC::MarkedAllocator::onlyContainsStructures):
        (MarkedAllocator):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        * heap/MarkedBlock.cpp: Add tracking for whether or not we're allocating only Structures. We need this to be able to 
        distinguish the various MarkedBlock types in MarkedSpace::allocatorFor(MarkedBlock*).
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (MarkedBlock):
        (JSC::MarkedBlock::onlyContainsStructures):
        (JSC):
        * heap/MarkedSpace.cpp: Include the new Structure allocator in all the places that all the other allocators are used/modified.
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        * heap/MarkedSpace.h: Add new MarkedAllocator just for Structures.
        (MarkedSpace):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::allocateStructure):
        (JSC):
        (JSC::MarkedSpace::forEachBlock):
        * runtime/Structure.h: Move all of the functions that call allocateCell<Structure> down below the explicit template specialization
        for allocateCell<Structure>. The new inline specialization for allocateCell directly calls the allocateStructure() function in the
        Heap.
        (Structure):
        (JSC::Structure):
        (JSC):
        (JSC::Structure::create):
        (JSC::Structure::createStructure):

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

        JSArray has methods that are neither used nor defined
        https://bugs.webkit.org/show_bug.cgi?id=92416

        Reviewed by Simon Fraser.

        * runtime/JSArray.h:
        (JSArray):

2012-07-26  Zoltan Herczeg  <zherczeg@webkit.org>

        [Qt][ARM]ARMAssembler needs buildfix afert r123417
        https://bugs.webkit.org/show_bug.cgi?id=92086

        Reviewed by Csaba Osztrogonác.

        The ARM implementation of this should be optimized code path
        is covered by a non-optimized code path. This patch fixes this,
        and adds a new function which returns with the offset range.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::readPointer):
        (ARMAssembler):
        (JSC::ARMAssembler::repatchInt32):
        (JSC::ARMAssembler::repatchCompact):
        * assembler/MacroAssemblerARM.h:
        (MacroAssemblerARM):
        (JSC::MacroAssemblerARM::isCompactPtrAlignedAddressOffset):
        (JSC::MacroAssemblerARM::load32WithCompactAddressOffsetPatch):

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

        Build fix for 32-bit after r123682

        * runtime/JSObject.h: Need to pad out JSObjects on 32-bit so that they're the correct size since
        we only removed one 4-byte word and we need to be 8-byte aligned.
        (JSObject):

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

        JSC GC object copying APIs should allow for greater flexibility
        https://bugs.webkit.org/show_bug.cgi?id=92316

        Reviewed by Mark Hahnenberg.

        It's now the case that visitChildren() methods can directly pin and allocate in new space during copying.
        They can also do the copying and marking themselves. This new API is only used for JSObjects for now.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/MarkStack.cpp:
        (JSC::SlotVisitor::allocateNewSpaceSlow):
        (JSC::SlotVisitor::allocateNewSpaceOrPin):
        (JSC):
        (JSC::SlotVisitor::copyAndAppend):
        * heap/MarkStack.h:
        (MarkStack):
        (JSC::MarkStack::appendUnbarrieredValue):
        (JSC):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlineMethods.h: Added.
        (JSC):
        (JSC::SlotVisitor::checkIfShouldCopyAndPinOtherwise):
        (JSC::SlotVisitor::allocateNewSpace):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitOutOfLineStorage):
        (JSC):
        (JSC::JSObject::visitChildren):
        (JSC::JSFinalObject::visitChildren):
        * runtime/JSObject.h:
        (JSObject):

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

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

        Reviewed by Filip Pizlo.

        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::JSFinalObject::visitChildren): No m_inheritorID to be marked.
        (JSC::JSObject::createInheritorID): Store the newly created inheritorID in the property map. Make sure 
        it's got the DontEnum attribute!!
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::resetInheritorID): Remove the inheritorID from property storage.
        (JSC):
        (JSC::JSObject::inheritorID): Read the inheritorID from property storage.

2012-07-25  Caio Marcelo de Oliveira Filho  <caio.oliveira@openbossa.org>

        Create a specialized pair for use in HashMap iterators
        https://bugs.webkit.org/show_bug.cgi?id=92137

        Reviewed by Ryosuke Niwa.

        Update a couple of sites that relied on the fact that "contents" of iterators were
        std::pairs.

        * profiler/Profile.cpp:
        (JSC): This code kept a vector of the pairs that were the "contents" of the iterators. This
        is changed to use a KeyValuePair. We make use HashCount's ValueType (which represents only
        the key) to get the proper key parameter for KeyValuePair.
        * tools/ProfileTreeNode.h:
        (ProfileTreeNode): Use HashMap::ValueType to declare the type of the contents of the hash
        instead of declaring it manually. This will make use of the new KeyValuePair.

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

        REGRESSION(r123505): Date.getYear() returns the same as Date.getFullYear()
        https://bugs.webkit.org/show_bug.cgi?id=92218

        Reviewed by Csaba Osztrogonác.

        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncGetYear): Added the missing offset of 1900 to the return value.

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

        REGRESSION(r123417): It made tests assert/crash on 32 bit
        https://bugs.webkit.org/show_bug.cgi?id=92088

        Reviewed by Mark Hahnenberg.

        The pointer arithmetic was wrong, because negative numbers are hard to think about.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):

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

        Store the full year in GregorianDateTime
        https://bugs.webkit.org/show_bug.cgi?id=92067

        Reviewed by Geoffrey Garen.

        Use the full year instead of the offset from year 1900
        for the year member variable of GregorianDateTime.

        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        (JSC::dateUTC):
        * runtime/DateConversion.cpp:
        (JSC::formatDate):
        (JSC::formatDateUTCVariant):
        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):
        (JSC::fillStructuresUsingDateArgs):
        (JSC::dateProtoFuncToISOString):
        (JSC::dateProtoFuncGetFullYear):
        (JSC::dateProtoFuncGetUTCFullYear):
        (JSC::dateProtoFuncSetYear):
        * runtime/JSDateMath.cpp:
        (JSC::gregorianDateTimeToMS):
        (JSC::msToGregorianDateTime):

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

        [WIN] Build fix after r123417.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

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

        Move GregorianDateTime from JSC to WTF namespace
        https://bugs.webkit.org/show_bug.cgi?id=91948

        Reviewed by Geoffrey Garen.

        Moving GregorianDateTime into the WTF namespace allows us to us to
        use it in WebCore too. The new class has the same behaviour as the
        old struct. Only the unused timeZone member has been removed.

        * runtime/DateConstructor.cpp:
        * runtime/DateConversion.cpp:
        * runtime/DateConversion.h:
        * runtime/DateInstance.h:
        * runtime/DatePrototype.cpp:
        * runtime/JSDateMath.cpp:
        * runtime/JSDateMath.h:

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

        Property storage should grow in reverse address direction, to support butterflies
        https://bugs.webkit.org/show_bug.cgi?id=91788

        Reviewed by Geoffrey Garen.

        Changes property storage to grow to the left, and changes the property storage pointer to point
        one 8-byte word (i.e. JSValue) to the right of the first value in the storage.
        
        Also improved debug support somewhat, by adding a describe() function to the jsc command-line,
        and a slow mode of object access in LLInt.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::repatchCompact):
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::isCompactPtrAlignedAddressOffset):
        (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::isCompactPtrAlignedAddressOffset):
        (JSC::MacroAssemblerX86Common::repatchCompact):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::repatchCompact):
        * bytecode/CodeBlock.cpp:
        (JSC::dumpStructure):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddPointer):
        * heap/CopiedSpace.h:
        (CopiedSpace):
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::pinIfNecessary):
        (JSC):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::compileGetDirectOffset):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::compileGetDirectOffset):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::tryCacheGetByID):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDescribe):
        * llint/LLIntCommon.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
        (JSC::JSFinalObject::visitChildren):
        (JSC::JSObject::growOutOfLineStorage):
        * runtime/JSObject.h:
        (JSC::JSObject::getDirectLocation):
        (JSC::JSObject::offsetForLocation):
        * runtime/JSValue.h:
        (JSValue):
        * runtime/PropertyOffset.h:
        (JSC::offsetInOutOfLineStorage):

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

        DFG is too aggressive in performing the specific value optimization on loads
        https://bugs.webkit.org/show_bug.cgi?id=92034

        Reviewed by Mark Hahnenberg.

        This ensures that we don't do optimizations based on a structure having a specific
        value, if there is no way to detect that the value is despecified. This is the
        case for dictionaries, since despecifying a value in a dictionary does not lead to
        a transition and so cannot be caught by either structure checks or structure
        transition watchpoints.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForChain):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):

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

        REGRESSION(r123169): It made fast/js/dfg-inline-arguments-use-from-uninlined-code.html fail on 32 bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=92002

        Reviewed by Mark Hahnenberg.
        
        In the process of changing the nature of local variable typing, I forgot to modify one of the places where
        we glue the DFG's notion of variable prediction to the runtime's notion of variable tagging.

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

2012-07-23  Simon Fraser  <simon.fraser@apple.com>

        Part 2 of: Implement sticky positioning
        https://bugs.webkit.org/show_bug.cgi?id=90046

        Reviewed by Ojan Vafai.

        Turn on ENABLE_CSS_STICKY_POSITION.

        * Configurations/FeatureDefines.xcconfig:

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

        Move JSC::parseDate() from DateConversion to JSDateMath
        https://bugs.webkit.org/show_bug.cgi?id=91982

        Reviewed by Geoffrey Garen.

        Moveing this function into the other files removes the dependency
        on JSC spcific classes in DateConversion.{cpp|h}.

        * runtime/DateConversion.cpp:
        * runtime/DateConversion.h:
        (JSC):
        * runtime/JSDateMath.cpp:
        (JSC::parseDate):
        (JSC):
        * runtime/JSDateMath.h:
        (JSC):

2012-07-23  Simon Fraser  <simon.fraser@apple.com>

        Part 1 of: Implement sticky positioning
        https://bugs.webkit.org/show_bug.cgi?id=90046

        Reviewed by Ojan Vafai.

        Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially.
        
        Sort the ENABLE_CSS lines in the file. Make sure all the flags
        are in FEATURE_DEFINES.

        * Configurations/FeatureDefines.xcconfig:

2012-07-23  Yong Li  <yoli@rim.com>

        [BlackBerry] Implement GCActivityCallback with platform timer
        https://bugs.webkit.org/show_bug.cgi?id=90175

        Reviewed by Rob Buis.

        Use JSLock when performing GC to avoid assertions.

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

2012-07-23  Kent Tamura  <tkent@chromium.org>

        Rename ENABLE_METER_TAG and ENABLE_PROGRESS_TAG to ENABLE_METER_ELEMENT and ENABLE_PROGRESS_ELEMENT respectively
        https://bugs.webkit.org/show_bug.cgi?id=91941

        Reviewed by Kentaro Hara.

        A flag name for an elmement should be ENABLE_*_ELEMENT.

        * Configurations/FeatureDefines.xcconfig:

2012-07-22  Kent Tamura  <tkent@chromium.org>

        Rename ENABLE_DETAILS to ENABLE_DETAILS_ELEMENT
        https://bugs.webkit.org/show_bug.cgi?id=91928

        Reviewed by Kentaro Hara.

        A flag name for an elmement should be ENABLE_*_ELEMENT.

        * Configurations/FeatureDefines.xcconfig:

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

        [WIN] Use GetDateFormat and GetTimeFormat instead of strftime
        https://bugs.webkit.org/show_bug.cgi?id=83436

        Reviewed by Brent Fulgham.

        The MS CRT implementation of strftime calls the same two functions.
        Using them directly avoids the overhead of parsing the format string and removes
        the dependency on strftime() for WinCE where this function does not exist.

        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):

2012-07-20  Kent Tamura  <tkent@chromium.org>

        Rename ENABLE_DATALIST to ENABLE_DATALIST_ELEMENT
        https://bugs.webkit.org/show_bug.cgi?id=91846

        Reviewed by Kentaro Hara.

        A flag name for an elmement should be ENABLE_*_ELEMENT.

        * Configurations/FeatureDefines.xcconfig:

2012-07-20  Han Shen  <shenhan@google.com>

        [Chromium] Compilation fails under gcc 4.7
        https://bugs.webkit.org/show_bug.cgi?id=90227

        Reviewed by Tony Chang.

        Disable warnings about c++0x compatibility in gcc newer than 4.6.

        * JavaScriptCore.gyp/JavaScriptCore.gyp:

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

        DFG cell checks should be hoisted
        https://bugs.webkit.org/show_bug.cgi?id=91717

        Reviewed by Geoffrey Garen.

        The DFG has always had the policy of hoisting array and integer checks to
        the point of variable assignment. Eventually, we added doubles and booleans
        to the mix. But cells should really be part of this as well, particularly
        for 32-bit where accessing a known-type variable is dramatically cheaper
        than accessing a variable whose types is only predicted but otherwise
        unproven.
        
        This appears to be a definite speed-up for V8 on 32-bit, a possible speed-up
        for Kraken, and a possible slow-down for V8 on 64-bit (around 0.2% if at
        all). Any slow-downs can, and should, be addressed by making the hoisting
        logic cognizant of variables that are never used in a manner that requires
        type checks, and by sinking argument checks to the point(s) of first use.
        
        To make this work I had to change some OSR machinery, and special-case the
        type predictions of the 'this' argument for constructors. OSR exit normally
        assumes that arguments are boxed, which happens to be true because the
        type prediction used for check hoisting is LUB'd with the type of the
        argument that was passed in - so either the arguments are always stored to
        with the full tag+payload, or if only the payload is stored then the tag
        matches whatever the caller would have set. But not so with the 'this'
        argument for constructors, which is not initialized by the caller. We
        could make this more precise by having argument types for OSR be inferred
        using similar machinery to other locals, but I figured that for this patch
        I should use the surgical fix.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchTestPtr):
        (MacroAssemblerX86_64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::testq_rm):
        (X86Assembler):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isCreatedThisArgument):
        (Graph):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValueSource.h:
        (JSC::DFG::ValueSource::forSpeculation):

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

        Fast path of storage resize should be removed from property storage reallocation, since it is only useful for arrays
        https://bugs.webkit.org/show_bug.cgi?id=91796

        Reviewed by Geoffrey Garen.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * runtime/JSObject.cpp:
        (JSC::JSObject::growOutOfLineStorage):

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

        Bug fixes and enhancements for OfflineASM annotation system.
        https://bugs.webkit.org/show_bug.cgi?id=91690

        Reviewed by Filip Pizlo.

        * offlineasm/armv7.rb: added default handling of Instruction lower().
        * offlineasm/asm.rb: added more support for annotations and more pretty printing.
        * offlineasm/ast.rb: added more support for annotations.
        * offlineasm/config.rb: added $preferredCommentStartColumn, simplified $enableInstrAnnotations.
        * offlineasm/parser.rb: added more support for annotations.
        * offlineasm/transform.rb: added more support for annotations.
        * offlineasm/x86.rb: added default handling of Instruction lower().

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

        [WIN] Fix compilation of JSGlobalData.h with ENABLE(DFG_JIT)
        https://bugs.webkit.org/show_bug.cgi?id=91243

        Reviewed by Geoffrey Garen.

        Disable MSVC warning 4200 "zero-sized array in struct/union" for JSC::ScratchBuffer.

        * runtime/JSGlobalData.h:
        (JSC):

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

        Fixed broken ENABLE_JIT=0 build.
        https://bugs.webkit.org/show_bug.cgi?id=91725

        Reviewed by Oliver Hunt.

        * bytecode/Watchpoint.cpp:
        * heap/JITStubRoutineSet.h:
        (JSC):
        (JITStubRoutineSet):
        (JSC::JITStubRoutineSet::JITStubRoutineSet):
        (JSC::JITStubRoutineSet::~JITStubRoutineSet):
        (JSC::JITStubRoutineSet::add):
        (JSC::JITStubRoutineSet::clearMarks):
        (JSC::JITStubRoutineSet::mark):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        (JSC::JITStubRoutineSet::traceMarkedStubRoutines):

2012-07-19  Kristóf Kosztyó  <kkristof@inf.u-szeged.hu>

        [Qt] Unreviewed buildfix after r123042.

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

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

        DFG should emit inline code for property storage (re)allocation
        https://bugs.webkit.org/show_bug.cgi?id=91597

        Reviewed by Oliver Hunt.

        This adds two new ops to the DFG IR: AllocatePropertyStorage and
        ReallocatePropertyStorage. It enables these to interact properly with
        CSE so that a GetPropertyStorage on something for which we have
        obviously done a (Re)AllocatePropertyStorage will result in the
        GetPropertyStorage being eliminated. Other than that, the code
        emitted for these ops is identical to the code we were emitting in
        the corresponding PutById stub.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasStructureTransitionData):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/Structure.cpp:
        (JSC::nextOutOfLineStorageCapacity):
        * runtime/Structure.h:
        (JSC):

2012-07-16  Oliver Hunt  <oliver@apple.com>

        dumpCallFrame is broken in ToT
        https://bugs.webkit.org/show_bug.cgi?id=91444

        Reviewed by Gavin Barraclough.

        Various changes have been made to the SF calling convention, but
        dumpCallFrame has not been updated to reflect these changes.
        That resulted in both bogus information, as well as numerous
        assertions of sadness.

        This patch makes dumpCallFrame actually work again and adds the
        wonderful feature of telling you the name of the variable that a
        register reflects, or what value it contains.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister):
            A really innefficient mechanism for finding the name of a local register.
            This should only ever be used by debug code so this should be okay.
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
            Debug builds no longer throw away a functions symbol table, this allows
            us to actually perform a register# to name mapping
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
            We weren't propogating the bytecode offset here leading to assertions
            in debug builds when dumping bytecode of DFG compiled code.
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::Interpreter::dumpRegisters):
             Rework to actually be correct.
        (JSC::getCallerInfo):
             Return the byteocde offset as well now, given we have to determine it
             anyway.
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::retrieveCallerFromVMCode):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDumpCallFrame):
             Give debug builds of JSC a method for calling dumpCallFrame so we can
             inspect a callframe without requiring us to break in a debugger.

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

        DFG 32-bit PutById transition stub storage reallocation case copies the first pointer of each JSValue instead of the whole JSValue
        https://bugs.webkit.org/show_bug.cgi?id=91599

        Reviewed by Geoffrey Garen.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::emitPutTransitionStub):

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

        DFG 32-bit PutById transition stub passes the payload/tag arguments to a DFG operation in the wrong order
        https://bugs.webkit.org/show_bug.cgi?id=91576

        Reviewed by Gavin Barraclough.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::emitPutTransitionStub):

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

        [Qt] REGRESSION(r122768, r122771): They broke jquery/data.html and inspector/elements/edit-dom-actions.html
        https://bugs.webkit.org/show_bug.cgi?id=91476

        Reviewed by Mark Hahnenberg.

        The 32-bit repatching code was not correctly adapted to the new world where there may not always
        be an available scratch register. Fixed it by ensuring that the scratch register we select does
        not overlap with the value tag.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):

2012-07-17  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed buildfix from Zoltan Herczeg after 122768.

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

2012-07-17  David Barr  <davidbarr@chromium.org>

        Introduce ENABLE_CSS_IMAGE_ORIENTATION compile flag
        https://bugs.webkit.org/show_bug.cgi?id=89055

        Reviewed by Kent Tamura.

        The css3-images module is at candidate recommendation.
        http://www.w3.org/TR/2012/CR-css3-images-20120417/#the-image-orientation

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

        * Configurations/FeatureDefines.xcconfig:

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

        Unreviewed, roll out 122790 because it broke the Windows build. I'm not
        sure what to do with exported symbols that are predicated on NDEBUG.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * bytecode/CodeBlock.cpp:
        (JSC):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::Interpreter::dumpRegisters):
        (JSC::getCallerInfo):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::retrieveCallerFromVMCode):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jsc.cpp:
        (GlobalObject::finishCreation):

2012-07-16  Oliver Hunt  <oliver@apple.com>

        dumpCallFrame is broken in ToT
        https://bugs.webkit.org/show_bug.cgi?id=91444

        Reviewed by Gavin Barraclough.

        Various changes have been made to the SF calling convention, but
        dumpCallFrame has not been updated to reflect these changes.
        That resulted in both bogus information, as well as numerous
        assertions of sadness.

        This patch makes dumpCallFrame actually work again and adds the
        wonderful feature of telling you the name of the variable that a
        register reflects, or what value it contains.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister):
            A really innefficient mechanism for finding the name of a local register.
            This should only ever be used by debug code so this should be okay.
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
            Debug builds no longer throw away a functions symbol table, this allows
            us to actually perform a register# to name mapping
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
            We weren't propogating the bytecode offset here leading to assertions
            in debug builds when dumping bytecode of DFG compiled code.
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::Interpreter::dumpRegisters):
             Rework to actually be correct.
        (JSC::getCallerInfo):
             Return the byteocde offset as well now, given we have to determine it
             anyway.
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::retrieveCallerFromVMCode):
        * interpreter/Interpreter.h:
        (Interpreter):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDumpCallFrame):
             Give debug builds of JSC a method for calling dumpCallFrame so we can
             inspect a callframe without requiring us to break in a debugger.

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

        Unreviewed, adding forgotten files.

        * dfg/DFGRegisterSet.h: Added.
        (DFG):
        (RegisterSet):
        (JSC::DFG::RegisterSet::RegisterSet):
        (JSC::DFG::RegisterSet::asPOD):
        (JSC::DFG::RegisterSet::copyInfo):
        (JSC::DFG::RegisterSet::set):
        (JSC::DFG::RegisterSet::setGPRByIndex):
        (JSC::DFG::RegisterSet::clear):
        (JSC::DFG::RegisterSet::get):
        (JSC::DFG::RegisterSet::getGPRByIndex):
        (JSC::DFG::RegisterSet::getFreeGPR):
        (JSC::DFG::RegisterSet::setFPRByIndex):
        (JSC::DFG::RegisterSet::getFPRByIndex):
        (JSC::DFG::RegisterSet::setByIndex):
        (JSC::DFG::RegisterSet::getByIndex):
        (JSC::DFG::RegisterSet::numberOfSetGPRs):
        (JSC::DFG::RegisterSet::numberOfSetFPRs):
        (JSC::DFG::RegisterSet::numberOfSetRegisters):
        (JSC::DFG::RegisterSet::setBit):
        (JSC::DFG::RegisterSet::clearBit):
        (JSC::DFG::RegisterSet::getBit):
        * dfg/DFGScratchRegisterAllocator.h: Added.
        (DFG):
        (ScratchRegisterAllocator):
        (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator):
        (JSC::DFG::ScratchRegisterAllocator::lock):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratch):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters):
        (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize):
        (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
        (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):

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

        DFG PutById transition should handle storage allocation, and inline it
        https://bugs.webkit.org/show_bug.cgi?id=91337

        Reviewed by Oliver Hunt.

        This enables the patching of DFG PutById to handle the out-of-line storage
        allocation case. Furthermore, it inlines out-of-line storage allocation (and
        reallocation) into the generated stubs.  
        
        To do this, this patch adds the ability to store the relevant register
        allocation state (i.e. the set of in-use registers) in the structure stub
        info so that the stub generation code can more flexibly select scratch
        registers: sometimes it needs none, sometimes one - or sometimes up to
        three. Moreover, to make the stub generation register allocation simple and
        maintainable, this patch introduces a reusable scratch register allocator
        class. This register allocator understands that some registers are in use by
        the main path code and so must be spilled as necessary, other registers are
        locked for use in the stub itself and so cannot even be spilled, while still
        others may be allocated for scratch purposes. A scratch register that is
        used must be spilled. If a register is locked, it cannot be used as a
        scratch register. If a register is used, it can be used as a scratch
        register so long as it is spilled.
        
        This is a sub-1% speed-up on V8 and neutral elsewhere.

        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerCodeRef.h:
        (FunctionPtr):
        (JSC::FunctionPtr::FunctionPtr):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGGPRInfo.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::PropertyAccessRecord::PropertyAccessRecord):
        (PropertyAccessRecord):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRegisterBank.h:
        (JSC::DFG::RegisterBank::isInUse):
        (RegisterBank):
        * dfg/DFGRegisterSet.h: Added.
        (DFG):
        (RegisterSet):
        (JSC::DFG::RegisterSet::RegisterSet):
        (JSC::DFG::RegisterSet::asPOD):
        (JSC::DFG::RegisterSet::copyInfo):
        (JSC::DFG::RegisterSet::set):
        (JSC::DFG::RegisterSet::setGPRByIndex):
        (JSC::DFG::RegisterSet::clear):
        (JSC::DFG::RegisterSet::get):
        (JSC::DFG::RegisterSet::getGPRByIndex):
        (JSC::DFG::RegisterSet::getFreeGPR):
        (JSC::DFG::RegisterSet::setFPRByIndex):
        (JSC::DFG::RegisterSet::getFPRByIndex):
        (JSC::DFG::RegisterSet::setByIndex):
        (JSC::DFG::RegisterSet::getByIndex):
        (JSC::DFG::RegisterSet::numberOfSetGPRs):
        (JSC::DFG::RegisterSet::numberOfSetFPRs):
        (JSC::DFG::RegisterSet::numberOfSetRegisters):
        (JSC::DFG::RegisterSet::setBit):
        (JSC::DFG::RegisterSet::clearBit):
        (JSC::DFG::RegisterSet::getBit):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::tryBuildPutByIdList):
        * dfg/DFGScratchRegisterAllocator.h: Added.
        (DFG):
        (ScratchRegisterAllocator):
        (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator):
        (JSC::DFG::ScratchRegisterAllocator::lock):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratch):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters):
        (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize):
        (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
        (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::usedRegisters):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * heap/CopiedAllocator.h:
        (CopiedAllocator):
        (JSC::CopiedAllocator::fastPathShouldSucceed):
        (JSC):

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

        Add dfg switch to create_jit_stubs script
        https://bugs.webkit.org/show_bug.cgi?id=91256

        Reviewed by Geoffrey Garen.

        * create_jit_stubs: Add a switch to enable or disable the generation of
                            stub functions in #if ENABLE(DFG_JIT) conditions.

2012-07-16  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed buildfix after r122729. Typo fix.

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

2012-07-16  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed buildfix from Zoltan Herczeg after r122677.
        Implement missing add32 function to MacroAssemblerARM.

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

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

        DFG PutByVal opcodes should accept more than 3 operands
        https://bugs.webkit.org/show_bug.cgi?id=91332

        Reviewed by Oliver Hunt.

        Turned PutByVal/PutByValAlias into var-arg nodes, so that we can give them
        4 or more operands in the future.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getByValLoadElimination):
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixDoubleEdge):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        (JSC::DFG::Graph::varArgNumChildren):
        (Graph):
        (JSC::DFG::Graph::numChildren):
        (JSC::DFG::Graph::varArgChild):
        (JSC::DFG::Graph::child):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        Rationalize and optimize storage allocation
        https://bugs.webkit.org/show_bug.cgi?id=91303

        Reviewed by Oliver Hunt.

        This implements a backwards bump allocator for copied space storage
        allocation, shown in pseudo-code below:
        
            pointer bump(size) {
                pointer tmp = allocator->remaining;
                tmp -= size;
                if (tmp < 0)
                    fail;
                allocator->remaining = tmp;
                return allocator->payloadEnd - tmp - size;
            }

        The advantage of this allocator is that it:
        
        - Only requires one comparison in the common case where size is known to
          not be huge, and this comparison can be done by checking the sign bit
          of the subtraction.
        
        - Can be implemented even when only one register is available. This
          register is reused for both temporary storage during allocation and
          for the result.
        
        - Preserves the behavior that memory in a block is filled in from lowest
          address to highest address, which allows for a cheap reallocation fast
          path.
        
        - Is resilient against the block used for allocation being the last one
          in virtual memory, thereby otherwise leading to the risk of overflow
          in the bump pointer, despite only doing one branch.
        
        In order to implement this allocator using the smallest possible chunk
        of code, I refactored the copied space code so that all of the allocation
        logic is in CopiedAllocator, and all of the state is in either
        CopiedBlock or CopiedAllocator. This should make changing the allocation
        fast path easier in the future.
        
        In order to do this, I needed to add some new assembler support,
        particularly for various forms of add(address, register) and negPtr().
        
        This is performance neutral. The purpose of this change is to facilitate
        further inlining of storage allocation without having to reserve
        additional registers or emit too much code.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::addPtr):
        (MacroAssembler):
        (JSC::MacroAssembler::negPtr):
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::add32):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::add32):
        (MacroAssemblerX86):
        * assembler/MacroAssemblerX86_64.h:
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::addPtr):
        (JSC::MacroAssemblerX86_64::negPtr):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::addl_mr):
        (JSC::X86Assembler::addq_mr):
        (JSC::X86Assembler::negq_r):
        * heap/CopiedAllocator.h:
        (CopiedAllocator):
        (JSC::CopiedAllocator::isValid):
        (JSC::CopiedAllocator::CopiedAllocator):
        (JSC::CopiedAllocator::tryAllocate):
        (JSC):
        (JSC::CopiedAllocator::tryReallocate):
        (JSC::CopiedAllocator::forceAllocate):
        (JSC::CopiedAllocator::resetCurrentBlock):
        (JSC::CopiedAllocator::setCurrentBlock):
        (JSC::CopiedAllocator::currentCapacity):
        * heap/CopiedBlock.h:
        (CopiedBlock):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::zeroFillWilderness):
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::payloadEnd):
        (JSC):
        (JSC::CopiedBlock::payloadCapacity):
        (JSC::CopiedBlock::data):
        (JSC::CopiedBlock::dataEnd):
        (JSC::CopiedBlock::dataSize):
        (JSC::CopiedBlock::wilderness):
        (JSC::CopiedBlock::wildernessEnd):
        (JSC::CopiedBlock::wildernessSize):
        (JSC::CopiedBlock::size):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateSlowCase):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocate):
        (JSC::CopiedSpace::doneFillingBlock):
        (JSC::CopiedSpace::doneCopying):
        * heap/CopiedSpace.h:
        (CopiedSpace):
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::startedCopying):
        (JSC::CopiedSpace::allocateBlockForCopyingPhase):
        (JSC::CopiedSpace::allocateBlock):
        (JSC::CopiedSpace::tryAllocate):
        (JSC):
        * heap/MarkStack.cpp:
        (JSC::SlotVisitor::startCopying):
        (JSC::SlotVisitor::allocateNewSpace):
        (JSC::SlotVisitor::doneCopying):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::SlotVisitor):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicStorage):
        (JSC::JIT::emitAllocateJSArray):

2012-07-13  Mark Lam  <mark.lam@apple.com>

        OfflineASM Pretty printing and commenting enhancements.
        https://bugs.webkit.org/show_bug.cgi?id=91281

        Reviewed by Filip Pizlo.

        Added some minor pretty printing in the OfflineASM.
        Also added infrastruture for adding multiple types of comments and
        annotations with the ability to enable/disable them in the generated
        output as desired.

        * GNUmakefile.list.am: add new file config.rb.
        * llint/LLIntOfflineAsmConfig.h:
          Added OFFLINE_ASM_BEGIN, OFFLINE_ASM_END, and OFFLINE_ASM_LOCAL_LABEL macros.
          This will allow us to redefine these for other backends later.
        * llint/LowLevelInterpreter32_64.asm:
          Add a small example of instruction annotations for now.
        * llint/LowLevelInterpreter64.asm:
          Add a small example of instruction annotations for now.
        * offlineasm/armv7.rb: Added handling of annotations.
        * offlineasm/asm.rb:
          Added machinery to dump the new comments and annotations.
          Also added some indentations to make the output a little prettier.
        * offlineasm/ast.rb: Added annotation field in class Instruction. 
        * offlineasm/backends.rb:
        * offlineasm/config.rb: Added.
          Currently only contains commenting options.  This file is meant to be
          a centralized place for build config values much like config.h for
          JavaScriptCore.
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/instructions.rb:
        * offlineasm/offsets.rb:
        * offlineasm/opt.rb:
        * offlineasm/parser.rb: Parse and record annotations.
        * offlineasm/registers.rb:
        * offlineasm/self_hash.rb:
        * offlineasm/settings.rb:
        * offlineasm/transform.rb:
        * offlineasm/x86.rb: Added handling of annotations.

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

        ASSERTION FAILED: use.useKind() != DoubleUse
        https://bugs.webkit.org/show_bug.cgi?id=91082

        Reviewed by Geoffrey Garen.

        The implementation of Branch() was unwisely relying on register allocation state
        to decide what speculations to perform. That's never correct.

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

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

        Unreviewed, rolling out r122640.
        http://trac.webkit.org/changeset/122640
        https://bugs.webkit.org/show_bug.cgi?id=91298

        LLInt apparently does not expect to mark these (Requested by
        olliej on #webkit).

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

2012-07-13  Oliver Hunt  <oliver@apple.com>

        LLInt fails to mark structures stored in the bytecode
        https://bugs.webkit.org/show_bug.cgi?id=91296

        Reviewed by Geoffrey Garen.

        LLInt stores structures in the bytecode, so we need to visit the appropriate
        instructions as we would if we were running in the classic interpreter.
        This requires adding additional checks for the LLInt specific opcodes, and
        the lint specific variants of operand ordering. 

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

2012-07-13  Yong Li  <yoli@rim.com>

        [BlackBerry] Implement GCActivityCallback with platform timer
        https://bugs.webkit.org/show_bug.cgi?id=90175

        Reviewed by Rob Buis.

        Implement GCActivityCallback and HeapTimer for BlackBerry port.

        * heap/HeapTimer.cpp:
        (JSC):
        (JSC::HeapTimer::HeapTimer):
        (JSC::HeapTimer::~HeapTimer):
        (JSC::HeapTimer::timerDidFire):
        (JSC::HeapTimer::synchronize):
        (JSC::HeapTimer::invalidate):
        (JSC::HeapTimer::didStartVMShutdown):
        * heap/HeapTimer.h:
        (HeapTimer):
        * runtime/GCActivityCallbackBlackBerry.cpp:
        (JSC):
        (JSC::DefaultGCActivityCallback::doWork):
        (JSC::DefaultGCActivityCallback::didAllocate):
        (JSC::DefaultGCActivityCallback::willCollect):
        (JSC::DefaultGCActivityCallback::cancel):

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

        [WIN] Fix compilation of DFGRepatch.cpp
        https://bugs.webkit.org/show_bug.cgi?id=91241

        Reviewed by Geoffrey Garen.

        Use intptr_t instead of uintptr_t when calling CodeLocationCommon::dataLabelPtrAtOffset(int)
        to fix MSVC "unary minus operator applied to unsigned type, result still unsigned" warning.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::dfgResetGetByID):
        (JSC::DFG::dfgResetPutByID):

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

        Fix ARM_TRADITIONAL JIT for COMPILER(MSVC) and COMPILER(RVCT) after r121885
        https://bugs.webkit.org/show_bug.cgi?id=91238

        Reviewed by Zoltan Herczeg.

        r121885 changed the assembler instruction only for COMPILER(GCC).
        Use the same instructions for the other compilers too.

        * jit/JITStubs.cpp:
        (JSC::ctiTrampoline):
        (JSC::ctiTrampolineEnd):
        (JSC::ctiVMThrowTrampoline):

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

        DFG property access stubs should use structure transition watchpoints
        https://bugs.webkit.org/show_bug.cgi?id=91135

        Reviewed by Geoffrey Garen.

        This adds a Watchpoint subclass that will clear a structure stub (i.e.
        a property access stub) when fired. The DFG stub generation code now
        uses this optimization.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::resetStub):
        (JSC::CodeBlock::resetStubInternal):
        * bytecode/CodeBlock.h:
        (JSC):
        (CodeBlock):
        * bytecode/StructureStubClearingWatchpoint.cpp: Added.
        (JSC):
        (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint):
        (JSC::StructureStubClearingWatchpoint::push):
        (JSC::StructureStubClearingWatchpoint::fireInternal):
        (JSC::WatchpointsOnStructureStubInfo::~WatchpointsOnStructureStubInfo):
        (JSC::WatchpointsOnStructureStubInfo::addWatchpoint):
        (JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint):
        * bytecode/StructureStubClearingWatchpoint.h: Added.
        (JSC):
        (StructureStubClearingWatchpoint):
        (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
        (WatchpointsOnStructureStubInfo):
        (JSC::WatchpointsOnStructureStubInfo::WatchpointsOnStructureStubInfo):
        (JSC::WatchpointsOnStructureStubInfo::codeBlock):
        (JSC::WatchpointsOnStructureStubInfo::stubInfo):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::reset):
        (JSC::StructureStubInfo::addWatchpoint):
        (StructureStubInfo):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::addStructureTransitionCheck):
        (DFG):
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::emitPutTransitionStub):
        * jit/JumpReplacementWatchpoint.h:

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

        DFG CFA may get overzealous in loops that have code that must exit
        https://bugs.webkit.org/show_bug.cgi?id=91188

        Reviewed by Gavin Barraclough.

        Ensure that if the CFA assumes that an operation must exit, then it will always exit
        no matter what happens after. That's necessary to preserve soundness.
        
        Remove a broken fixup done by the DFG simplifier, where it was trying to say that the
        variable-at-head was the first access in the second block in the merge, if the first
        block did not read the variable. That's totally wrong, if the first block was in fact
        doing a phantom read. I removed that fixup and instead hardened the rest of the
        compiler.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::endBasicBlock):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::BasicBlock):
        (BasicBlock):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase):
        (JSC::DFG::ConstantFoldingPhase::run):
        (ConstantFoldingPhase):
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):

2012-07-12  Allan Sandfeld Jensen  <allan.jensen@nokia.com>

        [Qt] Implement MemoryUsageSupport
        https://bugs.webkit.org/show_bug.cgi?id=91094

        Reviewed by Adam Barth.

        Compile in MemoryStatistics so we can make use of the interface.

        * Target.pri:

2012-07-12  Csaba Osztrogonác  <ossy@webkit.org>

        Remove dead code after r122392.
        https://bugs.webkit.org/show_bug.cgi?id=91049

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):

2012-07-11  Adenilson Cavalcanti  <cavalcantii@gmail.com>

        Build fix + remove dead code
        https://bugs.webkit.org/show_bug.cgi?id=91039

        Reviewed by Filip Pizlo.

        An unused variable was breaking compilation (thanks to warnings being treated as errors).

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

2012-07-11  Mark Rowe  <mrowe@apple.com>

        <http://webkit.org/b/91024> Build against the latest SDK when targeting older OS X versions.

        Reviewed by Dan Bernstein.

        The deployment target is already set to the version that we're targeting, and it's that setting
        which determines which functionality from the SDK is available to us.

        * Configurations/Base.xcconfig:

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

        DFG should have fast virtual calls
        https://bugs.webkit.org/show_bug.cgi?id=90924

        Reviewed by Gavin Barraclough.
        
        Implements virtual call support in the style of the old JIT, with the
        caveat that we still use the same slow path for both InternalFunction
        calls and JSFunction calls. Also rationalized the way that our
        CodeOrigin indices tie into exception checks (previously it was a
        strange one-to-one mapping with fairly limited assertions; now it's a
        one-to-many mapping for CodeOrigins to exception checks, respectively).
        I also took the opportunity to clean up
        CallLinkInfo::callReturnLocation, which previously was either a Call or
        a NearCall. Now it's just a NearCall. As well, exceptions during slow
        path call resolution are now handled by returning an exception throwing
        thunk rather than returning null. And finally, I made a few things
        public that were previously private-with-lots-of-friends, because I
        truly despise the thought of listing each thunk generating function as
        a friend of JSValue and friends.
        
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        * bytecode/CallLinkInfo.h:
        (CallLinkInfo):
        * bytecode/CodeOrigin.h:
        (JSC::CodeOrigin::CodeOrigin):
        (JSC::CodeOrigin::isSet):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::AssemblyHelpers):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::CCallHelpers):
        * dfg/DFGGPRInfo.h:
        (GPRInfo):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::CallBeginToken::CallBeginToken):
        (JSC::DFG::CallBeginToken::~CallBeginToken):
        (CallBeginToken):
        (JSC::DFG::CallBeginToken::set):
        (JSC::DFG::CallBeginToken::registerWithExceptionCheck):
        (JSC::DFG::CallBeginToken::codeOrigin):
        (JSC::DFG::CallExceptionRecord::CallExceptionRecord):
        (CallExceptionRecord):
        (JSC::DFG::JITCompiler::currentCodeOriginIndex):
        (JITCompiler):
        (JSC::DFG::JITCompiler::beginCall):
        (JSC::DFG::JITCompiler::notifyCall):
        (JSC::DFG::JITCompiler::prepareForExceptionCheck):
        (JSC::DFG::JITCompiler::addExceptionCheck):
        (JSC::DFG::JITCompiler::addFastExceptionCheck):
        * dfg/DFGOperations.cpp:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::dfgLinkFor):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::emitPointerValidation):
        (DFG):
        (JSC::DFG::throwExceptionFromCallSlowPathGenerator):
        (JSC::DFG::slowPathFor):
        (JSC::DFG::linkForThunkGenerator):
        (JSC::DFG::linkCallThunkGenerator):
        (JSC::DFG::linkConstructThunkGenerator):
        (JSC::DFG::virtualForThunkGenerator):
        (JSC::DFG::virtualCallThunkGenerator):
        (JSC::DFG::virtualConstructThunkGenerator):
        * dfg/DFGThunks.h:
        (DFG):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        (JSC::JIT::linkFor):
        * runtime/Executable.h:
        (ExecutableBase):
        (JSC::ExecutableBase::offsetOfJITCodeFor):
        (JSC::ExecutableBase::offsetOfNumParametersFor):
        * runtime/JSValue.h:
        (JSValue):

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

        Accidentally used the wrong license (3-clause instead of 2-clause) in some
        files I just committed.

        Rubber stamped by Oliver Hunt.

        * bytecode/Watchpoint.cpp:
        * bytecode/Watchpoint.h:
        * jit/JumpReplacementWatchpoint.cpp:
        * jit/JumpReplacementWatchpoint.h:

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

        Watchpoints and jump replacement should be decoupled
        https://bugs.webkit.org/show_bug.cgi?id=91016

        Reviewed by Oliver Hunt.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/AbstractMacroAssembler.h:
        (JSC):
        (Label):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::appendWatchpoint):
        (JSC::CodeBlock::watchpoint):
        (DFGData):
        * bytecode/Watchpoint.cpp:
        (JSC):
        * bytecode/Watchpoint.h:
        (JSC::Watchpoint::Watchpoint):
        (Watchpoint):
        (JSC::Watchpoint::fire):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        * jit/JumpReplacementWatchpoint.cpp: Added.
        (JSC):
        (JSC::JumpReplacementWatchpoint::correctLabels):
        (JSC::JumpReplacementWatchpoint::fireInternal):
        * jit/JumpReplacementWatchpoint.h: Added.
        (JSC):
        (JumpReplacementWatchpoint):
        (JSC::JumpReplacementWatchpoint::JumpReplacementWatchpoint):
        (JSC::JumpReplacementWatchpoint::setDestination):

2012-07-11  Kevin Ollivier  <kevino@theolliviers.com>

        [wx] Unreviewed build fix. Don't try to build udis86_itab.c since it's included by 
        another file.

        * wscript:

2012-07-11  Chao-ying Fu  <fu@mips.com>

        Add MIPS convertibleLoadPtr and other functions
        https://bugs.webkit.org/show_bug.cgi?id=90714

        Reviewed by Oliver Hunt.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::labelIgnoringWatchpoints):
        (MIPSAssembler):
        (JSC::MIPSAssembler::replaceWithLoad):
        (JSC::MIPSAssembler::replaceWithAddressComputation):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::convertibleLoadPtr):
        (MacroAssemblerMIPS):

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

        Add -Wtautological-compare and -Wsign-compare warning flags
        https://bugs.webkit.org/show_bug.cgi?id=90994

        Reviewed by Mark Rowe.

        * Configurations/Base.xcconfig:

2012-07-11  Benjamin Poulain  <bpoulain@apple.com>

        Simplify the copying of JSC ARMv7's LinkRecord
        https://bugs.webkit.org/show_bug.cgi?id=90930

        Reviewed by Filip Pizlo.

        The class LinkRecord is used by value everywhere in ARMv7Assembler. The compiler uses
        memmove() to move the objects.

        The problem is memmove() is overkill for this object, moving the value can be done with
        3 load-store. This patch adds an operator= to the class doing more efficient copying.
        This reduces the link time by 19%.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::LinkRecord::LinkRecord):
        (JSC::ARMv7Assembler::LinkRecord::operator=):
        (JSC::ARMv7Assembler::LinkRecord::from):
        (JSC::ARMv7Assembler::LinkRecord::setFrom):
        (JSC::ARMv7Assembler::LinkRecord::to):
        (JSC::ARMv7Assembler::LinkRecord::type):
        (JSC::ARMv7Assembler::LinkRecord::linkType):
        (JSC::ARMv7Assembler::LinkRecord::setLinkType):
        (JSC::ARMv7Assembler::LinkRecord::condition):

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

        jsc: Parse options before creating global data
        https://bugs.webkit.org/show_bug.cgi?id=90975

        Reviewed by Filip Pizlo.

        This patch moves the options parsing in "jsc" before the creation
        of the JSGlobalData, so that --useJIT=no has a chance to take
        effect.

        * jsc.cpp:
        (CommandLine::parseArguments): Refactor to be a class, and take
        argc and argv as constructor arguments.
        (jscmain): Move arg parsing before JSGlobalData creation.

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

        REGRESSION(r122166): It made 170 tests crash on 32 bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=90852

        Reviewed by Zoltan Herczeg.
        
        If we can't use the range filter, we should still make sure that the
        address is remotely sane, otherwise the hashtables will assert.

        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::passesFilter):

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

        DFG recompilation heuristics should be based on count, not rate
        https://bugs.webkit.org/show_bug.cgi?id=90146

        Reviewed by Oliver Hunt.
        
        Rolling r121511 back in after fixing the DFG's interpretation of op_div
        profiling, with Gavin's rubber stamp.

        This removes a bunch of code that was previously trying to prevent spurious
        reoptimizations if a large enough majority of executions of a code block did
        not result in OSR exit. It turns out that this code was purely harmful. This
        patch removes all of that logic and replaces it with a dead-simple
        heuristic: if you exit more than N times (where N is an exponential function
        of the number of times the code block has already been recompiled) then we
        will recompile.
        
        This appears to be a broad ~1% win on many benchmarks large and small.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (CodeBlock):
        (JSC::CodeBlock::osrExitCounter):
        (JSC::CodeBlock::countOSRExit):
        (JSC::CodeBlock::addressOfOSRExitCounter):
        (JSC::CodeBlock::offsetOfOSRExitCounter):
        (JSC::CodeBlock::adjustedExitCountThreshold):
        (JSC::CodeBlock::exitCountThresholdForReoptimization):
        (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
        (JSC::CodeBlock::shouldReoptimizeNow):
        (JSC::CodeBlock::shouldReoptimizeFromLoopNow):
        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter::setThreshold):
        * bytecode/ExecutionCounter.h:
        (ExecutionCounter):
        (JSC::ExecutionCounter::clippedThreshold):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeDivSafe):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileBody):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::handleExitCounts):
        * dfg/DFGOperations.cpp:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Options.h:
        (JSC):

2012-07-09  Matt Falkenhagen  <falken@chromium.org>

        Add ENABLE_DIALOG_ELEMENT and skeleton files
        https://bugs.webkit.org/show_bug.cgi?id=90521

        Reviewed by Kent Tamura.

        * Configurations/FeatureDefines.xcconfig:

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

        Unreviewed, roll out http://trac.webkit.org/changeset/121511
        It made in-browser V8v7 10% slower.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::countSpeculationSuccess):
        (JSC::CodeBlock::countSpeculationFailure):
        (JSC::CodeBlock::speculativeSuccessCounter):
        (JSC::CodeBlock::speculativeFailCounter):
        (JSC::CodeBlock::forcedOSRExitCounter):
        (JSC::CodeBlock::addressOfSpeculativeSuccessCounter):
        (JSC::CodeBlock::addressOfSpeculativeFailCounter):
        (JSC::CodeBlock::addressOfForcedOSRExitCounter):
        (JSC::CodeBlock::offsetOfSpeculativeSuccessCounter):
        (JSC::CodeBlock::offsetOfSpeculativeFailCounter):
        (JSC::CodeBlock::offsetOfForcedOSRExitCounter):
        (JSC::CodeBlock::largeFailCountThreshold):
        (JSC::CodeBlock::largeFailCountThresholdForLoop):
        (JSC::CodeBlock::shouldReoptimizeNow):
        (JSC::CodeBlock::shouldReoptimizeFromLoopNow):
        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter::setThreshold):
        * bytecode/ExecutionCounter.h:
        (ExecutionCounter):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileBody):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::handleExitCounts):
        * dfg/DFGOperations.cpp:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Options.h:
        (JSC):

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

        DFG may get stuck in an infinite fix point if it constant folds a mispredicted node
        https://bugs.webkit.org/show_bug.cgi?id=90829
        <rdar://problem/11823843>

        Reviewed by Oliver Hunt.
        
        If a node is shown to have been mispredicted during CFA, then don't allow constant
        folding to make the graph even more degenerate. Instead, pull back on constant folding
        and allow the normal OSR machinery to fix our profiling so that a future recompilation
        doesn't see the same mistake.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::trySetConstant):
        (AbstractState):
        * dfg/DFGPhase.h:
        (JSC::DFG::Phase::name):
        (Phase):
        (JSC::DFG::runAndLog):
        (DFG):
        (JSC::DFG::runPhase):

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

        It should be possible to jettison JIT stub routines even if they are currently running
        https://bugs.webkit.org/show_bug.cgi?id=90731

        Reviewed by Gavin Barraclough.
        
        This gives the GC awareness of all JIT-generated stubs for inline caches. That
        means that if you want to delete a JIT-generated stub, you don't have to worry
        about whether or not it is currently running: if there is a chance that it might
        be, the GC will kindly defer deletion until non-running-ness is proved.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/Instruction.h:
        (JSC):
        (PolymorphicStubInfo):
        (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set):
        (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList):
        * bytecode/PolymorphicPutByIdList.cpp:
        (JSC::PutByIdAccess::fromStructureStubInfo):
        * bytecode/PolymorphicPutByIdList.h:
        (JSC::PutByIdAccess::transition):
        (JSC::PutByIdAccess::replace):
        (JSC::PutByIdAccess::stubRoutine):
        (PutByIdAccess):
        (JSC::PolymorphicPutByIdList::currentSlowPathTarget):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::reset):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::tryBuildGetByIDProtoList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::tryBuildPutByIdList):
        * heap/ConservativeRoots.cpp:
        (JSC):
        (DummyMarkHook):
        (JSC::DummyMarkHook::mark):
        (JSC::ConservativeRoots::add):
        (CompositeMarkHook):
        (JSC::CompositeMarkHook::CompositeMarkHook):
        (JSC::CompositeMarkHook::mark):
        * heap/ConservativeRoots.h:
        (JSC):
        (ConservativeRoots):
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        * heap/Heap.h:
        (JSC):
        (Heap):
        * heap/JITStubRoutineSet.cpp: Added.
        (JSC):
        (JSC::JITStubRoutineSet::JITStubRoutineSet):
        (JSC::JITStubRoutineSet::~JITStubRoutineSet):
        (JSC::JITStubRoutineSet::add):
        (JSC::JITStubRoutineSet::clearMarks):
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        (JSC::JITStubRoutineSet::traceMarkedStubRoutines):
        * heap/JITStubRoutineSet.h: Added.
        (JSC):
        (JITStubRoutineSet):
        (JSC::JITStubRoutineSet::mark):
        * heap/MachineStackMarker.h:
        (JSC):
        * interpreter/RegisterFile.cpp:
        (JSC::RegisterFile::gatherConservativeRoots):
        * interpreter/RegisterFile.h:
        (JSC):
        * jit/ExecutableAllocator.cpp:
        (JSC::DemandExecutableAllocator::DemandExecutableAllocator):
        * jit/ExecutableAllocator.h:
        (JSC):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC):
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        * jit/GCAwareJITStubRoutine.cpp: Added.
        (JSC):
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        (JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine):
        (JSC::GCAwareJITStubRoutine::observeZeroRefCount):
        (JSC::GCAwareJITStubRoutine::deleteFromGC):
        (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject):
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject):
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal):
        (JSC::createJITStubRoutine):
        * jit/GCAwareJITStubRoutine.h: Added.
        (JSC):
        (GCAwareJITStubRoutine):
        (JSC::GCAwareJITStubRoutine::markRequiredObjects):
        (MarkingGCAwareJITStubRoutineWithOneObject):
        * jit/JITPropertyAccess.cpp:
        (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::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        * jit/JITStubRoutine.cpp: Added.
        (JSC):
        (JSC::JITStubRoutine::~JITStubRoutine):
        (JSC::JITStubRoutine::observeZeroRefCount):
        * jit/JITStubRoutine.h: Added.
        (JSC):
        (JITStubRoutine):
        (JSC::JITStubRoutine::JITStubRoutine):
        (JSC::JITStubRoutine::createSelfManagedRoutine):
        (JSC::JITStubRoutine::code):
        (JSC::JITStubRoutine::asCodePtr):
        (JSC::JITStubRoutine::ref):
        (JSC::JITStubRoutine::deref):
        (JSC::JITStubRoutine::startAddress):
        (JSC::JITStubRoutine::endAddress):
        (JSC::JITStubRoutine::addressStep):
        (JSC::JITStubRoutine::canPerformRangeFilter):
        (JSC::JITStubRoutine::filteringStartAddress):
        (JSC::JITStubRoutine::filteringExtentSize):
        (JSC::JITStubRoutine::passesFilter):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::getPolymorphicAccessStructureListSlot):

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

        Unreviewed, rolling out r122107.
        http://trac.webkit.org/changeset/122107
        https://bugs.webkit.org/show_bug.cgi?id=90794

        Build failure on Mac debug bots (Requested by falken_ on
        #webkit).

        * Configurations/FeatureDefines.xcconfig:

2012-07-09  Matt Falkenhagen  <falken@chromium.org>

        Add ENABLE_DIALOG_ELEMENT and skeleton files
        https://bugs.webkit.org/show_bug.cgi?id=90521

        Reviewed by Kent Tamura.

        * Configurations/FeatureDefines.xcconfig:

2012-07-08  Ryosuke Niwa  <rniwa@webkit.org>

        gcc build fix after r121925.

        * runtime/JSObject.h:
        (JSC::JSFinalObject::finishCreation):

2012-07-08  Zoltan Herczeg  <zherczeg@webkit.org>

        [Qt][ARM] Implementing missing macro assembler instructions after r121925
        https://bugs.webkit.org/show_bug.cgi?id=90657

        Reviewed by Csaba Osztrogonác.

        Implementing convertibleLoadPtr, replaceWithLoad and
        replaceWithAddressComputation.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::replaceWithLoad):
        (ARMAssembler):
        (JSC::ARMAssembler::replaceWithAddressComputation):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::convertibleLoadPtr):
        (MacroAssemblerARM):

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

        WebKit Version 5.1.7 (6534.57.2, r121935): Double-click no longer works on OpenStreetMap
        https://bugs.webkit.org/show_bug.cgi?id=90703

        Reviewed by Michael Saboff.
        
        It turns out that in my object model refactoring, I managed to fix get_by_pname in all
        execution engines except 64-bit baseline JIT.

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

2012-07-06  Pravin D  <pravind.2k4@gmail.com>

        Build Error on Qt Linux build
        https://bugs.webkit.org/show_bug.cgi?id=90699

        Reviewed by Laszlo Gombos.

        * parser/Parser.cpp:
        (JSC::::parseForStatement):
        Removed unused boolean variable as this was causing build error on Qt Linux.

2012-07-06  Nuno Lopes  <nlopes@apple.com>

        Fix build with recent clang.
        https://bugs.webkit.org/show_bug.cgi?id=90634

        Reviewed by Oliver Hunt.

        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (SpecializedThunkJIT):
        * 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):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):
        * parser/NodeConstructors.h:
        (JSC::PostfixErrorNode::PostfixErrorNode):
        (JSC::PrefixErrorNode::PrefixErrorNode):
        (JSC::AssignResolveNode::AssignResolveNode):
        (JSC::AssignErrorNode::AssignErrorNode):
        (JSC::ForNode::ForNode):
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.h:
        (FunctionCallResolveNode):
        (PostfixErrorNode):
        (PrefixErrorNode):
        (ReadModifyResolveNode):
        (AssignResolveNode):
        (AssignErrorNode):
        (ForNode):
        (ForInNode):
        * parser/Parser.cpp:
        (JSC::::parseVarDeclarationList):
        (JSC::::parseForStatement):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createAssignResolve):
        (JSC::SyntaxChecker::createForLoop):

2012-07-06  Zoltan Herczeg  <zherczeg@webkit.org>

        [Qt][ARM] REGRESSION(r121885): It broke 30 jsc tests, 500+ layout tests
        https://bugs.webkit.org/show_bug.cgi?id=90656

        Reviewed by Csaba Osztrogonác.

        Typo fixes.

        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords):
        Rename getOp2Byte() -> getOp2Half()
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::convertibleLoadPtr):
        Add a necessary space.
        * jit/JITStubs.cpp:
        (JSC):
        Revert INLINE_ARM_FUNCTION macro.

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

        REGRESSION(r121925): It broke 5 sputnik tests on x86 platforms
        https://bugs.webkit.org/show_bug.cgi?id=90658

        Reviewed by Zoltan Herczeg.
        
        Under the new object model, out-of-line property accesses such as those
        in ResolveGlobal must account for the fact that the offset to the Kth
        property is represented by K + inlineStorageCapacity. Hence, the property
        loads in ResolveGlobal must have an additional -inlineStorageCapacity *
        sizeof(JSValue) offset.

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

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

        [Qt] Unreviewed 64 bit buildfix after r121925.

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

2012-07-05  Michael Saboff  <msaboff@apple.com>

        JSString::tryHashConstLock() fails to get exclusive lock
        https://bugs.webkit.org/show_bug.cgi?id=90639

        Reviewed by Oliver Hunt.

        Added check that the string is already locked even before compare and swap.

        * heap/MarkStack.cpp:
        (JSC::JSString::tryHashConstLock):

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

        Inline property storage should not be wasted when it is exhausted
        https://bugs.webkit.org/show_bug.cgi?id=90347

        Reviewed by Gavin Barraclough.
        
        Previously, if we switched an object from using inline storage to out-of-line
        storage, we would abandon the inline storage. This would have two main implications:
        (i) all accesses to the object, even for properties that were previously in inline
        storage, must now take an extra indirection; and (ii) we waste a non-trivial amount
        of space since we must allocate additional out-of-line storage to hold properties
        that would have fit in the inline storage. There's also the copying cost when
        switching to out-of-line storage - we must copy all inline properties into ouf-of-line
        storage.
        
        This patch changes the way that object property storage works so that we can use both
        inline and out-of-line storage concurrently. This is accomplished by introducing a
        new notion of property offset. This PropertyOffset is a 32-bit signed integer and it
        behaves as follows:
        
        offset == -1: invalid offset, indicating a property that does not exist.
        
        0 <= offset <= inlineStorageCapacity: offset into inline storage.
        
        inlineStorageCapacity < offset: offset into out-of-line storage.
        
        Because non-final objects don't have inline storage, the only valid PropertyOffsets
        for those objects' properties are -1 or > inlineStorageCapacity.
        
        This now means that the decision to use inline or out-of-line storage for an access is
        made based on the offset, rather than the structure. It also means that any access
        where the offset is a variable must have an extra branch, unless the type of the
        object is also known (if it's known to be a non-final object then we can just assert
        that the offset is >= inlineStorageCapacity).
        
        This looks like a big Kraken speed-up and a slight V8 speed-up.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::ldrWide8BitImmediate):
        (JSC::ARMv7Assembler::replaceWithLoad):
        (JSC::ARMv7Assembler::replaceWithAddressComputation):
        * assembler/AbstractMacroAssembler.h:
        (AbstractMacroAssembler):
        (ConvertibleLoadLabel):
        (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::ConvertibleLoadLabel):
        (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::isSet):
        (JSC::AbstractMacroAssembler::labelIgnoringWatchpoints):
        (JSC::AbstractMacroAssembler::replaceWithLoad):
        (JSC::AbstractMacroAssembler::replaceWithAddressComputation):
        * assembler/CodeLocation.h:
        (JSC):
        (CodeLocationCommon):
        (CodeLocationConvertibleLoad):
        (JSC::CodeLocationConvertibleLoad::CodeLocationConvertibleLoad):
        (JSC::CodeLocationCommon::convertibleLoadAtOffset):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/LinkBuffer.h:
        (LinkBuffer):
        (JSC::LinkBuffer::locationOf):
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (JSC::MacroAssemblerARMv7::convertibleLoadPtr):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::convertibleLoadPtr):
        (MacroAssemblerX86):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::convertibleLoadPtr):
        (MacroAssemblerX86_64):
        * assembler/RepatchBuffer.h:
        (RepatchBuffer):
        (JSC::RepatchBuffer::replaceWithLoad):
        (JSC::RepatchBuffer::replaceWithAddressComputation):
        (JSC::RepatchBuffer::setLoadInstructionIsActive):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::replaceWithLoad):
        (X86Assembler):
        (JSC::X86Assembler::replaceWithAddressComputation):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::finalizeUnconditionally):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForChain):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):
        (JSC::GetByIdStatus::offset):
        (GetByIdStatus):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * bytecode/PutByIdStatus.h:
        (JSC::PutByIdStatus::PutByIdStatus):
        (JSC::PutByIdStatus::offset):
        (PutByIdStatus):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC):
        (JSC::computeForStructure):
        * bytecode/ResolveGlobalStatus.h:
        (JSC::ResolveGlobalStatus::ResolveGlobalStatus):
        (JSC::ResolveGlobalStatus::offset):
        (ResolveGlobalStatus):
        * bytecode/StructureSet.h:
        (StructureSet):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::PropertyAccessRecord::PropertyAccessRecord):
        (PropertyAccessRecord):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::dfgRepatchByIdSelfAccess):
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::tryBuildGetByIDProtoList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::tryBuildPutByIdList):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * heap/MarkStack.cpp:
        (JSC::visitChildren):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::tryCacheGetByID):
        (JSC::Interpreter::privateExecute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::PropertyStubCompilationInfo::copyToStubInfo):
        * jit/JIT.h:
        (JSC::PropertyStubCompilationInfo::PropertyStubCompilationInfo):
        (JSC::JIT::compileGetByIdProto):
        (JSC::JIT::compileGetByIdSelfList):
        (JSC::JIT::compileGetByIdProtoList):
        (JSC::JIT::compileGetByIdChainList):
        (JSC::JIT::compileGetByIdChain):
        (JSC::JIT::compilePutByIdTransition):
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_resolve_global):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_resolve_global):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::compileGetDirectOffset):
        (JSC::JIT::emit_op_method_check):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::patchGetByIdSelf):
        (JSC::JIT::patchPutByIdReplace):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_method_check):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::compileGetDirectOffset):
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::patchGetByIdSelf):
        (JSC::JIT::patchPutByIdReplace):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        (JSC::JIT::emit_op_get_by_pname):
        * jit/JITStubs.cpp:
        (JSC::JITThunks::tryCacheGetByID):
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/x86.rb:
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::functionNameOffset):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitChildren):
        (JSC):
        (JSC::JSFinalObject::visitChildren):
        (JSC::JSObject::put):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::getPropertySpecificValue):
        (JSC::JSObject::removeDirect):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::getDirect):
        (JSC::JSObject::getDirectLocation):
        (JSC::JSObject::hasInlineStorage):
        (JSC::JSObject::inlineStorageUnsafe):
        (JSC::JSObject::inlineStorage):
        (JSC::JSObject::outOfLineStorage):
        (JSC::JSObject::locationForOffset):
        (JSC::JSObject::offsetForLocation):
        (JSC::JSObject::getDirectOffset):
        (JSC::JSObject::putDirectOffset):
        (JSC::JSObject::putUndefinedAtDirectOffset):
        (JSC::JSObject::addressOfOutOfLineStorage):
        (JSC::JSObject::finishCreation):
        (JSC::JSNonFinalObject::JSNonFinalObject):
        (JSC::JSNonFinalObject::finishCreation):
        (JSFinalObject):
        (JSC::JSFinalObject::finishCreation):
        (JSC::JSFinalObject::JSFinalObject):
        (JSC::JSObject::offsetOfOutOfLineStorage):
        (JSC::JSObject::setOutOfLineStorage):
        (JSC::JSObject::JSObject):
        (JSC):
        (JSC::JSCell::fastGetOwnProperty):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::putDirectWithoutTransition):
        (JSC::offsetRelativeToPatchedStorage):
        (JSC::indexRelativeToBase):
        (JSC::offsetRelativeToBase):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::create):
        * runtime/JSPropertyNameIterator.h:
        (JSPropertyNameIterator):
        (JSC::JSPropertyNameIterator::getOffset):
        (JSC::JSPropertyNameIterator::finishCreation):
        * runtime/JSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/Operations.h:
        (JSC::normalizePrototypeChain):
        * runtime/Options.cpp:
        (JSC):
        (JSC::Options::initialize):
        * runtime/PropertyMapHashTable.h:
        (PropertyMapEntry):
        (JSC::PropertyMapEntry::PropertyMapEntry):
        (PropertyTable):
        (JSC::PropertyTable::PropertyTable):
        (JSC::PropertyTable::getDeletedOffset):
        (JSC::PropertyTable::addDeletedOffset):
        (JSC::PropertyTable::nextOffset):
        (JSC):
        (JSC::PropertyTable::sizeInMemory):
        * runtime/PropertyOffset.h: Added.
        (JSC):
        (JSC::checkOffset):
        (JSC::validateOffset):
        (JSC::isValidOffset):
        (JSC::isInlineOffset):
        (JSC::isOutOfLineOffset):
        (JSC::offsetInInlineStorage):
        (JSC::offsetInOutOfLineStorage):
        (JSC::offsetInRespectiveStorage):
        (JSC::numberOfOutOfLineSlotsForLastOffset):
        (JSC::numberOfSlotsForLastOffset):
        (JSC::nextPropertyOffsetFor):
        (JSC::firstPropertyOffsetFor):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::cachedOffset):
        (JSC::PropertySlot::setValue):
        (JSC::PropertySlot::setCacheableGetterSlot):
        (JSC::PropertySlot::clearOffset):
        * runtime/PutPropertySlot.h:
        (JSC::PutPropertySlot::setExistingProperty):
        (JSC::PutPropertySlot::setNewProperty):
        (JSC::PutPropertySlot::cachedOffset):
        (PutPropertySlot):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::materializePropertyMap):
        (JSC::nextOutOfLineStorageCapacity):
        (JSC::Structure::growOutOfLineCapacity):
        (JSC::Structure::suggestedNewOutOfLineStorageCapacity):
        (JSC::Structure::addPropertyTransitionToExistingStructure):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::removePropertyTransition):
        (JSC::Structure::flattenDictionaryStructure):
        (JSC::Structure::addPropertyWithoutTransition):
        (JSC::Structure::removePropertyWithoutTransition):
        (JSC::Structure::copyPropertyTableForPinning):
        (JSC::Structure::get):
        (JSC::Structure::putSpecificValue):
        (JSC::Structure::remove):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::putWillGrowOutOfLineStorage):
        (JSC::Structure::previousID):
        (JSC::Structure::outOfLineCapacity):
        (JSC::Structure::outOfLineSizeForKnownFinalObject):
        (JSC::Structure::outOfLineSizeForKnownNonFinalObject):
        (JSC::Structure::outOfLineSize):
        (JSC::Structure::hasInlineStorage):
        (JSC::Structure::inlineCapacity):
        (JSC::Structure::inlineSizeForKnownFinalObject):
        (JSC::Structure::inlineSize):
        (JSC::Structure::totalStorageSize):
        (JSC::Structure::totalStorageCapacity):
        (JSC::Structure::firstValidOffset):
        (JSC::Structure::lastValidOffset):
        (JSC::Structure::isValidOffset):
        (JSC::Structure::isEmpty):
        (JSC::Structure::transitionCount):
        (JSC::Structure::get):

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

        JSObjectCallAsFunction should thisConvert the provided thisObject
        https://bugs.webkit.org/show_bug.cgi?id=90628

        Reviewed by Gavin Barraclough.

        Perform this conversion on the provided this object.

        * API/JSObjectRef.cpp:
        (JSObjectCallAsFunction):

2012-07-05  Zoltan Herczeg  <zherczeg@webkit.org>

        [Qt] Unreviewed buildfix after r121886. Typo fix.

        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords):

2012-07-05  Zoltan Herczeg  <zherczeg@webkit.org>

        Port DFG JIT to traditional ARM
        https://bugs.webkit.org/show_bug.cgi?id=90198

        Reviewed by Filip Pizlo.

        This patch contains the macro assembler part of the
        DFG JIT support on ARM systems with fixed 32 bit instruction
        width. A large amount of old code was refactored, and the ARMv4
        or lower support is removed from the macro assembler.

        Sunspider is improved by 8%, and V8 is 92%.

        * assembler/ARMAssembler.cpp:
        (JSC::ARMAssembler::dataTransfer32):
        (JSC::ARMAssembler::baseIndexTransfer32):
        (JSC):
        (JSC::ARMAssembler::dataTransfer16):
        (JSC::ARMAssembler::baseIndexTransfer16):
        (JSC::ARMAssembler::dataTransferFloat):
        (JSC::ARMAssembler::baseIndexTransferFloat):
        (JSC::ARMAssembler::executableCopy):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::ARMAssembler):
        (JSC::ARMAssembler::emitInst):
        (JSC::ARMAssembler::vmov_f64_r):
        (ARMAssembler):
        (JSC::ARMAssembler::vabs_f64_r):
        (JSC::ARMAssembler::vneg_f64_r):
        (JSC::ARMAssembler::ldr_imm):
        (JSC::ARMAssembler::ldr_un_imm):
        (JSC::ARMAssembler::dtr_u):
        (JSC::ARMAssembler::dtr_ur):
        (JSC::ARMAssembler::dtr_d):
        (JSC::ARMAssembler::dtr_dr):
        (JSC::ARMAssembler::dtrh_u):
        (JSC::ARMAssembler::dtrh_ur):
        (JSC::ARMAssembler::dtrh_d):
        (JSC::ARMAssembler::dtrh_dr):
        (JSC::ARMAssembler::fdtr_u):
        (JSC::ARMAssembler::fdtr_d):
        (JSC::ARMAssembler::push_r):
        (JSC::ARMAssembler::pop_r):
        (JSC::ARMAssembler::poke_r):
        (JSC::ARMAssembler::peek_r):
        (JSC::ARMAssembler::vmov_vfp64_r):
        (JSC::ARMAssembler::vmov_arm64_r):
        (JSC::ARMAssembler::vmov_vfp32_r):
        (JSC::ARMAssembler::vmov_arm32_r):
        (JSC::ARMAssembler::vcvt_u32_f64_r):
        (JSC::ARMAssembler::vcvt_f64_f32_r):
        (JSC::ARMAssembler::vcvt_f32_f64_r):
        (JSC::ARMAssembler::clz_r):
        (JSC::ARMAssembler::bkpt):
        (JSC::ARMAssembler::bx):
        (JSC::ARMAssembler::blx):
        (JSC::ARMAssembler::labelIgnoringWatchpoints):
        (JSC::ARMAssembler::labelForWatchpoint):
        (JSC::ARMAssembler::label):
        (JSC::ARMAssembler::getLdrImmAddress):
        (JSC::ARMAssembler::replaceWithJump):
        (JSC::ARMAssembler::maxJumpReplacementSize):
        (JSC::ARMAssembler::getOp2Byte):
        (JSC::ARMAssembler::getOp2Half):
        (JSC::ARMAssembler::RM):
        (JSC::ARMAssembler::RS):
        (JSC::ARMAssembler::RD):
        (JSC::ARMAssembler::RN):
        * assembler/AssemblerBufferWithConstantPool.h:
        (JSC::AssemblerBufferWithConstantPool::ensureSpaceForAnyInstruction):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::add32):
        (MacroAssemblerARM):
        (JSC::MacroAssemblerARM::and32):
        (JSC::MacroAssemblerARM::lshift32):
        (JSC::MacroAssemblerARM::mul32):
        (JSC::MacroAssemblerARM::neg32):
        (JSC::MacroAssemblerARM::rshift32):
        (JSC::MacroAssemblerARM::urshift32):
        (JSC::MacroAssemblerARM::xor32):
        (JSC::MacroAssemblerARM::load8):
        (JSC::MacroAssemblerARM::load8Signed):
        (JSC::MacroAssemblerARM::load16):
        (JSC::MacroAssemblerARM::load16Signed):
        (JSC::MacroAssemblerARM::load32):
        (JSC::MacroAssemblerARM::load32WithAddressOffsetPatch):
        (JSC::MacroAssemblerARM::store32WithAddressOffsetPatch):
        (JSC::MacroAssemblerARM::store8):
        (JSC::MacroAssemblerARM::store16):
        (JSC::MacroAssemblerARM::store32):
        (JSC::MacroAssemblerARM::move):
        (JSC::MacroAssemblerARM::jump):
        (JSC::MacroAssemblerARM::branchAdd32):
        (JSC::MacroAssemblerARM::mull32):
        (JSC::MacroAssemblerARM::branchMul32):
        (JSC::MacroAssemblerARM::nearCall):
        (JSC::MacroAssemblerARM::compare32):
        (JSC::MacroAssemblerARM::test32):
        (JSC::MacroAssemblerARM::sub32):
        (JSC::MacroAssemblerARM::call):
        (JSC::MacroAssemblerARM::loadFloat):
        (JSC::MacroAssemblerARM::loadDouble):
        (JSC::MacroAssemblerARM::storeFloat):
        (JSC::MacroAssemblerARM::storeDouble):
        (JSC::MacroAssemblerARM::moveDouble):
        (JSC::MacroAssemblerARM::addDouble):
        (JSC::MacroAssemblerARM::divDouble):
        (JSC::MacroAssemblerARM::subDouble):
        (JSC::MacroAssemblerARM::mulDouble):
        (JSC::MacroAssemblerARM::absDouble):
        (JSC::MacroAssemblerARM::negateDouble):
        (JSC::MacroAssemblerARM::convertInt32ToDouble):
        (JSC::MacroAssemblerARM::convertFloatToDouble):
        (JSC::MacroAssemblerARM::convertDoubleToFloat):
        (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32):
        (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32):
        (JSC::MacroAssemblerARM::truncateDoubleToInt32):
        (JSC::MacroAssemblerARM::truncateDoubleToUint32):
        (JSC::MacroAssemblerARM::branchConvertDoubleToInt32):
        (JSC::MacroAssemblerARM::branchDoubleNonZero):
        (JSC::MacroAssemblerARM::branchDoubleZeroOrNaN):
        (JSC::MacroAssemblerARM::invert):
        (JSC::MacroAssemblerARM::replaceWithJump):
        (JSC::MacroAssemblerARM::maxJumpReplacementSize):
        (JSC::MacroAssemblerARM::call32):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::label):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::debugCall):
        (JSC::DFG::AssemblyHelpers::boxDouble):
        (JSC::DFG::AssemblyHelpers::unboxDouble):
        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArguments):
        * dfg/DFGFPRInfo.h:
        (DFG):
        * dfg/DFGGPRInfo.h:
        (DFG):
        (GPRInfo):
        * dfg/DFGOperations.cpp:
        (JSC):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
        (JSC::DFG::SpeculativeJIT::appendCallSetResult):
        * jit/JITStubs.cpp:
        (JSC):
        * jit/JITStubs.h:
        (JITStackFrame):
        * jit/JSInterfaceJIT.h:
        (JSInterfaceJIT):

2012-07-04  Anthony Scian  <ascian@rim.com>

        Web Inspector [JSC]: Implement ScriptCallStack::stackTrace
        https://bugs.webkit.org/show_bug.cgi?id=40118

        Reviewed by Yong Li.

        Added member functions to expose function name, urlString, and line #.
        Refactored toString to make use of these member functions to reduce
        duplicated code for future maintenance.

        Manually tested refactoring of toString by tracing thrown exceptions.

        * interpreter/Interpreter.h:
        (JSC::StackFrame::toString):
        (JSC::StackFrame::friendlySourceURL):
        (JSC::StackFrame::friendlyFunctionName):
        (JSC::StackFrame::friendlyLineNumber):

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

        [GTK] Enable parallel GC
        https://bugs.webkit.org/show_bug.cgi?id=90568

        Reviewed by Martin Robinson.

        * runtime/Options.cpp: Include <algorithm.h> for std::min.

2012-07-04  John Mellor  <johnme@chromium.org>

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

        This patch renames Font Boosting to Text Autosizing.

        Reviewed by Adam Barth.

        * Configurations/FeatureDefines.xcconfig:

2012-07-03  Michael Saboff  <msaboff@apple.com>

        Enh: Hash Const JSString in Backing Stores to Save Memory
        https://bugs.webkit.org/show_bug.cgi?id=86024

        Reviewed by Oliver Hunt.

        During garbage collection, each marking thread keeps a HashMap of
        strings.  While visiting via MarkStack::copyAndAppend(), we check to
        see if the string we are visiting is already in the HashMap.  If not
        we add it. If so, we change the reference to the current string we're
        visiting to the prior string.

        To reduce the performance impact of this change, two throttles have
        ben added.  1) We only try hash consting if a significant number of new 
        strings have been created since the last hash const.  Currently this is
        set at 100 strings.  2) If a string is unique at the end of a marking
        it will not be checked during further GC phases. In some cases this
        won't catch all duplicates, but we are trying to catch the growth of
        duplicate strings.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        * heap/MarkStack.cpp:
        (JSC::MarkStackThreadSharedData::resetChildren):
        (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData):
        (JSC::MarkStackThreadSharedData::reset):
        (JSC::MarkStack::setup): Check to see if enough strings have been created
        to hash const.
        (JSC::MarkStack::reset): Added call to clear m_uniqueStrings.
        (JSC::JSString::tryHashConstLock): New method to lock JSString for
        hash consting.
        (JSC::JSString::releaseHashConstLock): New unlock method.
        (JSC::JSString::shouldTryHashConst): Set of checks to see if we should
        try to hash const the string.
        (JSC::MarkStack::internalAppend): New method that performs the hash consting.
        (JSC::SlotVisitor::copyAndAppend): Changed to call the new hash
        consting internalAppend().
        * heap/MarkStack.h:
        (MarkStackThreadSharedData):
        (MarkStack):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        (JSC::JSGlobalData::haveEnoughNewStringsToHashConst):
        (JSC::JSGlobalData::resetNewStringsSinceLastHashConst):
        * runtime/JSString.h:
        (JSString): Changed from using bool flags to using an unsigned
        m_flags field.  This works better with the weakCompareAndSwap in
        JSString::tryHashConstLock(). Changed the 8bitness setting and
        checking to use new accessors.
        (JSC::JSString::JSString):
        (JSC::JSString::finishCreation):
        (JSC::JSString::is8Bit): Updated for new m_flags.
        (JSC::JSString::setIs8Bit): New setter.
        New hash const flags accessors:
        (JSC::JSString::isHashConstSingleton):
        (JSC::JSString::clearHashConstSingleton):
        (JSC::JSString::setHashConstSingleton):
        (JSC::JSRopeString::finishCreation):
        (JSC::JSRopeString::append):

2012-07-03  Tony Chang  <tony@chromium.org>

        [chromium] Unreviewed, update .gitignore to handle VS2010 files.

        * JavaScriptCore.gyp/.gitignore:

2012-07-03  Mark Lam  <mark.lam@apple.com>

        Add ability to symbolically set and dump JSC VM options.
        See comments in runtime/Options.h for details on how the options work.
        https://bugs.webkit.org/show_bug.cgi?id=90420

        Reviewed by Filip Pizlo.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/LinkBuffer.h:
        (JSC):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shouldOptimizeNow):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::likelyToTakeSlowCase):
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::likelyToTakeSpecialFastCase):
        (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
        (JSC::CodeBlock::likelyToTakeAnySlowCase):
        (JSC::CodeBlock::jitAfterWarmUp):
        (JSC::CodeBlock::jitSoon):
        (JSC::CodeBlock::reoptimizationRetryCounter):
        (JSC::CodeBlock::countReoptimization):
        (JSC::CodeBlock::counterValueForOptimizeAfterWarmUp):
        (JSC::CodeBlock::counterValueForOptimizeAfterLongWarmUp):
        (JSC::CodeBlock::optimizeSoon):
        (JSC::CodeBlock::exitCountThresholdForReoptimization):
        (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
        * bytecode/ExecutionCounter.h:
        (JSC::ExecutionCounter::clippedThreshold):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::mightCompileEval):
        (JSC::DFG::mightCompileProgram):
        (JSC::DFG::mightCompileFunctionForCall):
        (JSC::DFG::mightCompileFunctionForConstruct):
        (JSC::DFG::mightInlineFunctionForCall):
        (JSC::DFG::mightInlineFunctionForConstruct):
        * dfg/DFGCommon.h:
        (JSC::DFG::shouldShowDisassembly):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
        * heap/MarkStack.cpp:
        (JSC::MarkStackSegmentAllocator::allocate):
        (JSC::MarkStackSegmentAllocator::shrinkReserve):
        (JSC::MarkStackArray::MarkStackArray):
        (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        * heap/MarkStack.h:
        (JSC::MarkStack::mergeOpaqueRootsIfProfitable):
        (JSC::MarkStack::addOpaqueRoot):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::donate):
        * jit/JIT.cpp:
        (JSC::JIT::emitOptimizationCheck):
        * jsc.cpp:
        (printUsageStatement):
        (parseArguments):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/JSGlobalData.cpp:
        (JSC::enableAssembler):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        * runtime/Options.cpp:
        (JSC):
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::initialize):
        (JSC::Options::setOption):
        (JSC::Options::dumpAllOptions):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        (JSC):
        (Options):
        (EntryInfo):

2012-07-03  Jocelyn Turcotte  <jocelyn.turcotte@nokia.com>  Joel Dillon <joel.dillon@codethink.co.uk>

        [Qt][Win] Fix broken QtWebKit5.lib linking
        https://bugs.webkit.org/show_bug.cgi?id=88321

        Reviewed by Kenneth Rohde Christiansen.

        The goal is to have different ports build systems define STATICALLY_LINKED_WITH_WTF
        when building JavaScriptCore, if both are packaged in the same DLL, instead
        of relying on the code to handle this.
        The effects of BUILDING_* and STATICALLY_LINKED_WITH_* are currently the same
        except for a check in Source/JavaScriptCore/config.h.

        Keeping the old way for the WX port as requested by the port's contributors.
        For non-Windows ports there is no difference between IMPORT and EXPORT, no
        change is needed.

        * API/JSBase.h:
          JS symbols shouldn't be included by WTF objects anymore. Remove the export when BUILDING_WTF.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
          Make sure that JavaScriptCore uses import symbols of WTF for the Win port.
        * runtime/JSExportMacros.h:

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

        DFG OSR exit value recoveries should be computed lazily
        https://bugs.webkit.org/show_bug.cgi?id=82155

        Reviewed by Gavin Barraclough.
        
        This change aims to reduce one aspect of DFG compile times: the fact
        that we currently compute the value recoveries for each local and
        argument on every speculation check. We compile many speculation checks,
        so this can add up quick. The strategy that this change takes is to
        have the DFG save just enough information about how the compiler is
        choosing to represent state, that the DFG::OSRExitCompiler can reify
        the value recoveries lazily.
        
        This appears to be an 0.3% SunSpider speed-up and is neutral elsewhere.
        
        I also took the opportunity to fix the sampling regions profiler (it
        was missing an export macro) and to put in more sampling regions in
        the DFG (which are disabled so long as ENABLE(SAMPLING_REGIONS) is
        false).
        
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::shrinkDFGDataToFit):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::minifiedDFG):
        (JSC::CodeBlock::variableEventStream):
        (DFGData):
        * bytecode/Operands.h:
        (JSC::Operands::hasOperand):
        (Operands):
        (JSC::Operands::size):
        (JSC::Operands::at):
        (JSC::Operands::operator[]):
        (JSC::Operands::isArgument):
        (JSC::Operands::isVariable):
        (JSC::Operands::argumentForIndex):
        (JSC::Operands::variableForIndex):
        (JSC::Operands::operandForIndex):
        (JSC):
        (JSC::dumpOperands):
        * bytecode/SamplingTool.h:
        (SamplingRegion):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::parse):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::performCFA):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::performCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::performFixup):
        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::GenerationInfo):
        (JSC::DFG::GenerationInfo::initConstant):
        (JSC::DFG::GenerationInfo::initInteger):
        (JSC::DFG::GenerationInfo::initJSValue):
        (JSC::DFG::GenerationInfo::initCell):
        (JSC::DFG::GenerationInfo::initBoolean):
        (JSC::DFG::GenerationInfo::initDouble):
        (JSC::DFG::GenerationInfo::initStorage):
        (GenerationInfo):
        (JSC::DFG::GenerationInfo::noticeOSRBirth):
        (JSC::DFG::GenerationInfo::use):
        (JSC::DFG::GenerationInfo::spill):
        (JSC::DFG::GenerationInfo::setSpilled):
        (JSC::DFG::GenerationInfo::fillJSValue):
        (JSC::DFG::GenerationInfo::fillCell):
        (JSC::DFG::GenerationInfo::fillInteger):
        (JSC::DFG::GenerationInfo::fillBoolean):
        (JSC::DFG::GenerationInfo::fillDouble):
        (JSC::DFG::GenerationInfo::fillStorage):
        (JSC::DFG::GenerationInfo::appendFill):
        (JSC::DFG::GenerationInfo::appendSpill):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGMinifiedGraph.h: Added.
        (DFG):
        (MinifiedGraph):
        (JSC::DFG::MinifiedGraph::MinifiedGraph):
        (JSC::DFG::MinifiedGraph::at):
        (JSC::DFG::MinifiedGraph::append):
        (JSC::DFG::MinifiedGraph::prepareAndShrink):
        (JSC::DFG::MinifiedGraph::setOriginalGraphSize):
        (JSC::DFG::MinifiedGraph::originalGraphSize):
        * dfg/DFGMinifiedNode.cpp: Added.
        (DFG):
        (JSC::DFG::MinifiedNode::fromNode):
        * dfg/DFGMinifiedNode.h: Added.
        (DFG):
        (JSC::DFG::belongsInMinifiedGraph):
        (MinifiedNode):
        (JSC::DFG::MinifiedNode::MinifiedNode):
        (JSC::DFG::MinifiedNode::index):
        (JSC::DFG::MinifiedNode::op):
        (JSC::DFG::MinifiedNode::hasChild1):
        (JSC::DFG::MinifiedNode::child1):
        (JSC::DFG::MinifiedNode::hasConstant):
        (JSC::DFG::MinifiedNode::hasConstantNumber):
        (JSC::DFG::MinifiedNode::constantNumber):
        (JSC::DFG::MinifiedNode::hasWeakConstant):
        (JSC::DFG::MinifiedNode::weakConstant):
        (JSC::DFG::MinifiedNode::getIndex):
        (JSC::DFG::MinifiedNode::compareByNodeIndex):
        (JSC::DFG::MinifiedNode::hasChild):
        * dfg/DFGNode.h:
        (Node):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler.h:
        (OSRExitCompiler):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::performPredictionPropagation):
        * dfg/DFGRedundantPhiEliminationPhase.cpp:
        (JSC::DFG::performRedundantPhiElimination):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (DFG):
        (JSC::DFG::SpeculativeJIT::fillStorage):
        (JSC::DFG::SpeculativeJIT::noticeOSRBirth):
        (JSC::DFG::SpeculativeJIT::compileMovHint):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGSpeculativeJIT.h:
        (DFG):
        (JSC::DFG::SpeculativeJIT::use):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::speculationCheck):
        (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::recordSetLocal):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInteger):
        (JSC::DFG::SpeculativeJIT::fillDouble):
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInteger):
        (JSC::DFG::SpeculativeJIT::fillDouble):
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValueRecoveryOverride.h: Added.
        (DFG):
        (ValueRecoveryOverride):
        (JSC::DFG::ValueRecoveryOverride::ValueRecoveryOverride):
        * dfg/DFGValueSource.cpp: Added.
        (DFG):
        (JSC::DFG::ValueSource::dump):
        * dfg/DFGValueSource.h: Added.
        (DFG):
        (JSC::DFG::dataFormatToValueSourceKind):
        (JSC::DFG::valueSourceKindToDataFormat):
        (JSC::DFG::isInRegisterFile):
        (ValueSource):
        (JSC::DFG::ValueSource::ValueSource):
        (JSC::DFG::ValueSource::forPrediction):
        (JSC::DFG::ValueSource::forDataFormat):
        (JSC::DFG::ValueSource::isSet):
        (JSC::DFG::ValueSource::kind):
        (JSC::DFG::ValueSource::isInRegisterFile):
        (JSC::DFG::ValueSource::dataFormat):
        (JSC::DFG::ValueSource::valueRecovery):
        (JSC::DFG::ValueSource::nodeIndex):
        (JSC::DFG::ValueSource::nodeIndexFromKind):
        (JSC::DFG::ValueSource::kindFromNodeIndex):
        * dfg/DFGVariableEvent.cpp: Added.
        (DFG):
        (JSC::DFG::VariableEvent::dump):
        (JSC::DFG::VariableEvent::dumpFillInfo):
        (JSC::DFG::VariableEvent::dumpSpillInfo):
        * dfg/DFGVariableEvent.h: Added.
        (DFG):
        (VariableEvent):
        (JSC::DFG::VariableEvent::VariableEvent):
        (JSC::DFG::VariableEvent::reset):
        (JSC::DFG::VariableEvent::fillGPR):
        (JSC::DFG::VariableEvent::fillPair):
        (JSC::DFG::VariableEvent::fillFPR):
        (JSC::DFG::VariableEvent::spill):
        (JSC::DFG::VariableEvent::death):
        (JSC::DFG::VariableEvent::setLocal):
        (JSC::DFG::VariableEvent::movHint):
        (JSC::DFG::VariableEvent::kind):
        (JSC::DFG::VariableEvent::nodeIndex):
        (JSC::DFG::VariableEvent::dataFormat):
        (JSC::DFG::VariableEvent::gpr):
        (JSC::DFG::VariableEvent::tagGPR):
        (JSC::DFG::VariableEvent::payloadGPR):
        (JSC::DFG::VariableEvent::fpr):
        (JSC::DFG::VariableEvent::virtualRegister):
        (JSC::DFG::VariableEvent::operand):
        (JSC::DFG::VariableEvent::variableRepresentation):
        * dfg/DFGVariableEventStream.cpp: Added.
        (DFG):
        (JSC::DFG::VariableEventStream::logEvent):
        (MinifiedGenerationInfo):
        (JSC::DFG::MinifiedGenerationInfo::MinifiedGenerationInfo):
        (JSC::DFG::MinifiedGenerationInfo::update):
        (JSC::DFG::VariableEventStream::reconstruct):
        * dfg/DFGVariableEventStream.h: Added.
        (DFG):
        (VariableEventStream):
        (JSC::DFG::VariableEventStream::appendAndLog):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::performVirtualRegisterAllocation):

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

        DFG::ArgumentsSimplificationPhase should assert that the PhantomArguments nodes it creates are not shouldGenerate()
        https://bugs.webkit.org/show_bug.cgi?id=90407

        Reviewed by Mark Hahnenberg.

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

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

        Array.prototype.pop should throw if property is not configurable
        https://bugs.webkit.org/show_bug.cgi?id=75788

        Rubber Stamped by Oliver Hunt.

        No real bug here any more, but the error we throw sometimes has a misleading message.
 
        * runtime/JSArray.cpp:
        (JSC::JSArray::pop):

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

        JSObject wastes too much memory on unused property slots
        https://bugs.webkit.org/show_bug.cgi?id=90255

        Reviewed by Mark Hahnenberg.
        
        Rolling back in after applying a simple fix: it appears that
        JSObject::setStructureAndReallocateStorageIfNecessary() was allocating more
        property storage than necessary. Fixing this appears to resolve the crash.
        
        This does a few things:
        
        - JSNonFinalObject no longer has inline property storage.
        
        - Initial out-of-line property storage size is 4 slots for JSNonFinalObject,
          or 2x the inline storage for JSFinalObject.
        
        - Property storage is only reallocated if it needs to be. Previously, we
          would reallocate the property storage on any transition where the original
          structure said shouldGrowProperyStorage(), but this led to spurious
          reallocations when doing transitionless property adds and there are
          deleted property slots available. That in turn led to crashes, because we
          would switch to out-of-line storage even if the capacity matched the
          criteria for inline storage.
        
        - Inline JSFunction allocation is killed off because we don't have a good
          way of inlining property storage allocation. This didn't hurt performance.
          Killing off code is better than fixing it if that code wasn't doing any
          good.
        
        This looks like a 1% progression on V8.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_func):
        (JSC):
        (JSC::JIT::emit_op_new_func_exp):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        * runtime/JSObject.h:
        (JSC::JSObject::isUsingInlineStorage):
        (JSObject):
        (JSC::JSObject::finishCreation):
        (JSC):
        (JSC::JSNonFinalObject::hasInlineStorage):
        (JSNonFinalObject):
        (JSC::JSNonFinalObject::JSNonFinalObject):
        (JSC::JSNonFinalObject::finishCreation):
        (JSC::JSFinalObject::hasInlineStorage):
        (JSC::JSFinalObject::finishCreation):
        (JSC::JSObject::offsetOfInlineStorage):
        (JSC::JSObject::setPropertyStorage):
        (JSC::Structure::inlineStorageCapacity):
        (JSC::Structure::isUsingInlineStorage):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::nextPropertyStorageCapacity):
        (JSC):
        (JSC::Structure::growPropertyStorageCapacity):
        (JSC::Structure::suggestedNewPropertyStorageSize):
        * runtime/Structure.h:
        (JSC::Structure::putWillGrowPropertyStorage):
        (Structure):

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

        Webkit crashes in DFG on Google Docs when creating a new document
        https://bugs.webkit.org/show_bug.cgi?id=90209

        Reviewed by Gavin Barraclough.
        
        Don't attempt to short-circuit Phantom(GetLocal) if the GetLocal is for a
        captured variable.

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

2012-06-30  Zan Dobersek  <zandobersek@gmail.com>

        Unreviewed, rolling out r121605.
        http://trac.webkit.org/changeset/121605
        https://bugs.webkit.org/show_bug.cgi?id=90336

        Changes caused flaky crashes in sputnik/Unicode tests on Apple
        WK1 and GTK Linux builders

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateJSFinalObject):
        (JSC):
        (JSC::JIT::emitAllocateJSFunction):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emitSlow_op_new_func):
        (JSC):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emitSlow_op_new_func_exp):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        * runtime/JSObject.h:
        (JSC::JSObject::isUsingInlineStorage):
        (JSObject):
        (JSC::JSObject::finishCreation):
        (JSC):
        (JSNonFinalObject):
        (JSC::JSNonFinalObject::JSNonFinalObject):
        (JSC::JSNonFinalObject::finishCreation):
        (JSFinalObject):
        (JSC::JSFinalObject::finishCreation):
        (JSC::JSObject::offsetOfInlineStorage):
        (JSC::JSObject::setPropertyStorage):
        (JSC::Structure::isUsingInlineStorage):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::putDirectWithoutTransition):
        (JSC::JSObject::transitionTo):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC):
        (JSC::Structure::growPropertyStorageCapacity):
        (JSC::Structure::suggestedNewPropertyStorageSize):
        * runtime/Structure.h:
        (JSC::Structure::shouldGrowPropertyStorage):
        (JSC::Structure::propertyStorageSize):

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

        Remove warning about protected values when the Heap is being destroyed
        https://bugs.webkit.org/show_bug.cgi?id=90302

        Reviewed by Geoffrey Garen.

        Having to do book-keeping about whether values allocated from a certain 
        VM are or are not protected makes the JSC API much more difficult to use 
        correctly. Clients should be able to throw an entire VM away and not have 
        to worry about unprotecting all of the values that they protected earlier.

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

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

        JSObject wastes too much memory on unused property slots
        https://bugs.webkit.org/show_bug.cgi?id=90255

        Reviewed by Mark Hahnenberg.
        
        This does a few things:
        
        - JSNonFinalObject no longer has inline property storage.
        
        - Initial out-of-line property storage size is 4 slots for JSNonFinalObject,
          or 2x the inline storage for JSFinalObject.
        
        - Property storage is only reallocated if it needs to be. Previously, we
          would reallocate the property storage on any transition where the original
          structure said shouldGrowProperyStorage(), but this led to spurious
          reallocations when doing transitionless property adds and there are
          deleted property slots available. That in turn led to crashes, because we
          would switch to out-of-line storage even if the capacity matched the
          criteria for inline storage.
        
        - Inline JSFunction allocation is killed off because we don't have a good
          way of inlining property storage allocation. This didn't hurt performance.
          Killing off code is better than fixing it if that code wasn't doing any
          good.
        
        This looks like a 1% progression on V8.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_func):
        (JSC):
        (JSC::JIT::emit_op_new_func_exp):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        * runtime/JSObject.h:
        (JSC::JSObject::isUsingInlineStorage):
        (JSObject):
        (JSC::JSObject::finishCreation):
        (JSC):
        (JSC::JSNonFinalObject::hasInlineStorage):
        (JSNonFinalObject):
        (JSC::JSNonFinalObject::JSNonFinalObject):
        (JSC::JSNonFinalObject::finishCreation):
        (JSC::JSFinalObject::hasInlineStorage):
        (JSC::JSFinalObject::finishCreation):
        (JSC::JSObject::offsetOfInlineStorage):
        (JSC::JSObject::setPropertyStorage):
        (JSC::Structure::inlineStorageCapacity):
        (JSC::Structure::isUsingInlineStorage):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::nextPropertyStorageCapacity):
        (JSC):
        (JSC::Structure::growPropertyStorageCapacity):
        (JSC::Structure::suggestedNewPropertyStorageSize):
        * runtime/Structure.h:
        (JSC::Structure::putWillGrowPropertyStorage):
        (Structure):

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

        DFG recompilation heuristics should be based on count, not rate
        https://bugs.webkit.org/show_bug.cgi?id=90146

        Reviewed by Oliver Hunt.
        
        This removes a bunch of code that was previously trying to prevent spurious
        reoptimizations if a large enough majority of executions of a code block did
        not result in OSR exit. It turns out that this code was purely harmful. This
        patch removes all of that logic and replaces it with a dead-simple
        heuristic: if you exit more than N times (where N is an exponential function
        of the number of times the code block has already been recompiled) then we
        will recompile.
        
        This appears to be a broad ~1% win on many benchmarks large and small.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::osrExitCounter):
        (JSC::CodeBlock::countOSRExit):
        (CodeBlock):
        (JSC::CodeBlock::addressOfOSRExitCounter):
        (JSC::CodeBlock::offsetOfOSRExitCounter):
        (JSC::CodeBlock::adjustedExitCountThreshold):
        (JSC::CodeBlock::exitCountThresholdForReoptimization):
        (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
        (JSC::CodeBlock::shouldReoptimizeNow):
        (JSC::CodeBlock::shouldReoptimizeFromLoopNow):
        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter::setThreshold):
        * bytecode/ExecutionCounter.h:
        (ExecutionCounter):
        (JSC::ExecutionCounter::clippedThreshold):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileBody):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::handleExitCounts):
        * dfg/DFGOperations.cpp:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Options.cpp:
        (Options):
        (JSC::Options::initializeOptions):
        * runtime/Options.h:
        (Options):

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

        Adding a commenting utility to record BytecodeGenerator comments
        with opcodes that are emitted.  Presently, the comments can only
        be constant strings.  Adding comments for opcodes is optional.
        If a comment is added, the comment will be printed following the
        opcode when CodeBlock::dump() is called.

        This utility is disabled by default, and is only meant for VM
        development purposes.  It should not be enabled for product builds.

        To enable this utility, set ENABLE_BYTECODE_COMMENTS in CodeBlock.h
        to 1.

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

        Reviewed by Geoffrey Garen.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): Dumps the comment.
        (JSC):
        (JSC::CodeBlock::printUnaryOp): Add comment dumps.
        (JSC::CodeBlock::printBinaryOp): Add comment dumps.
        (JSC::CodeBlock::printConditionalJump): Add comment dumps.
        (JSC::CodeBlock::printCallOp): Add comment dumps.
        (JSC::CodeBlock::printPutByIdOp): Add comment dumps.
        (JSC::CodeBlock::dump): Add comment dumps.
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::commentForBytecodeOffset):
            Finds the comment for an opcode if available.
        (JSC::CodeBlock::dumpBytecodeComments):
            For debugging whether comments are collected.
            It is not being called anywhere.
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::bytecodeComments):
        * bytecode/Comment.h: Added.
        (JSC):
        (Comment):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitOpcode): Calls emitComment().
        (JSC):
        (JSC::BytecodeGenerator::emitComment): Adds comment to CodeBlock.
        (JSC::BytecodeGenerator::prependComment):
            Registers a comment for emitComemnt() to use later.
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        (JSC::BytecodeGenerator::emitComment):
        (JSC::BytecodeGenerator::prependComment):
            These are inlined versions of these functions that nullify them
            when ENABLE_BYTECODE_COMMENTS is 0.
        (JSC::BytecodeGenerator::comments):

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

        32bit DFG incorrectly claims an fpr is fillable even if it has not been proven double
        https://bugs.webkit.org/show_bug.cgi?id=90127

        Reviewed by Filip Pizlo.

        The 32-bit version of fillSpeculateDouble doesn't handle Number->fpr loads
        correctly.  This patch fixes this by killing the fill info in the GenerationInfo
        when the spillFormat doesn't guarantee the value is a double.

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

2012-06-28  Kent Tamura  <tkent@chromium.org>

        Classify form control states by their owner forms
        https://bugs.webkit.org/show_bug.cgi?id=89950

        Reviewed by Hajime Morita.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        Expose WTF::StringBuilder::canShrink()

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

        [Win] jscore-tests flakey
        https://bugs.webkit.org/show_bug.cgi?id=88118

        Reviewed by Jessie Berlin.

        jsDriver.pl on windows intermittently doesn't get the returned value from jsc,
        instead it gets 126.  Added a new option to jsc (-x) which prints the exit
        code before exiting.  jsDriver.pl uses this option on Windows and parses the
        exit code output for the exit code, removing it before comparing the actual
        and expected outputs.  Filed a follow on "FIXME" defect:
        [WIN] Intermittent failure for jsc return value to propagate through jsDriver.pl
        https://bugs.webkit.org/show_bug.cgi?id=90119

        * jsc.cpp:
        (CommandLine::CommandLine):
        (CommandLine):
        (printUsageStatement):
        (parseArguments):
        (jscmain):
        * tests/mozilla/jsDriver.pl:
        (execute_tests):

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

        Unreviewed, rolling out r121359.
        http://trac.webkit.org/changeset/121359
        https://bugs.webkit.org/show_bug.cgi?id=90115

        Broke many inspector tests (Requested by jpfau on #webkit).

        * interpreter/Interpreter.h:
        (JSC::StackFrame::toString):

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

        Javascript SHA-512 gives wrong hash on second and subsequent runs unless Web Inspector Javascript Debugging is on
        https://bugs.webkit.org/show_bug.cgi?id=90053
        <rdar://problem/11764613>

        Reviewed by Mark Hahnenberg.
        
        The problem is that the code was assuming that the recovery should be Undefined if the source of
        the SetLocal was !shouldGenerate(). But that's wrong, since the DFG optimizer may skip around a
        UInt32ToNumber node (hence making it !shouldGenerate()) and keep the source of that node alive.
        In that case we should base the recovery on the source of the UInt32ToNumber. The logic for this
        was already in place but the fast check for !shouldGenerate() broke it.

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

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

        DFG disassembly should be easier to read
        https://bugs.webkit.org/show_bug.cgi?id=90106

        Reviewed by Mark Hahnenberg.
        
        Did a few things:
        
        - Options::showDFGDisassembly now shows OSR exit disassembly as well.
        
        - Phi node dumping doesn't attempt to do line wrapping since it just made the dump harder
          to read.
        
        - DFG graph disassembly view shows a few additional node types that turn out to be
          essential for understanding OSR exits.
        
        Put together, these changes reinforce the philosophy that anything needed for computing
        OSR exit is just as important as the machine code itself. Of course, we still don't take
        that philosophy to its full extreme - for example Phantom nodes are not dumped. We may
        revisit that in the future.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/LinkBuffer.h:
        (JSC):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dump):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dumpBlockHeader):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGOSRExitCompiler.cpp:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):

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

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

        Reviewed by Geoffrey Garen.

        * 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):
        (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):
        * 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: 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-27  Filip Pizlo  <fpizlo@apple.com>

        x86 disassembler confuses immediates with addresses
        https://bugs.webkit.org/show_bug.cgi?id=90099

        Reviewed by Mark Hahnenberg.
        
        Prepend "$" to immediates to disambiguate between immediates and addresses. This is in
        accordance with the gas and AT&T syntax.

        * disassembler/udis86/udis86_syn-att.c:
        (gen_operand):

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

        Add a comment clarifying Options::showDisassembly versus Options::showDFGDisassembly.

        Rubber stamped by Mark Hahnenberg.

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

2012-06-27  Anthony Scian  <ascian@rim.com>

        Web Inspector [JSC]: Implement ScriptCallStack::stackTrace
        https://bugs.webkit.org/show_bug.cgi?id=40118

        Reviewed by Yong Li.

        Added member functions to expose function name, urlString, and line #.
        Refactored toString to make use of these member functions to reduce
        duplicated code for future maintenance.

        Manually tested refactoring of toString by tracing thrown exceptions.

        * interpreter/Interpreter.h:
        (StackFrame):
        (JSC::StackFrame::toString):
        (JSC::StackFrame::friendlySourceURL):
        (JSC::StackFrame::friendlyFunctionName):
        (JSC::StackFrame::friendlyLineNumber):

2012-06-27  Oswald Buddenhagen  <oswald.buddenhagen@nokia.com>

        [Qt] Remove redundant c++11 warning suppression code

        This is already handled in default_post.

        Reviewed by Tor Arne Vestbø.

        * Target.pri:

2012-06-26  Tor Arne Vestbø  <tor.arne.vestbo@nokia.com>

        [Qt] Add missing heades to HEADERS

        For JavaScriptCore there aren't any Qt specific files, so we include all
        headers for easy editing in Qt Creator.

        Reviewed by Simon Hausmann.

        * Target.pri:

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

        [Chromium] Remove unused build scripts and empty folders for JavaScriptCore w/ gyp
        https://bugs.webkit.org/show_bug.cgi?id=90029

        Reviewed by Adam Barth.

        * gyp: Removed.
        * gyp/generate-derived-sources.sh: Removed.
        * gyp/generate-dtrace-header.sh: Removed.
        * gyp/run-if-exists.sh: Removed.
        * gyp/update-info-plist.sh: Removed.

2012-06-26  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 2)

        This part turns off "berzerker GC" and turns on incremental shrinking.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep): Free or shrink after sweeping to
        maintain the behavior we used to get from the occasional berzerker GC,
        which would run all finalizers and then free or shrink all blocks
        synchronously.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::needsSweeping): Sweep zapped blocks, too. It's always
        safe to sweep a zapped block (that's the point of zapping), and it's
        sometimes profitable. For example, consider this case: Block A does some
        allocation (transitioning Block A from Marked to FreeListed), then GC
        happens (transitioning Block A to Zapped), then all objects in Block A
        are free, then the incremental sweeper visits Block A. If we skipped
        Zapped blocks, we'd skip Block A, even though it would be profitable to
        run its destructors and free its memory.

        * runtime/GCActivityCallback.cpp:
        (JSC::DefaultGCActivityCallback::doWork): Don't sweep eagerly; we'll do
        this incrementally.

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

        DFG PutByValAlias is too aggressive
        https://bugs.webkit.org/show_bug.cgi?id=90026
        <rdar://problem/11751830>

        Reviewed by Gavin Barraclough.
        
        For CSE on normal arrays, we now treat PutByVal as impure. This does not appear to affect
        performance by much.
        
        For CSE on typed arrays, we fix PutByValAlias by making GetByVal speculate that the access
        is within bounds. This also has the effect of making our out-of-bounds handling consistent
        with WebCore.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        (JSC::DFG::Graph::clobbersWorld):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):

2012-06-26  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.

        Fix non-JIT build on BlackBerry broken by r121196.

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

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

        DFG::operationNewArray is unnecessarily slow, and may use the wrong array
        prototype when inlined
        https://bugs.webkit.org/show_bug.cgi?id=89821

        Reviewed by Geoffrey Garen.
        
        Fixes all array allocations to use the right structure, and hence the right prototype. Adds
        inlining of new Array(...) with a non-zero number of arguments. Optimizes allocations of
        empty arrays.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/JSArray.h:
        (JSC):
        (JSC::constructArray):
        * runtime/JSGlobalObject.h:
        (JSC):
        (JSC::constructArray):

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

        New fast/js/dfg-store-unexpected-value-into-argument-and-osr-exit.html fails on 32 bit
        https://bugs.webkit.org/show_bug.cgi?id=89953

        Reviewed by Zoltan Herczeg.
        
        DFG 32-bit JIT was confused about the difference between a predicted type and a
        proven type. This is easy to get confused about, since a local that is predicted int32
        almost always means that the local must be an int32 since speculations are hoisted to
        stores to locals. But that is less likely to be the case for arguments, where there is
        an additional least-upper-bounding step: any store to an argument with a weird type
        may force the argument to be any type.
        
        This patch basically duplicates the functionality in DFGSpeculativeJIT64.cpp for
        GetLocal: the decision of whether to load a local as an int32 (or as an array, or as
        a boolean) is made based on the AbstractValue::m_type, which is a type proof, rather
        than the VariableAccessData::prediction(), which is a predicted type.

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

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