Revert "Introducing the Platform Abstraction Layer (PAL)"

[WebKit-https.git] / Source / JavaScriptCore / ChangeLog

2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>

        Revert "Introducing the Platform Abstraction Layer (PAL)"
        https://bugs.webkit.org/show_bug.cgi?id=144751

        Unreviewed.

        PAL should be a new target inside WebCore, rather than a top-level folder.

        * Configurations/FeatureDefines.xcconfig: Updated

2015-05-07  Basile Clement  <basile_clement@apple.com>

        Dumping OSR ExitValue should expand materializations only once
        https://bugs.webkit.org/show_bug.cgi?id=144694

        Reviewed by Filip Pizlo.

        Currently, dumping OSR exit values will print the full materialization
        information each time it is encountered. We change it to print only a
        brief description (only the materialization's address), and print the
        whole set of materializations later on.

        This makes the dump less confusing (less likely to think that two
        instances of the same materialization are different), and will be a
        necessary change if/when we support materialization cycles.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dumpInContext):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):

2015-05-07  Andreas Kling  <akling@apple.com>

        Worker threads leak WeakBlocks (as seen on leaks bot)
        <https://webkit.org/b/144721>
        <rdar://problem/20848288>

        Reviewed by Darin Adler.

        Nuke any remaining empty WeakBlocks when the Heap is being torn down.
        Trying to peek into these blocks after the VM is dead would be a bug anyway.

        This fixes a ~750 KB leak seen on the leaks bot.

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

2015-05-05  Geoffrey Garen  <ggaren@apple.com>

        Don't branch when accessing the callee
        https://bugs.webkit.org/show_bug.cgi?id=144645

        Reviewed by Michael Saboff.

        The branch was added in <http://trac.webkit.org/changeset/81040> without
        explanation.

        kling found it to be a performance problem. See <https://webkit.org/b/144586>.

        Our theory of access to Registers is that it's up to the client to access
        them in the right way. So, let's do that.

        * interpreter/CallFrame.h:
        (JSC::ExecState::callee):
        (JSC::ExecState::setCallee): Call the field object instead of function
        because nothing guarantees that it's a function.
        * interpreter/ProtoCallFrame.h:
        (JSC::ProtoCallFrame::callee):
        (JSC::ProtoCallFrame::setCallee):
        * interpreter/Register.h:
        * runtime/JSObject.h:
        (JSC::Register::object): Just do a cast like our other accessors do.
        (JSC::Register::operator=):
        (JSC::Register::function): Deleted.
        (JSC::Register::withCallee): Deleted.

2015-05-07  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
        https://bugs.webkit.org/show_bug.cgi?id=144727

        Reviewed by Darin Adler.

        * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
        INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.

2015-05-07  Andreas Kling  <akling@apple.com>

        Special-case Int32 values in JSON.stringify().
        <https://webkit.org/b/144731>

        Reviewed by Michael Saboff.

        Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
        simple integers through the full-blown dtoa() machinery.

        ~50% speedup on Kraken/json-stringify-tinderbox.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>

        ToT WebKit crashes while loading ES6 compatibility table
        https://bugs.webkit.org/show_bug.cgi?id=144726

        Reviewed by Filip Pizlo.

        The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.

        Always build the identifier here as it could be a method name.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
        https://bugs.webkit.org/show_bug.cgi?id=144665

        Reviewed by Michael Saboff.
        
        This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
        extending SaneChain to all indexing shapes.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
        (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
        (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.

2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>

        Introducing the Platform Abstraction Layer (PAL)
        https://bugs.webkit.org/show_bug.cgi?id=143358

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig: Updated

2015-05-06  Andreas Kling  <akling@apple.com>

        Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
        <https://webkit.org/b/144676>

        Reviewed by Darin Adler.

        We were creating a new String for every number JSValue passing through the JSON stringifier.
        These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
        Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
        for the conversion instead.

        13% progression on Kraken/json-stringify-tinderbox.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):

2015-05-06  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183847.
        https://bugs.webkit.org/show_bug.cgi?id=144691

        Caused many assertion failures (Requested by ap on #webkit).

        Reverted changeset:

        "GC has trouble with pathologically large array allocations"
        https://bugs.webkit.org/show_bug.cgi?id=144609
        http://trac.webkit.org/changeset/183847

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        PutGlobalVar shouldn't have an unconditional store barrier
        https://bugs.webkit.org/show_bug.cgi?id=133104

        Reviewed by Benjamin Poulain.
        
        We don't need a store barrier on PutGlobalVar if the value being stored can be
        speculated to not be a cell.

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

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
        https://bugs.webkit.org/show_bug.cgi?id=144667

        Reviewed by Andreas Kling.
        
        We are now calling this method for oversize blocks. It had an assertion that indirectly
        implied that the block is not oversize, because it was claiming that the number of live
        bytes should be smaller than the non-oversize-block size.

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

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        GC has trouble with pathologically large array allocations
        https://bugs.webkit.org/show_bug.cgi?id=144609

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::updateObjectCounts): Make this code less confusing.
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
        * jsc.cpp: Add size measuring hooks to write the largeish test.
        (GlobalObject::finishCreation):
        (functionGCAndSweep):
        (functionFullGC):
        (functionEdenGC):
        (functionHeapSize):
        * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
        * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
        (foo):
        (test):

2015-05-05  Filip Pizlo  <fpizlo@apple.com>

        FTL SwitchString slow case creates duplicate switch cases
        https://bugs.webkit.org/show_bug.cgi?id=144634

        Reviewed by Geoffrey Garen.
        
        The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
        added mostly-debug-only asserts to catch such issues earlier.

        * bytecode/CallVariant.cpp:
        (JSC::variantListWithVariant): Assertion to prevent similar bugs.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
        (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
        * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
        (foo):
        (cat):

2015-05-05  Basile Clement  <basile_clement@apple.com>

        Fix debug builds after r183812
        https://bugs.webkit.org/show_bug.cgi?id=144300

        Rubber stamped by Andreas Kling and Filip Pizlo.

        hasObjectMaterializationData() didn't treat MaterializeCreateActivation
        as having materialization data, which was causing an assertion failure when
        sinking CreateActivations on debug builds.

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

2015-05-04  Basile Clement  <basile_clement@apple.com>

        Allow CreateActivation sinking
        https://bugs.webkit.org/show_bug.cgi?id=144300

        Reviewed by Filip Pizlo.

        This pursues the work started in
        https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
        allocations we are able to sink by allowing sinking of CreateActivation
        node.

        This is achieved by following closely the way NewObject is currently
        sunk: we add a new PhantomCreateActivation node to record the initial
        position of the CreateActivation node, new ClosureVarPLoc promoted heap
        locations to keep track of the variables put in the activation, and a
        new MaterializeCreateActivation node to allocate and populate the sunk
        activation.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutClosureVarHint):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomCreateActivation):
        (JSC::DFG::Node::isActivationAllocation):
        (JSC::DFG::Node::isPhantomActivationAllocation):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
        (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * tests/stress/activation-sink-osrexit.js: Added.
        (bar):
        (foo.set result):
        * tests/stress/activation-sink.js: Added.
        (bar):

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

        Unreviewed, fix stale comment.

        * tests/mozilla/js1_5/Array/regress-101964.js:

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

        Large array shouldn't be slow
        https://bugs.webkit.org/show_bug.cgi?id=144617

        Rubber stamped by Mark Lam.

        * tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.

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

        Large array shouldn't be slow
        https://bugs.webkit.org/show_bug.cgi?id=144617

        Rubber stamped by Mark Lam.

        * tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.

2015-05-04  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183789.
        https://bugs.webkit.org/show_bug.cgi?id=144620

        Causing flakiness on exceptionFuzz tests locally on 32-bit
        build (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "Global functions should be initialized as JSFunctions in byte
        code"
        https://bugs.webkit.org/show_bug.cgi?id=144178
        http://trac.webkit.org/changeset/183789

2015-05-04  Saam Barati  <saambarati1@gmail.com>

        Global functions should be initialized as JSFunctions in byte code
        https://bugs.webkit.org/show_bug.cgi?id=144178

        Reviewed by Geoffrey Garen.

        This patch makes the initialization of global functions more explicit by
        moving initialization into bytecode. It also prepares JSC for having ES6
        style lexical scoping because initializing global functions in bytecode
        easily allows global functions to be initialized with the proper scope that
        will have access to global lexical variables. Global lexical variables
        should be visible to global functions but don't live on the global object.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedProgramCodeBlock::visitChildren):
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addFunction):
        * runtime/JSGlobalObject.h:

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

        Large array shouldn't be slow
        https://bugs.webkit.org/show_bug.cgi?id=144617

        Reviewed by Geoffrey Garen.
        
        Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
        you're already using ArrayStorage mode, from the minimul array length required to use
        ArrayStorage in a new Array(length) allocation.
        
        Lift the array allocation length threshold to something very high. If this works, we'll
        probably remove that threshold entirely.
        
        This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
        JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
        for now.

        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
        * runtime/ArrayConventions.h:
        * runtime/JSArray.h:
        (JSC::JSArray::create):
        * runtime/JSGlobalObject.h:
        (JSC::constructEmptyArray):
        * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.

2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        Add backed intrinsics to private functions exposed with private symbols in global object
        https://bugs.webkit.org/show_bug.cgi?id=144545

        Reviewed by Darin Adler.

        Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
        This patch adds intrinsic to private functions exposed with private symbols in global object,
        @floor and @abs.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalPrivateFuncAbs): Deleted.
        (JSC::globalPrivateFuncFloor): Deleted.
        * runtime/MathObject.cpp:
        * runtime/MathObject.h:
        * tests/stress/array-from-abs-and-floor.js: Added.
        (target1):
        (target2):
        (target3):

2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] ARM related build system cleanup
        https://bugs.webkit.org/show_bug.cgi?id=144566

        Reviewed by Darin Adler.

        * CMakeLists.txt:

2015-05-04  Andreas Kling  <akling@apple.com>

        Optimize WeakBlock's "reap" and "visit" operations.
        <https://webkit.org/b/144585>

        Reviewed by Geoffrey Garen.

        WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
        That function was really written with conservative roots marking in mind, and will do a bunch
        of sanity and bounds checks.

        For weaks, we know that the pointer will have been a valid cell pointer into a block
        of appropriate cell size, so we can skip a lot of the checks.

        We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
        MarkedBlock::blockFor() for every single cell when iterating.

        Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
        WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
        be pointing to any live cells, and the only operation that will run on the block is sweep().

        Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
        In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
        This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.

        This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
        what looks like a 1% speedup locally.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
        block's state is known to be either Marked or Retired.

        (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
        would report that all cells are live anyway.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.

        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.

        * heap/WeakBlock.h:
        (JSC::WeakBlock::disconnectMarkedBlock): Added.
        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
        ownership to Heap until it can die peacefully.

        (JSC::WeakSet::addAllocator):
        * heap/WeakSet.h:
        (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.

2015-05-04  Basile Clement  <basile_clement@apple.com>

        Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
        https://bugs.webkit.org/show_bug.cgi?id=144587

        Rubber stamped by Filip Pizlo.

        When sinking object allocations, we ensure in
        determineMaterializationPoints that whenever an allocation is
        materialized on a path to a block, it is materialized in all such
        paths. Thus when running the SSA calculator to place Phis in
        placeMaterializationPoints, we can't encounter a situation where some
        Upsilons are referring to a materialization while others are referring
        to the phantom object.

        This replaces the code that was adding a materialization late in
        placeMaterializationPoints to handle that case by an assertion that it
        does not happen, which will make
        https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):

2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>

        Extending undefined in class syntax should throw a TypeError
        https://bugs.webkit.org/show_bug.cgi?id=144284

        Reviewed by Darin Adler.

        The bug was caused by op_eq_null evaluating to true when compared to undefined.
        Explicitly check op_eq_undefined first to detect the case where we're extending undefined.

        We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.

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

2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>

        new super should be a syntax error
        https://bugs.webkit.org/show_bug.cgi?id=144282

        Reviewed by Joseph Pecoraro.

        Disallow "new super" as ES6 spec doesn't allow this.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):

2015-05-04  Saam Barati  <saambarati1@gmail.com>

        JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
        https://bugs.webkit.org/show_bug.cgi?id=144265

        Reviewed by Geoffrey Garen.

        JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
        for a static function if the parent has that property slot. JSCallbackObject::put 
        did not maintain this symmetry of also calling ::put on the parent if the parent 
        has the property. We should ensure that this symmetry exists.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::put):
        * API/tests/testapi.c:
        * API/tests/testapi.js:
        (globalStaticFunction2):
        (this.globalStaticFunction2):
        (iAmNotAStaticFunction):
        (this.iAmNotAStaticFunction):

2015-05-04  Andreas Kling  <akling@apple.com>

        Make ExecState::vm() branchless in release builds.
        <https://webkit.org/b/144586>

        Reviewed by Geoffrey Garen.

        Avoid null checking the ExecState's callee() before getting the
        VM from it. The code was already dereferencing it anyway, since we
        know it's not gonna be null.

        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):

2015-05-04  Basile Clement  <basile_clement@apple.com>

        Object allocation not sinking properly through CheckStructure
        https://bugs.webkit.org/show_bug.cgi?id=144465

        Reviewed by Filip Pizlo.

        Currently, sinking an allocation through a CheckStructure will
        completely ignore all structure checking, which is obviously wrong.

        A CheckStructureImmediate node type was present for that purpose, but
        the CheckStructures were not properly replaced.  This ensures that
        CheckStructure nodes are replaced by CheckStructureImmediate nodes when
        sunk through, and that structure checking happens correctly.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
        (JSC::DFG::Node::hasStructureSet):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
        (JSC::FTL::LowerDFGToLLVM::checkStructure):
        * tests/stress/sink_checkstructure.js: Added.
        (foo):

2015-05-01  Geoffrey Garen  <ggaren@apple.com>

        REGRESSION(r183570): jslib-traverse-jquery is 22% slower
        https://bugs.webkit.org/show_bug.cgi?id=144476

        Reviewed by Sam Weinig.

        jslib-traverse-jquery is now 31% faster than its unregressed baseline.

        The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
        to my knowledge, the topic of how to optimize it is not covered in any
        literature about sorting.

        On the slowest jQuery sorting test -- prevAll -- our new
        Array.prototype.sort, compared to its predecessor, performed 12% fewer
        comparisons and requireed 10X less overhead per comparison. Yet, it was
        slower.

        It was slower because it inadvertantly increased the average cost of the
        comparison function by 2X. jQuery uses compareDocumentPosition to compare
        DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
        required to traverse backwards from b to a. In prevAll, we encounter the
        worst case for merge sort of compareDocumentPosition: A long list of DOM
        nodes in mostly reverse order. In this case, merge sort will sequentially
        compareDocumentPosition(a, b), where a is not reachable backwards from
        b, and therefore compareDocumentPosition will traverse the whole sibling
        list.

        The solution is simple enough: Call compareDocumentPosition(b, a) instead.

        This is a pretty silly thing to do, but it is harmless, and jQuery is
        popular, so let's do it.

        We do not risk suffering the same problem in reverse when sorting a long
        list of DOM nodes in forward order. (We still have a 37% speedup on the
        nextAll benchmark.) The reason is that merge sort performs 2X fewer
        comparisons when the list is already sorted, so we can worry less about
        the cost of each comparison.

        A fully principled soultion to this problem would probably do something
        like Python's timsort, which special-cases ordered ranges to perform
        only O(n) comparisons. But that would contradict our original
        goal of just having something simple that works.

        Another option is for elements to keep a compareDocumentPosition cache,
        like a node list cache, which allows you to determine the absolute
        position of a node using a hash lookup. I will leave this as an exercise
        for kling.

        * builtins/Array.prototype.js:
        (sort.merge): Compare in an order that is favorable to a comparator
        that calls compareDocumentPosition.

2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix generate-js-builtins related incremental build issue
        https://bugs.webkit.org/show_bug.cgi?id=144094

        Reviewed by Michael Saboff.

        * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
        Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
        * DerivedSources.make:
        Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
        * generate-js-builtins: Accept input files and input directory too.

2015-05-03  Simon Fraser  <simon.fraser@apple.com>

        Make some static data const
        https://bugs.webkit.org/show_bug.cgi?id=144552

        Reviewed by Andreas Kling.
        
        Turn characterSetInfo into const data.

        * yarr/YarrCanonicalizeUCS2.cpp:
        * yarr/YarrCanonicalizeUCS2.h:

2015-05-01  Filip Pizlo  <fpizlo@apple.com>

        TypeOf should be fast
        https://bugs.webkit.org/show_bug.cgi?id=144396

        Reviewed by Geoffrey Garen.
        
        Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
        are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
        TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
        
        This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
        rely heavily on C++ calls to fulfill their function.
        
        Because TypeOf is now so fast, we no longer need to do any speculations on this node.
        
        In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
        This means that if the TypeOf is dominated by any type checks, we will automatically prune
        out cases that are redundant.
        
        This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
        code generation is designed to be reusable.
        
        This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
        the exotic call trap hook. That hook is now in a deeper slow path than before.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
        (JSC::DFG::SpeculativeJIT::compileIsFunction):
        (JSC::DFG::SpeculativeJIT::compileTypeOf):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
        (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
        (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
        (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
        * ftl/FTLSwitchCase.h:
        (JSC::FTL::SwitchCase::SwitchCase):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNotEqual):
        (JSC::AssemblyHelpers::branchIfEqual):
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        (JSC::AssemblyHelpers::branchIfBoolean):
        (JSC::AssemblyHelpers::branchIfNotBoolean):
        (JSC::AssemblyHelpers::boxBooleanPayload):
        (JSC::AssemblyHelpers::boxBoolean):
        (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
        * jit/JITOperations.h:
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::typeString):
        * runtime/TypeofType.cpp: Added.
        (WTF::printInternal):
        * runtime/TypeofType.h: Added.
        * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.

2015-05-02  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):

2015-05-02  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
        https://bugs.webkit.org/show_bug.cgi?id=144525.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGPhantomInsertionPhase.cpp:

2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>

        Static property hashtable should only lookup with non-symbol key
        https://bugs.webkit.org/show_bug.cgi?id=144438

        Reviewed by Darin Adler.

        Static property hashtable compares the Identifier's uid
        with the normal C string without interning it.
        So this comparison is performed in their contents.
        As the result, in this comparison, symbol-ness is not considered.

        So if accidentally the hash collision occur with the symbol and the string
        and they have the same contents, the hash table entry is looked up incorrectly.

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

2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>

        Class syntax should allow string and numeric identifiers for method names
        https://bugs.webkit.org/show_bug.cgi?id=144254

        Reviewed by Darin Adler.

        Added the support for string and numeric identifiers in class syntax.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
        inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
        outside a class constructor as it should be.
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
        element to allow numeric and string method names. For both of those method names, parse it here instead
        of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
        (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
        this function is never used to parse a class method.
        (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
        (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty):

2015-05-01  Filip Pizlo  <fpizlo@apple.com>

        FTL should use AI more
        https://bugs.webkit.org/show_bug.cgi?id=144500

        Reviewed by Oliver Hunt.
        
        This makes our type check folding even more comprehensive by ensuring that even if the FTL
        decides to emit some checks, it will still do another query to the abstract interpreter to
        see if the check is necessary. This helps with cases where we decided early on to speculate
        one way, but later proved a more specific type of the value in question, and the constant
        folder didn't catch it.
        
        This also makes it more natural to query the abstract interpreter. For example, if you just
        want the proven type, you can now say provenType(node) or provenType(edge).

        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::alreadyChecked):
        * dfg/DFGArrayMode.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
        (JSC::FTL::LowerDFGToLLVM::compileToThis):
        (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithPow):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::LowerDFGToLLVM::compileGetById):
        (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
        (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
        (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
        (JSC::FTL::LowerDFGToLLVM::compileIsString):
        (JSC::FTL::LowerDFGToLLVM::compileIsObject):
        (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
        (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
        (JSC::FTL::LowerDFGToLLVM::baseIndex):
        (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
        (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
        (JSC::FTL::LowerDFGToLLVM::boolify):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::lowInt32):
        (JSC::FTL::LowerDFGToLLVM::lowInt52):
        (JSC::FTL::LowerDFGToLLVM::lowCell):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        (JSC::FTL::LowerDFGToLLVM::lowDouble):
        (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
        (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
        (JSC::FTL::LowerDFGToLLVM::isNumber):
        (JSC::FTL::LowerDFGToLLVM::isNotNumber):
        (JSC::FTL::LowerDFGToLLVM::isNotCell):
        (JSC::FTL::LowerDFGToLLVM::isCell):
        (JSC::FTL::LowerDFGToLLVM::isNotMisc):
        (JSC::FTL::LowerDFGToLLVM::isMisc):
        (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
        (JSC::FTL::LowerDFGToLLVM::isBoolean):
        (JSC::FTL::LowerDFGToLLVM::isNotOther):
        (JSC::FTL::LowerDFGToLLVM::isOther):
        (JSC::FTL::LowerDFGToLLVM::isProvenValue):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::isString):
        (JSC::FTL::LowerDFGToLLVM::isFunction):
        (JSC::FTL::LowerDFGToLLVM::isNotFunction):
        (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
        (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
        (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
        (JSC::FTL::LowerDFGToLLVM::abstractValue):
        (JSC::FTL::LowerDFGToLLVM::provenType):
        (JSC::FTL::LowerDFGToLLVM::provenValue):
        (JSC::FTL::LowerDFGToLLVM::abstractStructure):

2015-05-01  Martin Robinson  <mrobinson@igalia.com>

        USE(...) macro should expect unprefixed variables
        https://bugs.webkit.org/show_bug.cgi?id=144454

        Reviewed by Daniel Bates.

        * CMakeLists.txt: Replace all occurrences WTF_USE with USE.

2015-05-01  Jordan Harband  <ljharb@gmail.com>

        String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
        https://bugs.webkit.org/show_bug.cgi?id=144314

        Reviewed by Darin Adler.

        Fixing handling of Infinity position args, per
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith

        * runtime/StringPrototype.cpp:
        (JSC::clampInt32):
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):

2015-05-01  Basile Clement  <basile_clement@apple.com>

        Math.abs() returns negative
        https://bugs.webkit.org/show_bug.cgi?id=137827

        Reviewed by Michael Saboff.

        Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
        identity function.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * tests/stress/math-abs-positive.js: Added, was previously failing.
        (foo):

2015-05-01  Basile Clement  <basile_clement@apple.com>

        Function allocation sinking shouldn't be performed on singleton functions
        https://bugs.webkit.org/show_bug.cgi?id=144166

        Reviewed by Geoffrey Garen.

        Function allocations usually are free of any other side effects, but
        this is not the case for allocations performed while the underlying
        FunctionExecutable is still a singleton (as this allogation will fire
        watchpoints invalidating code that depends on it being a singleton).
        As the object allocation sinking phase assumes object allocation is
        free of side-effects, sinking these allocations is not correct.

        This also means that when materializing a function allocation on OSR
        exit, that function's executable will never be a singleton, and we don't have
        to worry about its watchpoint, allowing us to use
        JSFunction::createWithInvalidatedRellocationWatchpoint instead of
        JSFunction::create.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):

2015-04-30  Jon Davis  <jond@apple.com>

        Web Inspector: console should show an icon for console.info() messages
        https://bugs.webkit.org/show_bug.cgi?id=18530

        Reviewed by Timothy Hatcher.

        * inspector/ConsoleMessage.cpp:
        (Inspector::messageLevelValue):
        * inspector/protocol/Console.json:
        * runtime/ConsoleClient.cpp:
        (JSC::appendMessagePrefix):
        * runtime/ConsolePrototype.cpp:
        (JSC::ConsolePrototype::finishCreation):
        (JSC::consoleProtoFuncInfo):
        * runtime/ConsoleTypes.h:

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
        https://bugs.webkit.org/show_bug.cgi?id=144462

        Reviewed by Geoffrey Garen and Mark Lam.
        
        At some point we started adding representation-agnostic helpers for doing common type tests.
        We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
        they had overlapping powers, though SpeculativeJIT was a bit better.
        
        This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
        better because now all of these helpers can be used in all of the assembly-based JITs, not
        just the DFG. It also settles on what I find to be a slightly better naming convention.
        For example where we previously would have said branchIsString, now we say
        branchIfString. Similarly, branchNotString becomes branchIfNotString.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
        (JSC::DFG::SpeculativeJIT::speculateNotCell):
        (JSC::DFG::SpeculativeJIT::speculateOther):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
        (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
        (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
        (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfCell):
        (JSC::AssemblyHelpers::branchIfOther):
        (JSC::AssemblyHelpers::branchIfNotOther):
        (JSC::AssemblyHelpers::branchIfObject):
        (JSC::AssemblyHelpers::branchIfNotObject):
        (JSC::AssemblyHelpers::branchIfType):
        (JSC::AssemblyHelpers::branchIfNotType):
        (JSC::AssemblyHelpers::branchIfString):
        (JSC::AssemblyHelpers::branchIfNotString):
        (JSC::AssemblyHelpers::branchIfSymbol):
        (JSC::AssemblyHelpers::branchIfNotSymbol):
        (JSC::AssemblyHelpers::branchIfFunction):
        (JSC::AssemblyHelpers::branchIfNotFunction):
        (JSC::AssemblyHelpers::branchIfEmpty):
        (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
        (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitScopedArgumentsGetByVal):

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
        https://bugs.webkit.org/show_bug.cgi?id=144463

        Reviewed by Benjamin Poulain.
        
        Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
        into a Check(String:@x) followed by JSConstant(true). Then in these tests the
        ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
        converting the boolean into an integer. But as part of doing that, it would try to
        short-circuit any profiling by leveraging the fact that the IsString is now a constant,
        and it would try to figure out if the addition might overflow. Part of that logic
        involved checking if the immediate is either a boolean or a sufficiently small integer.
        But: it would check if it's a sufficiently small integer before checking if it was a
        boolean, so it would try to call asNumber() on the boolean.
        
        All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
        case was previously never hit until I wrote these tests, and so we never knew that
        calling asNumber() on a boolean was wrong.
        
        The fix is super simple: the expression should just check for boolean first.
        
        This bug was benign in release builds. JSValue::asNumber() on a boolean would return
        garbage, and that's OK, since we'd take the boolean case anyway.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.

        * jit/JITOperations.cpp:

2015-04-30  Filip Pizlo  <fpizlo@apple.com>

        Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
        particular that they cannot change their minds and may be called from compiler threads.

        Rubber stamped by Geoffrey Garen.

        * runtime/JSCell.h:

2015-04-29  Filip Pizlo  <fpizlo@apple.com>

        DFG Is<Blah> versions of TypeOf should fold based on proven input type
        https://bugs.webkit.org/show_bug.cgi?id=144409

        Reviewed by Geoffrey Garen.
        
        We were missing some obvious folding opportunities here. I don't know how this affects real
        code, but in general, we like to ensure that our constant folding is comprehensive. So this
        is more about placating my static analysis OCD than anything else.
        
        I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Use the default hash value for Symbolized StringImpl
        https://bugs.webkit.org/show_bug.cgi?id=144347

        Reviewed by Darin Adler.

        Before this patch, symbolized StringImpl* has a special hash value
        to avoid the hash collision with the other normal StringImpl*.
        I guess that it is introduced when private symbols are introduced.
        However, it prevents using symbolized StringImpl* in the other place
        For example, using it as WTFString cause a problem because of its special hash value.

        When only using private symbols, they are not exposed to the outside of JSC,
        so we can handle it carefully. But now, it's extended to symbols.
        So I think storing a special hash value in StringImpl* causes an error.

        To avoid this, I propose using the usual hash value in symbolized StringImpl*.
        And to provide significantly different hash value when using it as symbol,
        store the additional hash value in symbolized StringImpl*. It is used when
        the hash value is required by IdentifierRepHash.

        * runtime/Identifier.h:
        (JSC::IdentifierRepHash::hash):
        * runtime/Lookup.h:
        (JSC::HashTable::entry):
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::get):
        * runtime/Structure.cpp:
        (JSC::PropertyTable::checkConsistency):

2015-04-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove RageConvert array conversion
        https://bugs.webkit.org/show_bug.cgi?id=144433

        Reviewed by Filip Pizlo.

        RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
        pretty hard:
        -The indexing types shows that the array access varies between Int32 and DoubleArray.
        -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
         An Arrayify node would convert the Int32 to that type.
        -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
         node would use RageConvert instead of Convert.
        -The Arrayify for that GetByVal with RageConvert would not convert the array to
         Contiguous.
        -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
         now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
         fail systematically and we never get to run the later code.

        Getting rid of RageConvert fixes the problem and does not seems to have any
        negative side effect on other benchmarks.

        The improvments on Kraken are:
            -stanford-crypto-aes: definitely 1.0915x faster.
            -stanford-crypto-pbkdf2: definitely 1.2446x faster.
            -stanford-crypto-sha256-iterative: definitely 1.0544x faster.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::arrayConversionToString):
        * dfg/DFGArrayMode.h:
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
        * runtime/JSObject.cpp:
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
        (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
        (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::rageEnsureContiguous): Deleted.

2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        Gracefully handle missing auto pause key on remote inspector setup
        https://bugs.webkit.org/show_bug.cgi?id=144411

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):

2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        NodeList has issues with Symbol and empty string
        https://bugs.webkit.org/show_bug.cgi?id=144310

        Reviewed by Darin Adler.

        * runtime/PropertyName.h:
        (JSC::PropertyName::isSymbol):
        Helper to check if the PropertyName is a string or symbol property.

2015-04-29  Alex Christensen  <achristensen@webkit.org>

        Fix non-cygwin incremental builds on Windows.
        https://bugs.webkit.org/show_bug.cgi?id=143264

        Reviewed by Brent Fulgham.

        * generate-js-builtins:
        Remove stale headers before calling os.rename to replace them.

2015-04-29  Filip Pizlo  <fpizlo@apple.com>

        JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
        https://bugs.webkit.org/show_bug.cgi?id=144397

        Reviewed by Andreas Kling.
        
        Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
        callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
        making a getCallData() call if it isn't necessary.

        * API/JSCallbackObject.h:
        * runtime/InternalFunction.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::typeOfShouldCallGetCallData):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        * tests/stress/type-of-functions-and-objects.js: Added.
        (foo):
        (bar):
        (baz):
        (fuzz):
        (expect):
        (test):

2015-04-28  Geoffrey Garen  <ggaren@apple.com>

        It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
        https://bugs.webkit.org/show_bug.cgi?id=144013

        Reviewed by Mark Lam.

        This patch implements Array.prototype.sort in JavaScript, removing the
        C++ implementations. It is simpler and less error-prone to express our
        operations in JavaScript, which provides memory safety, exception safety,
        and recursion safety.

        The performance result is mixed, but net positive in my opinion. It's
        difficult to enumerate all the results, since we used to have so many
        different sorting modes, and there are lots of different data patterns
        across which you might want to measure sorting. Suffice it to say:

            (*) The benchmarks we track are faster or unchanged.

            (*) Sorting random input using a comparator -- which we think is
            common -- is 3X faster.

            (*) Sorting random input in a non-array object -- which jQuery does
            -- is 4X faster.

            (*) Sorting random input in a compact array of integers using a
            trivial pattern-matchable comparator is 2X *slower*.

        * builtins/Array.prototype.js:
        (sort.min):
        (sort.stringComparator):
        (sort.compactSparse): Special case compaction for sparse arrays because
        we don't want to hang when sorting new Array(BIG).

        (sort.compact):
        (sort.merge):
        (sort.mergeSort): Use merge sort because it's a reasonably efficient
        stable sort. We have evidence that some sites depend on stable sort,
        even though the ES6 spec does not mandate it. (See
        <http://trac.webkit.org/changeset/33967>.)

        This is a textbook implementation of merge sort with three optimizations:

            (1) Use iteration instead of recursion;

            (2) Use array subscripting instead of array copying in order to
            create logical sub-lists without creating physical sub-lists;

            (3) Swap src and dst at each iteration instead of copying src into
            dst, and only copy src into the subject array at the end if src is
            not the subject array.

        (sort.inflate):
        (sort.comparatorSort):
        (sort): Sort in JavaScript for the win.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
        names so we can use helper functions.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isNumericCompareFunction): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
        (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode): We don't do this special casing based
        on pattern matching anymore. This was mainly an optimization to avoid 
        the overhead of calling from C++ to JS, which we now avoid by
        sorting in JS.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::pushTempSortVector): Deleted.
        (JSC::Heap::popTempSortVector): Deleted.
        (JSC::Heap::visitTempSortVectors): Deleted.
        * heap/Heap.h: We don't have temp sort vectors anymore because we sort
        in JavaScript using a normal JavaScript array for our temporary storage.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
        helper functions.

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

        * runtime/CommonIdentifiers.h: New strings used by sort.

        * runtime/JSArray.cpp:
        (JSC::compareNumbersForQSortWithInt32): Deleted.
        (JSC::compareNumbersForQSortWithDouble): Deleted.
        (JSC::compareNumbersForQSort): Deleted.
        (JSC::compareByStringPairForQSort): Deleted.
        (JSC::JSArray::sortNumericVector): Deleted.
        (JSC::JSArray::sortNumeric): Deleted.
        (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
        (JSC::JSArray::sortCompactedVector): Deleted.
        (JSC::JSArray::sort): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
        (JSC::JSArray::sortVector): Deleted.
        (JSC::JSArray::compactForSorting): Deleted.
        * runtime/JSArray.h:

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation): Provide some builtins used
        by sort.

2015-04-29  Mark Lam  <mark.lam@apple.com>

        Safari WebKit crash when loading Google Spreadsheet.
        https://bugs.webkit.org/show_bug.cgi?id=144020

        Reviewed by Filip Pizlo.

        The bug is that the object allocation sinking phase did not account for a case
        where a property of a sunken object is only initialized on one path and not
        another.  As a result, on the path where the property is not initialized, we'll
        encounter an Upsilon with a BottomValue (which is not allowed by definition).

        The fix is to use a JSConstant(undefined) as the bottom value instead (of
        BottomValue).  If the property is uninitialized, it should still be accessible
        and have the value undefined.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
        * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
        (foo):
        (foo2):

2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
        https://bugs.webkit.org/show_bug.cgi?id=144257

        Reviewed by Darin Adler.

        SHA1 is used to calculate CodeBlockHash.
        To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
        However, the source code can contain null character.
        So when performing `strlen` on the source code's CString, it returns the incorrect length.
        In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.

        In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
        As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.

        CString will be changed not to contain a null-character[1]. However, inserting the assertion here
        is not correct. Because

        1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
        2. If CString can contain a null character, this assertion becomes incorrect.

        So this patch just drops the assertion.

        In the current implementation, we once convert the entire source code to the newly allocated
        UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
        Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
        We'll implement it in the separate patch[2].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
        [2]: https://bugs.webkit.org/show_bug.cgi?id=144263

        * tests/stress/eval-script-contains-null-character.js: Added.
        (shouldBe):
        (test):
        * tests/stress/template-literal-line-terminators.js:
        * tests/stress/template-literal-syntax.js:
        * tests/stress/template-literal.js:

2015-04-29  Filip Pizlo  <fpizlo@apple.com>

        Evict IsEnvironmentRecord from inline type flags
        https://bugs.webkit.org/show_bug.cgi?id=144398

        Reviewed by Mark Lam and Michael Saboff.
        
        In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
        type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
        and evicts it into the out-of-line type flags. This change has no performance implications
        because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
        where we access it at all is in String.prototype.repeat, and there we already load the
        structure anyway.

        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::implementsHasInstance):
        (JSC::TypeInfo::structureIsImmortal):
        (JSC::TypeInfo::isEnvironmentRecord):

2015-04-29  Darin Adler  <darin@apple.com>

        [ES6] Implement Unicode code point escapes
        https://bugs.webkit.org/show_bug.cgi?id=144377

        Reviewed by Antti Koivisto.

        * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
        the header. Made it a non-member class so it doesn't need to be part
        of a template. Made it use UChar32 instead of int for the value to
        make it clearer what goes into this class.
        (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
        old type() function.
        (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
        parseFourDigitUnicodeHex and added support for code point escapes.
        (JSC::isLatin1): Added an overload for UChar32.
        (JSC::isIdentStart): Changed this to take UChar32; no caller tries
        to call it with a UChar, so no need to overload for that type for now.
        (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
        Also added FIXME about a subtle ES6 change that we might want to make later.
        (JSC::isIdentPart): Changed this to take UChar32; no caller tries
        to call it with a UChar, so no need to overload for that type for now.
        (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
        don't need to repeat the code twice. Added code to handle code point escapes.
        (JSC::isIdentPartIncludingEscape): Call the template instead of having the
        code in line.
        (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
        (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
        updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
        (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
        instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
        the code that handles the escapes, since the code point escape code now
        consumes characters while parsing rather than peeking ahead. Test case
        covers this: Symptom would be that "\u{" would evaluate to "u" instead of
        giving a syntax error.

        * parser/Lexer.h: Updated for above changes.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
        out 0x10FFFF; clearer this way.

2015-04-29  Martin Robinson  <mrobinson@igalia.com>

        [CMake] [GTK] Organize and clean up unused CMake variables
        https://bugs.webkit.org/show_bug.cgi?id=144364

        Reviewed by Gyuyoung Kim.

        * PlatformGTK.cmake: Add variables specific to this project.

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        TypeOf should return SpecStringIdent and the DFG should know this
        https://bugs.webkit.org/show_bug.cgi?id=144376

        Reviewed by Andreas Kling.
        
        Make TypeOf return atomic strings. That's a simple change in SmallStrings.
        
        Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
        bad.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setType):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::setType):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::initialize):
        * tests/stress/switch-typeof-indirect.js: Added.
        (bar):
        (foo):
        (test):
        * tests/stress/switch-typeof-slightly-indirect.js: Added.
        (foo):
        (test):
        * tests/stress/switch-typeof.js: Added.
        (foo):
        (test):

2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
        https://bugs.webkit.org/show_bug.cgi?id=144373

        Reviewed by Darin Adler.

        Revert r181868 as it caused a failure on live.com. We can try
        re-enabling this exception after we make idl attributes configurable,
        which may have prevented this particular failure.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):

2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>

        Deadlock on applications using JSContext on non-main thread
        https://bugs.webkit.org/show_bug.cgi?id=144370

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):
        Prevent a possible deadlock by assuming we can synchronously
        run something on the main queue at this time.

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        FTL should fully support Switch (it currently lacks the SwitchString variant)
        https://bugs.webkit.org/show_bug.cgi?id=144348

        Reviewed by Benjamin Poulain.
        
        This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
        in LayoutTests/js/regress.

        * dfg/DFGCommon.cpp:
        (JSC::DFG::stringLessThan):
        * dfg/DFGCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::switchString):
        (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
        (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
        (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
        (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
        (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
        (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::check):
        * ftl/FTLOutput.h:
        * ftl/FTLWeight.h:
        (JSC::FTL::Weight::inverse):
        * jit/JITOperations.h:

2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
        https://bugs.webkit.org/show_bug.cgi?id=144304

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
        ENABLE_LLINT_C_LOOP, disabled by default.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.

2015-04-28  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183514.
        https://bugs.webkit.org/show_bug.cgi?id=144359

        It broke cloop test bots (Requested by mcatanzaro on #webkit).

        Reverted changeset:

        "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
        https://bugs.webkit.org/show_bug.cgi?id=144304
        http://trac.webkit.org/changeset/183514

2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
        https://bugs.webkit.org/show_bug.cgi?id=144304

        Reviewed by Geoffrey Garen.

        * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
        ENABLE_LLINT_C_LOOP, disabled by default.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.

2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>

        Fix common typo "targetting" => "targeting"
        https://bugs.webkit.org/show_bug.cgi?id=144349

        Reviewed by Daniel Bates.

        * bytecode/ExecutionCounter.h:

2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
        https://bugs.webkit.org/show_bug.cgi?id=144328

        Reviewed by Andreas Kling.

        Update the status of ES6 features.

        * features.json:

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        DFG should not use or preserve Phantoms during transformations
        https://bugs.webkit.org/show_bug.cgi?id=143736

        Reviewed by Geoffrey Garen.
        
        Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
        no longer necessary to preserve Phantoms during transformations. They are still useful just
        before FixupPhase to support backwards propagation analyses. They are still inserted late in the
        game in the DFG backend. But transformations don't need to worry about them. Inside a basic
        block, we can be sure that so long as the IR pinpoints the place where the value becomes
        available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
        other block would need the value (either for OSR or for DFG execution), then we don't need any
        liveness markers.
        
        So, this removes any places where we inserted Phantoms just for liveness during transformation
        and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
        Check node only keeps its children so long as those children have checks.
        
        The fact that we no longer convertToPhantom() means that we have to be more careful when
        constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
        Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
        a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
        Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
        GetLocals.
        
        The only Phantom-like cruft left over after this patch is:
        
        - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
          backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
          the users of the original local's live range in bytecode. This is essential for supporting our
          BackwardsPropagationPhase, which is an important optimization for things like asm.js.
        
        - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
          https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
          alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
          the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
          treat GetLocal/SetLocal conservatively, this should all be sound.
        
        This change should be perf-neutral although it does reduce the total work that the compiler
        does.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAdjacencyList.h:
        (JSC::DFG::AdjacencyList::justChecks):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::replaceTerminal):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
        (JSC::DFG::CPSRethreadingPhase::clearVariables):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
        (JSC::DFG::CleanUpPhase::CleanUpPhase):
        (JSC::DFG::CleanUpPhase::run):
        (JSC::DFG::performCleanUp):
        (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
        (JSC::DFG::PhantomRemovalPhase::run): Deleted.
        (JSC::DFG::performPhantomRemoval): Deleted.
        * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
        (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        (JSC::DFG::DCEPhase::fixupBlock):
        (JSC::DFG::DCEPhase::cleanVariables):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupBlock):
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::convertStringAddUse):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::fixIntConvertingEdge):
        (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
        (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
        (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
        (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
        (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
        (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
        (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::convertToConstant):
        (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
        * dfg/DFGGraph.h:
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertCheck):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::remove):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::replaceWith):
        (JSC::DFG::Node::convertToPhantom): Deleted.
        (JSC::DFG::Node::convertToCheck): Deleted.
        (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
        * dfg/DFGNodeFlags.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
        * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
        * dfg/DFGPhantomRemovalPhase.cpp: Removed.
        * dfg/DFGPhantomRemovalPhase.h: Removed.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
        * dfg/DFGResurrectionForValidationPhase.h: Removed.
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        * dfg/DFGStoreBarrierElisionPhase.cpp:
        (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):
        (JSC::DFG::Validate::validateSSA):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileNoOp):
        (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.

2015-04-28  Andreas Kling  <akling@apple.com>

        DFG+FTL should generate efficient code for branching on a string's boolean value.
        <https://webkit.org/b/144317>

        Reviewed by Geoff Garen & Filip Pizlo

        Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
        instead of dropping out to C++ whenever we branch on a string.

        The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
        the DFG JIT gets some new codegen logic in this patch.

        Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitStringBranch):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitBranch):

2015-04-28  Filip Pizlo  <fpizlo@apple.com>

        VarargsForwardingPhase should only consider MovHints that have the candidate as a child
        https://bugs.webkit.org/show_bug.cgi?id=144340

        Reviewed by Michael Saboff and Mark Lam.
        
        Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
        CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
        Basically, we'd keep it alive until the end of the block. This maximized the chances of
        there being an interfering operation, which would prevent elimination.
        
        The fix is to only consider MovHints that have the arguments candidate as a child. We only
        care to track the liveness of those bytecode locals that would need an arguments object
        recovery on OSR exit.
        
        This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
        introduced in http://trac.webkit.org/changeset/183406.

        * dfg/DFGVarargsForwardingPhase.cpp:

2015-04-28  Csaba Osztrogonác  <ossy@webkit.org>

        Remove WinCE cruft from cmake build system
        https://bugs.webkit.org/show_bug.cgi?id=144325

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:
        * create_jit_stubs: Removed.

2015-04-27  Andreas Kling  <akling@apple.com>

        RegExp matches arrays should use contiguous indexing.
        <https://webkit.org/b/144286>

        Reviewed by Geoffrey Garen.

        We had a custom Structure being used for RegExp matches arrays that would
        put the arrays into SlowPutArrayStorageShape mode. This was just left
        from when matches arrays were custom, lazily initialized objects.

        This change removes that Structure and switches the matches arrays to
        using the default ContiguousShape Structure. This allows the FTL JIT
        to compile the inner loop of the Octane/regexp benchmark.

        Also made a version of initializeIndex() [inline] that takes the indexing
        type in an argument, allowing createRegExpMatchesArray() to initialize
        the entire array without branching on the indexing type for each entry.

        ~3% progression on Octane/regexp.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2015-04-27  Filip Pizlo  <fpizlo@apple.com>

        FTL failed to initialize arguments.callee on the slow path as well as the fast path
        https://bugs.webkit.org/show_bug.cgi?id=144293

        Reviewed by Mark Lam.
        
        The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
        to initialize the callee on the common path after the fast and slow path.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
        * tests/stress/arguments-callee-uninitialized.js: Added.
        (foo):

2015-04-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add support for typed arrays to the Array profiling
        https://bugs.webkit.org/show_bug.cgi?id=143913

        Reviewed by Filip Pizlo.

        This patch adds ArrayModes for every typed arrays. Having that information
        let us generate better GetByVal and PutByVal when the type speculation
        are not good enough.

        A typical case where this is useful is any basic block for which the type
        of the object is always more restrictive than the speculation (for example, 
        a basic block gated by a branch only taken for on type).

        * bytecode/ArrayProfile.cpp:
        (JSC::dumpArrayModes):
        * bytecode/ArrayProfile.h:
        (JSC::arrayModeFromStructure):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::refine):
        Maintain the refine() semantic. We do not support OutOfBounds access
        for GetByVal on typed array.

        * runtime/IndexingType.h:
        * tests/stress/typed-array-get-by-val-profiling.js: Added.
        (testArray.testCode):
        (testArray):
        * tests/stress/typed-array-put-by-val-profiling.js: Added.
        (testArray.testCode):
        (testArray):

2015-04-27  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
        causes many debug test failures.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpMatchesArrayStructure):
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2015-04-27  Andreas Kling  <akling@apple.com>

        RegExp matches arrays should use contiguous indexing.
        <https://webkit.org/b/144286>

        Reviewed by Geoffrey Garen.

        We had a custom Structure being used for RegExp matches arrays that would
        put the arrays into SlowPutArrayStorageShape mode. This was just left
        from when matches arrays were custom, lazily initialized objects.

        This change removes that Structure and switches the matches arrays to
        using the default ContiguousShape Structure. This allows the FTL JIT
        to compile the inner loop of the Octane/regexp benchmark.

        Also made a version of initializeIndex() [inline] that takes the indexing
        type in an argument, allowing createRegExpMatchesArray() to initialize
        the entire array without branching on the indexing type for each entry.

        ~3% progression on Octane/regexp.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):

2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
        https://bugs.webkit.org/show_bug.cgi?id=144257

        Temporarily disable skip these tests.

        * tests/stress/template-literal-line-terminators.js:
        * tests/stress/template-literal-syntax.js:
        * tests/stress/template-literal.js:

2015-04-27  Basile Clement  <basile_clement@apple.com>

        Function allocations shouldn't sink through Put operations
        https://bugs.webkit.org/show_bug.cgi?id=144176

        Reviewed by Filip Pizlo.

        By design, we don't support function allocation sinking through any
        related operation ; however object allocation can sink through PutByOffset et
        al.

        Currently, the checks to prevent function allocation to sink through
        these are misguided and do not prevent anything ; function allocation sinking
        through these operations is prevented as a side effect of requiring an
        AllocatePropertyStorage through which the function allocation is seen as
        escaping.

        This changes it so that ObjectAllocationSinkingPhase::handleNode()
        checks properly that only object allocations sink through related write
        operations.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):

2015-04-25  Filip Pizlo  <fpizlo@apple.com>

        VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
        https://bugs.webkit.org/show_bug.cgi?id=143843

        Reviewed by Geoffrey Garen.
        
        It will soon come to pass that Phantom isn't available at the time that
        VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
        a value dies for OSR.
        
        This is simplified by two things:
        
        1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
           before by polishing the API.
        
        2) This phase already operates on one node at a time and allows itself to do a full search
           of the enclosing basic block for that node. This is fine because CreateDirectArguments
           and friends is a rarely occurring node. The fact that it operates on one node at a time
           makes it even easier to reason about OSR liveness - we just track the list of locals in
           which it is live.
        
        This change has no effect right now but it is a necessary prerequisite to implementing
        https://bugs.webkit.org/show_bug.cgi?id=143736.

        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::tryAt):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGPhantomInsertionPhase.cpp:
        * dfg/DFGVarargsForwardingPhase.cpp:

2015-04-27  Jordan Harband  <ljharb@gmail.com>

        Map#entries and Map#keys error for non-Maps is swapped
        https://bugs.webkit.org/show_bug.cgi?id=144253

        Reviewed by Simon Fraser.

        Correcting error messages on Set/Map methods when called on
        incompatible objects.

        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncEntries):
        (JSC::mapProtoFuncKeys):
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncEntries):

2015-04-24  Filip Pizlo  <fpizlo@apple.com>

        Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
        https://bugs.webkit.org/show_bug.cgi?id=144186

        Reviewed by Geoffrey Garen.
        
        If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
        Int32. We may later perform code simplifications based on the proof that this is Int32, and
        we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
        which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
        except that we still need the overflow check!

        Previously we mishandled this:

        - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
          to keep it alive. That's dirty and it's just indicative of a deeper issue.

        - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
          powerless. This was sort of hiding the bug.

        - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
          something that you are relying on for subsequent simplifications.
        
        This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
        nodes that may perform checks that are used by AI to guarantee the result type. As a result,
        we no longer need the weird MustGenerate node.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPhantomCanonicalizationPhase.cpp:
        (JSC::DFG::PhantomCanonicalizationPhase::run):
        * dfg/DFGPhantomRemovalPhase.cpp:
        (JSC::DFG::PhantomRemovalPhase::run):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
        (foo):
        * tests/stress/fold-based-on-int32-proof-mul.js: Added.
        (foo):
        * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
        (foo):
        * tests/stress/fold-based-on-int32-proof.js: Added.
        (foo):

2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>

        Class body ending with a semicolon throws a SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=144244

        Reviewed by Darin Adler.

        The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
        it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
        it by continue'ing when it encounters a semicolon.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):

2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>

        Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=144243

        Reviewed by Darin Adler.

        Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseGetterSetter):

2015-04-26  Jordan Harband  <ljharb@gmail.com>

        Map#forEach does not pass "map" argument to callback.
        https://bugs.webkit.org/show_bug.cgi?id=144187

        Reviewed by Darin Adler.

        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
        step 7.a.i., the callback should be called with three arguments.

        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncForEach):

2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement ES6 template literals
        https://bugs.webkit.org/show_bug.cgi?id=142691

        Reviewed by Darin Adler.

        This patch implements TemplateLiteral.
        Since TaggedTemplate requires some global states and
        primitive operations like GetTemplateObject,
        we separate the patch. It will be implemented in a subsequent patch.

        Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
        By disabling it, we can disable Template Literal support.

        To implement template literals, in this patch,
        we newly introduces bytecode op_to_string.
        In template literals, we alternately evaluate the expression and
        perform ToString onto the result of evaluation.
        For example,

        `${f1()} ${f2()}`

        In this template literal, execution order is the following,
        1. calling f1()
        2. ToString(the result of f1())
        3. calling f2()
        4. ToString(the result of f2())

        op_strcat also performs ToString. However, performing ToString
        onto expressions are batched in op_strcat, it's not the same to the
        template literal spec. In the above example,
        ToString(f1()) should be called before calling f2().

        * Configurations/FeatureDefines.xcconfig:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToString):
        (JSC::BytecodeGenerator::emitToNumber): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TemplateStringNode::emitBytecode):
        (JSC::TemplateLiteralNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emitSlow_op_to_string):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emitSlow_op_to_string):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTemplateString):
        (JSC::ASTBuilder::createTemplateStringList):
        (JSC::ASTBuilder::createTemplateExpressionList):
        (JSC::ASTBuilder::createTemplateLiteral):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::Lexer<T>::parseIdentifierSlowCase):
        (JSC::Lexer<T>::parseString):
        (JSC::LineNumberAdder::LineNumberAdder):
        (JSC::LineNumberAdder::clear):
        (JSC::LineNumberAdder::add):
        (JSC::Lexer<T>::parseTemplateLiteral):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer<T>::scanRegExp):
        (JSC::Lexer<T>::scanTrailingTemplateString):
        (JSC::Lexer<T>::parseStringSlowCase): Deleted.
        * parser/Lexer.h:
        * parser/NodeConstructors.h:
        (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
        (JSC::TemplateStringNode::TemplateStringNode):
        (JSC::TemplateStringListNode::TemplateStringListNode):
        (JSC::TemplateLiteralNode::TemplateLiteralNode):
        * parser/Nodes.h:
        (JSC::TemplateExpressionListNode::value):
        (JSC::TemplateExpressionListNode::next):
        (JSC::TemplateStringNode::cooked):
        (JSC::TemplateStringNode::raw):
        (JSC::TemplateStringListNode::value):
        (JSC::TemplateStringListNode::next):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseTemplateString):
        (JSC::Parser<LexerType>::parseTemplateLiteral):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createTemplateString):
        (JSC::SyntaxChecker::createTemplateStringList):
        (JSC::SyntaxChecker::createTemplateExpressionList):
        (JSC::SyntaxChecker::createTemplateLiteral):
        (JSC::SyntaxChecker::createSpreadExpression): Deleted.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/stress/template-literal-line-terminators.js: Added.
        (test):
        (testEval):
        (testEvalLineNumber):
        * tests/stress/template-literal-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        * tests/stress/template-literal.js: Added.
        (test):
        (testEval):
        (testEmbedded):

2015-04-26  Jordan Harband  <ljharb@gmail.com>

        Set#forEach does not pass "key" or "set" arguments to callback.
        https://bugs.webkit.org/show_bug.cgi?id=144188

        Reviewed by Darin Adler.

        Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
        Set#forEach should pass 3 arguments to the callback.

        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncForEach):

2015-04-26  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Implement Math.clz32(), remove Number.clz()
        https://bugs.webkit.org/show_bug.cgi?id=144205

        Reviewed by Michael Saboff.

        This patch adds the ES6 function Math.clz32(), and remove the non-standard
        Number.clz(). Number.clz() probably came from an older draft.

        The new function has a corresponding instrinsic: Clz32Intrinsic,
        and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::countLeadingZeros32):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::bsr_rr):
        The x86 assembler did not have countLeadingZeros32() because there is
        no native CLZ instruction on that architecture.

        I have added the version with bsr + branches for the case of zero.
        An other popular version uses cmov to handle the case of zero. I kept
        it simple since the Assembler has no support for cmov.

        It is unlikely to matter much. If the code is hot enough, LLVM picks
        something good based on the surrounding code.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        Constant handling + effect propagation. The node only produces integer (between 0 and 32).

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        Thanks to the definition of toUint32(), we can ignore plenty of details
        from doubles.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithClz32):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::ctlz32):
        * jit/ThunkGenerators.cpp:
        (JSC::clz32ThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/Intrinsic.h:
        * runtime/MathCommon.h:
        (JSC::clz32):
        Fun fact: InstCombine does not recognize this pattern to eliminate
        the branch which makes our FTL version better than the C version.

        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        (JSC::mathProtoFuncClz32):
        * runtime/NumberPrototype.cpp:
        (JSC::clz): Deleted.
        (JSC::numberProtoFuncClz): Deleted.
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        * tests/stress/math-clz32-basics.js: Added.
        (mathClz32OnInteger):
        (testMathClz32OnIntegers):
        (verifyMathClz32OnIntegerWithOtherTypes):
        (mathClz32OnDouble):
        (testMathClz32OnDoubles):
        (verifyMathClz32OnDoublesWithOtherTypes):
        (mathClz32NoArguments):
        (mathClz32TooManyArguments):
        (testMathClz32OnConstants):
        (mathClz32StructTransition):
        (Math.clz32):

2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Array.from need to accept iterables
        https://bugs.webkit.org/show_bug.cgi?id=141055

        Reviewed by Darin Adler.

        ES6 spec requires that Array.from accepts iterable objects.
        This patch introduces this functionality, Array.from accepting iterable objects.

        Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
        However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
        `typeof thisObj === "function"` queries the given object has `[[Call]]`.
        This will be fixed in the subsequent patch[1].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=144093

        * builtins/ArrayConstructor.js:
        (from):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * tests/stress/array-from-with-iterable.js: Added.
        (shouldBe):
        (.set for):
        (.set var):
        (.get var):
        (argumentsGenerators):
        (.set shouldBe):
        (.set new):
        * tests/stress/array-from-with-iterator.js: Added.
        (shouldBe):
        (shouldThrow):
        (createIterator.iterator.return):
        (createIterator):
        (.):

2015-04-25  Jordan Harband  <ljharb@gmail.com>

        Set#keys !== Set#values
        https://bugs.webkit.org/show_bug.cgi?id=144190

        Reviewed by Darin Adler.

        per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
        Set#keys should === Set#values

        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::setProtoFuncValues):
        (JSC::setProtoFuncEntries):
        (JSC::setProtoFuncKeys): Deleted.

2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>

        Allow for pausing a JSContext when opening a Web Inspector
        <rdar://problem/20564788>

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        * inspector/remote/RemoteInspectorConstants.h:
        * inspector/remote/RemoteInspectorDebuggable.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.mm:
        (Inspector::RemoteInspectorDebuggableConnection::setup):
        On any incoming setup message, we may want to automatically
        pause the debuggable. If requested, pause the debuggable
        after we have setup the frontend connection.

        * runtime/JSGlobalObjectDebuggable.h:
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::pause):
        Pass through to the inspector controller.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::pause):
        Enable pause on next statement.

2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>

        class methods should be non-enumerable
        https://bugs.webkit.org/show_bug.cgi?id=143181

        Reviewed by Darin Adler.

        Fixed the bug by using Object.defineProperty to define methods.

        This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
        inside CodeBlock's constructor since bytecode can be linked against multiple global objects.

        * bytecode/CodeBlock.cpp: 
        (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
        index of zero.
        * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
        exactly one entry for Object.defineProperty.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
        constant register for the link time constant we're adding.
        (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
        register for the specified link time constant and notify UnlinkedCodeBlock about it.
        (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
        Object.defineProperty with it.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
        non-enumerable by using emitCallDefineProperty to define them.
        (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
        (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
        property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
        (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::definePropertyFunction): Added.
        (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
        (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
        returns a JSCell; e.g. Object.defineProperty.
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
        * runtime/ObjectConstructor.h:

2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement String.fromCodePoint
        https://bugs.webkit.org/show_bug.cgi?id=144160

        Reviewed by Darin Adler.

        This patch implements String.fromCodePoint.
        It accepts multiple code points and generates a string that consists of given code points.
        The range [0x0000 - 0x10FFFF] is valid for code points.
        If the given value is out of range, throw a range error.

        When a 0xFFFF <= valid code point is given,
        String.fromCodePoint generates a string that contains surrogate pairs.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCodePoint):
        (JSC::constructWithStringConstructor):
        * tests/stress/string-from-code-point.js: Added.
        (shouldBe):
        (shouldThrow):
        (toCodePoints):
        (passThrough):

2015-04-25  Martin Robinson  <mrobinson@igalia.com>

        Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
        https://bugs.webkit.org/show_bug.cgi?id=144182

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.

2015-04-25  Mark Lam  <mark.lam@apple.com>

        mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
        https://bugs.webkit.org/show_bug.cgi?id=144152

        Reviewed by Filip Pizlo.

        Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
        StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
        OSR exits.  This was overlooked in the original code.

        While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
        the Branch node, the other 3 may also trigger the same bug for other nodes.
        To prevent this bug from manifesting with other nodes (and future ones that
        are yet to be added to mayExits()'s "potential won't exit" set), we fix the
        EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).

        Also added a test to exercise a code path that will trigger this bug with
        the Branch node before the fix is applied.

        * dfg/DFGMayExit.cpp:
        * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
        (inlinedFunction):
        (foo):

2015-04-24  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r183288.
        https://bugs.webkit.org/show_bug.cgi?id=144189

        Made js/sort-with-side-effecting-comparisons.html time out in
        debug builds (Requested by ap on #webkit).

        Reverted changeset:

        "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
        array."
        https://bugs.webkit.org/show_bug.cgi?id=144013
        http://trac.webkit.org/changeset/183288

2015-04-24  Filip Pizlo  <fpizlo@apple.com>

        CRASH in operationCreateDirectArgumentsDuringExit()
        https://bugs.webkit.org/show_bug.cgi?id=143962

        Reviewed by Geoffrey Garen.
        
        We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
        recoverable so long as they are live. Therefore, OSR exit should track liveness of
        constants instead of assuming that they are always live.

        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::noticeOSRBirth):
        (JSC::DFG::GenerationInfo::appendBirth):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGVariableEvent.cpp:
        (JSC::DFG::VariableEvent::dump):
        * dfg/DFGVariableEvent.h:
        (JSC::DFG::VariableEvent::birth):
        (JSC::DFG::VariableEvent::id):
        (JSC::DFG::VariableEvent::dataFormat):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
        (foo):
        (bar):
        * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
        (foo):
        (bar):

2015-04-24  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
        https://bugs.webkit.org/show_bug.cgi?id=144169

        Reviewed by Geoffrey Garen.

        * runtime/JSObject.cpp:
        (JSC::JSObject::convertInt32ForValue):
        DoubleArray do not store NaN, they are used for holes.
        What happened was:
        1) We fail to insert the NaN in the Int32 array because it is a double.
        2) We were converting the array to DoubleArray.
        3) We were trying to insert the value again. We would fail again because
           DoubleArray does not store NaN.
        4) We would convert the DoubleArrayt to Contiguous Array, converting the values
           to boxed values.

        * tests/stress/int32array-transition-on-nan.js: Added.
        The behavior is not really observable. This only test nothing crashes in those
        cases.

        (insertNaNWhileFilling):
        (testInsertNaNWhileFilling):
        (insertNaNAfterFilling):
        (testInsertNaNAfterFilling):
        (pushNaNWhileFilling):
        (testPushNaNWhileFilling):

2015-04-21  Geoffrey Garen  <ggaren@apple.com>

        It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
        https://bugs.webkit.org/show_bug.cgi?id=144013

        Reviewed by Mark Lam.

        This patch implements Array.prototype.sort in JavaScript, removing the
        C++ implementations. It is simpler and less error-prone to express our
        operations in JavaScript, which provides memory safety, exception safety,
        and recursion safety.

        The performance result is mixed, but net positive in my opinion. It's
        difficult to enumerate all the results, since we used to have so many
        different sorting modes, and there are lots of different data patterns
        across which you might want to measure sorting. Suffice it to say:

            (*) The benchmarks we track are faster or unchanged.

            (*) Sorting random input using a comparator -- which we think is
            common -- is 3X faster.

            (*) Sorting random input in a non-array object -- which jQuery does
            -- is 4X faster.

            (*) Sorting random input in a compact array of integers using a
            trivial pattern-matchable comparator is 2X *slower*.

        * builtins/Array.prototype.js:
        (sort.min):
        (sort.stringComparator):
        (sort.compactSparse): Special case compaction for sparse arrays because
        we don't want to hang when sorting new Array(BIG).

        (sort.compact):
        (sort.merge):
        (sort.mergeSort): Use merge sort because it's a reasonably efficient
        stable sort. We have evidence that some sites depend on stable sort,
        even though the ES6 spec does not mandate it. (See
        <http://trac.webkit.org/changeset/33967>.)

        This is a textbook implementation of merge sort with three optimizations:

            (1) Use iteration instead of recursion;

            (2) Use array subscripting instead of array copying in order to
            create logical sub-lists without creating physical sub-lists;

            (3) Swap src and dst at each iteration instead of copying src into
            dst, and only copy src into the subject array at the end if src is
            not the subject array.

        (sort.inflate):
        (sort.comparatorSort):
        (sort): Sort in JavaScript for the win.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
        names so we can use helper functions.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isNumericCompareFunction): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
        (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode): We don't do this special casing based
        on pattern matching anymore. This was mainly an optimization to avoid 
        the overhead of calling from C++ to JS, which we now avoid by
        sorting in JS.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::pushTempSortVector): Deleted.
        (JSC::Heap::popTempSortVector): Deleted.
        (JSC::Heap::visitTempSortVectors): Deleted.
        * heap/Heap.h: We don't have temp sort vectors anymore because we sort
        in JavaScript using a normal JavaScript array for our temporary storage.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
        helper functions.

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

        * runtime/CommonIdentifiers.h: New strings used by sort.

        * runtime/JSArray.cpp:
        (JSC::compareNumbersForQSortWithInt32): Deleted.
        (JSC::compareNumbersForQSortWithDouble): Deleted.
        (JSC::compareNumbersForQSort): Deleted.
        (JSC::compareByStringPairForQSort): Deleted.
        (JSC::JSArray::sortNumericVector): Deleted.
        (JSC::JSArray::sortNumeric): Deleted.
        (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
        (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
        (JSC::JSArray::sortCompactedVector): Deleted.
        (JSC::JSArray::sort): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
        (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
        (JSC::JSArray::sortVector): Deleted.
        (JSC::JSArray::compactForSorting): Deleted.
        * runtime/JSArray.h:

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation): Provide some builtins used
        by sort.

2015-04-24  Matthew Mirman  <mmirman@apple.com>

        Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
        https://bugs.webkit.org/show_bug.cgi?id=141865
        rdar://problem/19927273

        Reviewed by Filip Pizlo.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):

2015-04-23  Benjamin Poulain  <bpoulain@apple.com>

        Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
        https://bugs.webkit.org/show_bug.cgi?id=144118

        Reviewed by Geoffrey Garen.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateMachineInt):
        Both block do the same thing.

2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Speculative fix for non-main thread auto-attach failures
        https://bugs.webkit.org/show_bug.cgi?id=144134

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):

2015-04-23  Basile Clement  <basile_clement@apple.com>

        Allow function allocation sinking
        https://bugs.webkit.org/show_bug.cgi?id=144016

        Reviewed by Filip Pizlo.

        This adds the ability to sink function allocations in the
        DFGObjectAllocationSinkingPhase.

        In order to enable this, we add a new PhantomNewFunction node that is
        used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
        a sunk NewFunction and keep track of the allocations that have to be performed
        in case of OSR exit after the sunk allocation but before the real one.
        The FunctionExecutable and JSLexicalEnvironment (activation) of the function
        are stored onto the PhantomNewFunction through PutHints in order for them
        to be recovered on OSR exit.

        Contrary to sunk object allocations, sunk function allocations do not
        support any kind of operations (e.g. storing into a field) ; any such operation
        will mark the function allocation as escaping and trigger materialization. As
        such, function allocations can only be sunk to places where it would have been
        correct to syntactically move them, and we don't need a special
        MaterializeNewFunction node to recover possible operations on the function. A
        sunk NewFunction node will simply create new NewFunction nodes, then replace
        itself with a PhantomNewFunction node.

        In itself, this change is not expected to have a significant impact on
        performances other than in degenerate cases (see e.g.
        JSRegress/sink-function), but it is a step towards being able to sink recursive
        closures onces we support CreateActivation sinking as well as allocation cycles
        sinking.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToPhantomNewFunction):
        (JSC::DFG::Node::isPhantomAllocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
        (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * tests/stress/function-sinking-no-double-allocate.js: Added.
        (call):
        (.f):
        (sink):
        * tests/stress/function-sinking-osrexit.js: Added.
        (.g):
        (sink):
        * tests/stress/function-sinking-put.js: Added.
        (.g):
        (sink):

2015-04-23  Basile Clement  <basile_clement@apple.com>

        Make FunctionRareData allocation thread-safe
        https://bugs.webkit.org/show_bug.cgi?id=144001

        Reviewed by Mark Lam.

        The two things we want to prevent are:

         1. A thread seeing a pointer to a not-yet-fully-created rare data from
            a JSFunction
         2. A thread seeing a pointer to a not-yet-fully-created Structure from
            an ObjectAllocationProfile

        For 1., only the JS thread can be creating the rare data (in
        runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
        worry about concurrent writes, and we don't need any fences when *reading* the
        rare data from the JS thread. Thus we only need a storeStoreFence between the
        rare data creation and assignment to m_rareData in
        JSFunction::createAndInitializeRareData() to ensure that when the store to
        m_rareData is issued, the rare data has been properly created.

        For the DFG compilation threads, the only place they can access the
        rare data is through JSFunction::rareData(), and so we only need a
        loadLoadFence there to ensure that when we see a non-null pointer in
        m_rareData, the pointed object will be seen as a fully created
        FunctionRareData.


        For 2., the structure is created in
        ObjectAllocationProfile::initialize() (which appears to be called only by the
        JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
        which always happen in the JS thread), and read through
        ObjectAllocationProfile::structure() and
        ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
        put a storeStoreFence in ObjectAllocationProfile::initialize() and a
        loadLoadFence in ObjectAllocationProfile::structure() (and change
        ObjectAllocationProfile::inlineCapacity() to go through
        ObjectAllocationProfile::structure()).

        We don't need a fence in ObjectAllocationProfile::clear() because
        clearing the structure is already as atomic as it gets.

        Finally, notice that we don't care about the ObjectAllocationProfile's
        m_allocator as that is only used by ObjectAllocationProfile::initialize() and
        ObjectAllocationProfile::clear() that are always run in the JS thread.
        ObjectAllocationProfile::isNull() could cause some trouble, but it is
        currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
        thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
        thread anyway.

        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfile::initialize):
        (JSC::ObjectAllocationProfile::structure):
        (JSC::ObjectAllocationProfile::inlineCapacity):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::allocateAndInitializeRareData):
        * runtime/JSFunction.h:
        (JSC::JSFunction::rareData):
        (JSC::JSFunction::allocationStructure): Deleted.
        This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.

2015-04-22  Filip Pizlo  <fpizlo@apple.com>

        DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
        https://bugs.webkit.org/show_bug.cgi?id=143735

        Reviewed by Geoffrey Garen.
        
        We've always had bugs arising from the fact that we would MovHint something into a local,
        and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
        on those Nodes that were MovHinted. But this became increasingly tricky. Given the
        sophistication of the transformations we are doing today, this approach is just not sound
        anymore.
        
        This comprehensively fixes these bugs by having the DFG backend automatically insert
        Phantoms just before codegen based on bytecode liveness. To make this practical, this also
        makes it much faster to query bytecode liveness.
        
        It's about as perf-neutral as it gets for a change that increases compiler work without
        actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
        which should then speed us up. I can't really report concrete slow-down numbers because
        they are low enough to basically be in the noise. For example, a 20-iteration run of
        SunSpider yields "maybe 0.8% slower", whatever that means.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        * bytecode/FullBytecodeLiveness.h:
        (JSC::FullBytecodeLiveness::getLiveness):
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::operator+):
        (JSC::VirtualRegister::operator-):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllLiveNodesAtTail):
        (JSC::DFG::forAllKilledOperands):
        (JSC::DFG::forAllKilledNodesAtNodeIndex):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        (JSC::DFG::Graph::localsLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        (JSC::DFG::Graph::forAllLiveInBytecode):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMovHintRemovalPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGPhantomInsertionPhase.cpp: Added.
        (JSC::DFG::performPhantomInsertion):
        * dfg/DFGPhantomInsertionPhase.h: Added.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGScoreBoard.h:
        (JSC::DFG::ScoreBoard::sortFree):
        (JSC::DFG::ScoreBoard::assertClear):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        * tests/stress/phantom-inadequacy.js: Added.
        (bar):
        (baz):
        (foo):

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

        Rename HardPhantom to MustGenerate.

        Rubber stamped by Geoffrey Garen.
        
        We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
        is more than that; it's a utility for forcing the execution of otherwise killable nodes.
        NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
        node should just be called MustGenerate.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPhantomCanonicalizationPhase.cpp:
        (JSC::DFG::PhantomCanonicalizationPhase::run):
        * dfg/DFGPhantomRemovalPhase.cpp:
        (JSC::DFG::PhantomRemovalPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2015-04-23  Jordan Harband  <ljharb@gmail.com>

        Implement `Object.assign`
        https://bugs.webkit.org/show_bug.cgi?id=143980

        Reviewed by Filip Pizlo.

        per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign

        * builtins/ObjectConstructor.js: Added.
        (assign):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectConstructor.h:

2015-04-22  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix debug build.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::performSubstitutionForEdge):

2015-04-22  Filip Pizlo  <fpizlo@apple.com>

        Nodes should have an optional epoch field
        https://bugs.webkit.org/show_bug.cgi?id=144084

        Reviewed by Ryosuke Niwa and Mark Lam.
        
        This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
        https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
        used.

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGEpoch.h:
        (JSC::DFG::Epoch::fromUnsigned):
        (JSC::DFG::Epoch::toUnsigned):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::clearReplacements):
        (JSC::DFG::Graph::clearEpochs):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::performSubstitutionForEdge):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::replaceWith):
        (JSC::DFG::Node::replacement):
        (JSC::DFG::Node::setReplacement):
        (JSC::DFG::Node::epoch):
        (JSC::DFG::Node::setEpoch):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):

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

        Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
        https://bugs.webkit.org/show_bug.cgi?id=143898

        Reviewed by Filip Pizlo.

        CodeBlock::dumpSource() will access SourceCode strings in a way that requires
        ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
        compilation threads because StringImpls are not thread safe. As a result, we get
        an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
        build.

        This patch fixes the issue by only collecting the CodeBlock (and associated info)
        into a DeferredSourceDump record while compiling, and stashing it away in a
        deferredSourceDump list in the DeferredCompilationCallback object to be dumped
        later.

        When compilation is done, the callback object will be notified that
        compilationDidComplete().  We will dump the SourceCode strings from there. 
        Since compilationDidComplete() is guaranteed to only be called on the thread
        doing JS execution, it is safe to access the SourceCode strings there and ref
        their underlying StringImpls as needed.        

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/DeferredCompilationCallback.cpp:
        (JSC::DeferredCompilationCallback::compilationDidComplete):
        (JSC::DeferredCompilationCallback::sourceDumpInfo):
        (JSC::DeferredCompilationCallback::dumpCompiledSources):
        * bytecode/DeferredCompilationCallback.h:
        * bytecode/DeferredSourceDump.cpp: Added.
        (JSC::DeferredSourceDump::DeferredSourceDump):
        (JSC::DeferredSourceDump::dump):
        * bytecode/DeferredSourceDump.h: Added.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):

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

        Implement String.codePointAt()
        https://bugs.webkit.org/show_bug.cgi?id=143934

        Reviewed by Darin Adler.

        This patch adds String.codePointAt() as defined by ES6.
        I opted for a C++ implementation for now.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::codePointAt):
        (JSC::stringProtoFuncCodePointAt):

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

        SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
        https://bugs.webkit.org/show_bug.cgi?id=144067

        Reviewed by Michael Saboff.

        Currently, there are a few places where the JSObject that owns the
        SparseArrayValueMap is designated as the owner of the SparseArrayEntry
        write barrier.  This is a bug and can result in the GC collecting the
        SparseArrayEntry even though it is being referenced by the
        SparseArrayValueMap.  This patch fixes the bug.

        * runtime/JSObject.cpp:
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
        (JSC::JSObject::putIndexedDescriptor):
        * tests/stress/sparse-array-entry-update-144067.js: Added.
        (useMemoryToTriggerGCs):
        (foo):

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

        Give the heap object iterators the ability to return early.
        https://bugs.webkit.org/show_bug.cgi?id=144011

        Reviewed by Michael Saboff.

        JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
        candidate cell pointers, and, when in use, is called a lot more often than
        the normal way those iterators are used.  As a result, I see my instrumented
        VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
        callback functor the ability to tell the iterators to return early when the
        functor no longer needs to continue iterating.  With this, my instrumented
        VM is useful again for debugging.

        Since heap iteration is not something that we do in a typical fast path,
        I don't expect this to have any noticeable impact on performance.

        I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
        it checks JSCell addresses, not just JSObjects.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        * heap/GCLogging.cpp:
        (JSC::LoggingFunctor::operator()):
        * heap/Heap.cpp:
        (JSC::Zombify::visit):
        (JSC::Zombify::operator()):
        * heap/HeapStatistics.cpp:
        (JSC::StorageStatistics::visit):
        (JSC::StorageStatistics::operator()):
        * heap/HeapVerifier.cpp:
        (JSC::GatherLiveObjFunctor::visit):
        (JSC::GatherLiveObjFunctor::operator()):
        * heap/MarkedBlock.cpp:
        (JSC::SetNewlyAllocatedFunctor::operator()):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::forEachCell):
        (JSC::MarkedBlock::forEachLiveCell):
        (JSC::MarkedBlock::forEachDeadCell):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::forEachLiveCell):
        (JSC::MarkedSpace::forEachDeadCell):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::TypeRecompiler::visit):
        (Inspector::TypeRecompiler::operator()):
        * runtime/IterationStatus.h: Added.
        * runtime/JSGlobalObject.cpp:
        * runtime/VM.cpp: