ChangeLog   [plain text]


2016-09-14  Babak Shafiei  <bshafiei@apple.com>

        Merge r205882. rdar://problem/28233331

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

            DFG NewArrayBuffer node should watch for "have a bad time" state change.
            https://bugs.webkit.org/show_bug.cgi?id=161927
            <rdar://problem/27995222>

            Reviewed by Geoffrey Garen.

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

2016-09-13  Babak Shafiei  <bshafiei@apple.com>

        Merge r205895. rdar://problem/28287070

    2016-09-13  Michael Saboff  <msaboff@apple.com>

            Promises aren't resolved properly when making a ObjC API callback
            https://bugs.webkit.org/show_bug.cgi?id=161929

            Reviewed by Geoffrey Garen.

            When we go to call out to an Objective C function registered via the API,
            we first drop all JSC locks to make the call.  As part of dropping the locks,
            we drain the microtask queue that is used among other things for handling deferred
            promise resolution.  The DropAllLocks scope class that drops the locks while in
            scope, resets the current thread's AtomicStringTable to the default table.  This
            is wrong for two reasons, first it happens before we drain the microtask queue and
            second it isn't needed as JSLock::willReleaseLock() restores the current thread's
            AtomicStringTable to the table before the lock was acquired.

            In fact, the manipulation of the current thread's AtomicStringTable is already
            properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock().
            Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor
            and destructor should be removed.

            * API/tests/testapi.mm:
            (testObjectiveCAPIMain): Added a new test.
            * runtime/JSLock.cpp:
            (JSC::JSLock::DropAllLocks::DropAllLocks):
            (JSC::JSLock::DropAllLocks::~DropAllLocks):

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r204403. rdar://problem/27991568

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

            OverridesHasInstance should not branch across register allocations.
            https://bugs.webkit.org/show_bug.cgi?id=160792
            <rdar://problem/27361778>

            Reviewed by Benjamin Poulain.

            The OverrideHasInstance node has a branch test that is emitted conditionally.
            It also has a bug where it allocated a register after this branch, which is not
            allowed and would fail an assertion introduced in https://trac.webkit.org/r145931.
            From the ChangeLog for r145931:

            "This [assertion that register allocations are not branched around] protects
            against the case where an allocation could have spilled register contents to free
            up a register and that spill only occurs on one path of many through the code.
            A subsequent fill of the spilled register may load garbage."

            Because the branch isn't always emitted, this bug has gone unnoticed until now.
            This patch fixes this issue by pre-allocating the registers before emitting the
            branch in OverrideHasInstance.

            Note: this issue is only present in DFGSpeculativeJIT64.cpp.  The 32-bit version
            is doing it right.

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

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r204485. rdar://problem/27991572

    2016-08-15  Mark Lam  <mark.lam@apple.com>

            Make JSValue::strictEqual() handle failures to resolve JSRopeStrings.
            https://bugs.webkit.org/show_bug.cgi?id=160832
            <rdar://problem/27577556>

            Reviewed by Geoffrey Garen.

            Currently, JSValue::strictEqualSlowCaseInline() (and peers) will blindly try to
            access the StringImpl of a JSRopeString that fails to resolve its rope.  As a
            result, we'll crash with null pointer dereferences.

            We can fix this by introducing a JSString::equal() method that will do the
            equality comparison, but is aware of the potential failures to resolve ropes.
            JSValue::strictEqualSlowCaseInline() (and peers) will now call JSString::equal()
            instead of accessing the underlying StringImpl directly.

            Also added some exception checks.

            * JavaScriptCore.xcodeproj/project.pbxproj:
            * jit/JITOperations.cpp:
            * runtime/ArrayPrototype.cpp:
            (JSC::arrayProtoFuncIndexOf):
            (JSC::arrayProtoFuncLastIndexOf):
            * runtime/JSCJSValueInlines.h:
            (JSC::JSValue::equalSlowCaseInline):
            (JSC::JSValue::strictEqualSlowCaseInline):
            * runtime/JSString.cpp:
            (JSC::JSString::equalSlowCase):
            * runtime/JSString.h:
            * runtime/JSStringInlines.h: Added.
            (JSC::JSString::equal):

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r203381. rdar://problem/27860536

    2016-07-18  Anders Carlsson  <andersca@apple.com>

            WebKit nightly fails to build on macOS Sierra
            https://bugs.webkit.org/show_bug.cgi?id=159902
            rdar://problem/27365672

            Reviewed by Tim Horton.

            * icu/unicode/ucurr.h: Added.
            Add ucurr.h from ICU.

2016-09-09  Babak Shafiei  <bshafiei@apple.com>

        Merge r205192. rdar://problem/28097740

    2016-08-30  Alex Christensen  <achristensen@webkit.org>

            Fix WebInspectorUI in internal Windows build
            https://bugs.webkit.org/show_bug.cgi?id=161221
            rdar://problem/28019023

            Reviewed by Brent Fulgham and Joseph Pecoraro.

            * JavaScriptCore.vcxproj/JavaScriptCore.proj:

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204570. rdar://problem/27991567

    2016-08-17  Mark Lam  <mark.lam@apple.com>

            Remove an invalid assertion in the DFG backend's GetById emitter.
            https://bugs.webkit.org/show_bug.cgi?id=160925
            <rdar://problem/27248961>

            Reviewed by Filip Pizlo.

            The DFG backend's GetById assertion that the node's prediction not be SpecNone
            is just plain wrong.  It assumes that we can never have a GetById node without a
            type prediction, but this is not true.  The following test case proves otherwise:

                function foo() {
                    "use strict";
                    return --arguments["callee"];
                }

            Will remove the assertion.  Nothing else needs to change as the DFG is working
            correctly without the assertion.

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

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204388. rdar://problem/27991576

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

            The jsc shell's Element host constructor should throw if it fails to construct an object.
            https://bugs.webkit.org/show_bug.cgi?id=160773
            <rdar://problem/27328608>

            Reviewed by Saam Barati.

            The Element object is a test object provided in the jsc shell for testing use only.
            JavaScriptCore expects host constructors to either throw an error or return a
            constructed object.  Element has a host constructor that did not obey this contract.
            As a result, the following statement will fail a RELEASE_ASSERT:

                new (Element.bind())

            This is now fixed.

            * jsc.cpp:
            (functionCreateElement):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204362. rdar://problem/27991421

    2016-08-10  Michael Saboff  <msaboff@apple.com>

            Baseline GetByVal and PutByVal for cache ID stubs need to handle exceptions
            https://bugs.webkit.org/show_bug.cgi?id=160749

            Reviewed by Filip Pizlo.

            We were emitting "callOperation()" calls in emitGetByValWithCachedId() and
            emitPutByValWithCachedId() without linking the exception checks created by the
            code emitted.  This manifested itself in various ways depending on the processor.
            This is due to what the destination is for an unlinked branch.  On X86, an unlinked
            branch goes tot he next instructions.  On ARM64, we end up with an infinite loop
            as we branch to the same instruction.  On ARM we branch to 0 as the branch is to
            an absolute address of 0.

            Now we save the exception handler address for the original generated function and
            link the exception cases for these by-val stubs to this handler.

            * bytecode/ByValInfo.h:
            (JSC::ByValInfo::ByValInfo): Added the address of the exception handler we should
            link to.

            * jit/JIT.cpp:
            (JSC::JIT::link): Compute the linked exception handler address and pass it to
            the ByValInfo constructor.
            (JSC::JIT::privateCompileExceptionHandlers): Make sure that we generate the
            exception handler if we have any by-val handlers.

            * jit/JIT.h:
            Added a label for the exception handler.  We'll link this later for the
            by value handlers.

            * jit/JITPropertyAccess.cpp:
            (JSC::JIT::privateCompileGetByValWithCachedId):
            (JSC::JIT::privateCompilePutByValWithCachedId):
            Link exception branches to the exception handler for the main function.

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r204360. rdar://problem/27991577

    2016-08-10  Mark Lam  <mark.lam@apple.com>

            DFG's flushForTerminal() needs to add PhantomLocals for bytecode live locals.
            https://bugs.webkit.org/show_bug.cgi?id=160755
            <rdar://problem/27488507>

            Reviewed by Filip Pizlo.

            If the DFG sees that an inlined function will result in an OSR exit every time,
            it will treat all downstream blocks as dead.  However, it still needs to keep
            locals that are alive in the bytecode alive for the compiled function so that
            those locals are properly written to the stack by the OSR exit ramp.

            The existing code neglected to do this.  This patch remedies this issue.

            * dfg/DFGByteCodeParser.cpp:
            (JSC::DFG::ByteCodeParser::flushDirect):
            (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal):
            (JSC::DFG::ByteCodeParser::phantomLocalDirect):
            (JSC::DFG::ByteCodeParser::flushForTerminal):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203952. rdar://problem/27991571

    2016-07-30  Mark Lam  <mark.lam@apple.com>

            Assertion failure while setting the length of an ArrayClass array.
            https://bugs.webkit.org/show_bug.cgi?id=160381
            <rdar://problem/27328703>

            Reviewed by Filip Pizlo.

            When setting large length values, we're currently treating ArrayClass as a
            ContiguousIndexingType array.  This results in an assertion failure.  This is
            now fixed.

            There are currently only 2 places where we create arrays with indexing type
            ArrayClass: ArrayPrototype and RuntimeArray.  The fix in JSArray:;setLength()
            takes care of ArrayPrototype.

            RuntimeArray already checks for the setting of its length property, and will
            throw a RangeError.  Hence, there's no change is needed for the RuntimeArray.
            Instead, I added some test cases ensure that the check and throw behavior does
            not change without notice.

            * runtime/JSArray.cpp:
            (JSC::JSArray::setLength):
            * tests/stress/array-setLength-on-ArrayClass-with-large-length.js: Added.
            (toString):
            (assertEqual):
            * tests/stress/array-setLength-on-ArrayClass-with-small-length.js: Added.
            (toString):
            (assertEqual):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203853. rdar://problem/27991580

    2016-07-28  Mark Lam  <mark.lam@apple.com>

            ASSERTION FAILED in errorProtoFuncToString() when Error name is a single char string.
            https://bugs.webkit.org/show_bug.cgi?id=160324
            <rdar://problem/27389572>

            Reviewed by Keith Miller.

            The issue is that errorProtoFuncToString() was using jsNontrivialString() to
            generate the error string even when the name string can be a single character
            string.  This is incorrect.  We should be using jsString() instead.

            * runtime/ErrorPrototype.cpp:
            (JSC::errorProtoFuncToString):
            * tests/stress/errors-with-simple-names-or-messages-should-not-crash-toString.js: Added.

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203834. rdar://problem/27991582

    2016-07-28  Mark Lam  <mark.lam@apple.com>

            StringView should have an explicit m_is8Bit field.
            https://bugs.webkit.org/show_bug.cgi?id=160282
            <rdar://problem/27327943>

            Reviewed by Benjamin Poulain.

            * tests/stress/string-joining-long-strings-should-not-crash.js: Added.
            (catch):

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203802. rdar://problem/27991569

    2016-07-27  Benjamin Poulain  <bpoulain@apple.com>

            [JSC] Fix a bunch of use-after-free of DFG::Node
            https://bugs.webkit.org/show_bug.cgi?id=160228

            Reviewed by Mark Lam.

            FTL had a few places where we use a node after it has been
            deleted. The dangling pointers come from the SSA liveness information
            kept on the basic blocks.

            This patch fixes the issues I could find and adds liveness invalidation
            to help finding dependencies like these.

            * dfg/DFGBasicBlock.h:
            (JSC::DFG::BasicBlock::SSAData::invalidate):

            * dfg/DFGConstantFoldingPhase.cpp:
            (JSC::DFG::ConstantFoldingPhase::run):
            Constant folding phase was deleting nodes in the loop over basic blocks.
            The problem is the deleted nodes can be referenced by other blocks.
            When the abstract interpreter was manipulating the abstract values of those
            it was doing so on the dead nodes.

            * dfg/DFGConstantHoistingPhase.cpp:
            Just invalidation. Nothing wrong here since the useless nodes were
            kept live while iterating the blocks.

            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::killBlockAndItsContents):
            (JSC::DFG::Graph::killUnreachableBlocks):
            (JSC::DFG::Graph::invalidateNodeLiveness):

            * dfg/DFGGraph.h:
            * dfg/DFGPlan.cpp:
            (JSC::DFG::Plan::compileInThreadImpl):
            We had a lot of use-after-free in LCIM because we were using the stale
            live nodes deleted by previous phases.

2016-08-30  Babak Shafiei  <bshafiei@apple.com>

        Merge r203798. rdar://problem/27991578

    2016-07-27  Keith Miller  <keith_miller@apple.com>

            concatAppendOne should allocate using the indexing type of the array if it cannot merge
            https://bugs.webkit.org/show_bug.cgi?id=160261
            <rdar://problem/27530122>

            Reviewed by Mark Lam.

            Before, if we could not merge the indexing types for copying, we would allocate the
            the array as ArrayWithUndecided. Instead, we should allocate an array with the original
            array's indexing type.

            * runtime/ArrayPrototype.cpp:
            (JSC::concatAppendOne):
            * tests/stress/concat-append-one-with-sparse-array.js: Added.

2016-08-17  Babak Shafiei  <bshafiei@apple.com>

        Merge r204572. rdar://problem/27889416

    2016-08-17  Geoffrey Garen  <ggaren@apple.com>

            Fixed a potential bug in MarkedArgumentBuffer.
            https://bugs.webkit.org/show_bug.cgi?id=160948
            <rdar://problem/27889416>

            Reviewed by Oliver Hunt.

            I haven't been able to produce an observable test case after some trying.

            * runtime/ArgList.cpp:
            (JSC::MarkedArgumentBuffer::addMarkSet): New helper function -- I broke
            this out from existing code for clarity, but the behavior is the same.

            (JSC::MarkedArgumentBuffer::expandCapacity): Ditto.

            (JSC::MarkedArgumentBuffer::slowAppend): Always addMarkSet() on the slow
            path. This is faster than the old linear scan, and I think it might
            avoid cases the old scan could miss.

            * runtime/ArgList.h:
            (JSC::MarkedArgumentBuffer::append): Account for the case where someone
            has called clear() or removeLast().

            (JSC::MarkedArgumentBuffer::mallocBase): No behavior change -- but it's
            clearer to test the buffers directly instead of inferring what they
            might be based on capacity.

2016-08-11  Keith Miller  <keith_miller@apple.com>

        Merge r203972.

    2016-08-01  Keith Miller  <keith_miller@apple.com>

            We should not keep the JavaScript tests inside the Source/JavaScriptCore/ directory.
            https://bugs.webkit.org/show_bug.cgi?id=160372

            Rubber stamped by Geoffrey Garen.

            This patch moves all the JavaScript tests from Source/JavaScriptCore/tests to
            a new top level directory, JSTests. Having the tests in the Source directory
            was both confusing an inconvenient for people that just want to checkout the
            source code of WebKit. Since there is no other obvious place to put all the
            JavaScript tests a new top level directory seemed the most sensible.

            * tests/: Deleted.

2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        Merge r204010. rdar://problem/27534844

    2016-08-01  Filip Pizlo  <fpizlo@apple.com>

            REGRESSION (r203990): JSC Debug test stress/arity-check-ftl-throw.js failing
            https://bugs.webkit.org/show_bug.cgi?id=160438

            Reviewed by Mark Lam.

            In r203990 I fixed a bug where CommonSlowPaths.h/arityCheckFor() was basically failing at
            catching stack overflow due to large parameter count. It would only catch regular old stack
            overflow, like if the frame pointer was already past the limit.

            This had a secondary problem: unfortunately all of our tests for what happens when you overflow
            the stack due to large parameter count were not going down that path at all, so we haven't had
            test coverage for this in ages.  There were bugs in all tiers of the engine when handling this
            case.

            We need to be able to roll back the topCallFrame on paths that are meant to throw an exception
            from the caller. Otherwise, we'd crash in StackVisitor because it would see a busted stack
            frame. Rolling back like this "just works" except when the caller is the VM entry frame. I had
            some choices here. I could have forced anyone who is rolling back to always skip VM entry
            frames. They can't do it in a way that changes the value of VM::topVMEntryFrame, which is what
            a stack frame roll back normally does, since exception unwinding needs to see the current value
            of topVMEntryFrame. So, we have a choice to either try to magically avoid all of the paths that
            look at topCallFrame, or give topCallFrame a state that unambiguously signals that we are
            sitting right on top of a VM entry frame without having succeeded at making a JS call. The only
            place that really needs to know is StackVisitor, which wants to start scanning at topCallFrame.
            To signal this, I could have either made topCallFrame point to the real top JS call frame
            without also rolling back topVMEntryFrame, or I could make topCallFrame == topVMEntryFrame. The
            latter felt somehow cleaner. I filed a bug (https://bugs.webkit.org/show_bug.cgi?id=160441) for
            converting topCallFrame to a void*, which would give us a chance to harden the rest of the
            engine against this case.

            * interpreter/StackVisitor.cpp:
            (JSC::StackVisitor::StackVisitor):
            We may do ShadowChicken processing, which invokes StackVisitor, when we have topCallFrame
            pointing at topVMEntryFrame. This teaches StackVisitor how to handle this case. I believe that
            StackVisitor is the only place that needs to be taught about this at this time, because it's
            one of the few things that access topCallFrame along this special path.

            * jit/JITOperations.cpp: Roll back the top call frame.
            * runtime/CommonSlowPaths.cpp:
            (JSC::SLOW_PATH_DECL): Roll back the top call frame.

2016-08-01  Babak Shafiei  <bshafiei@apple.com>

        Merge r203990. rdar://problem/27534844

    2016-08-01  Filip Pizlo  <fpizlo@apple.com>

            Rationalize varargs stack overflow checks
            https://bugs.webkit.org/show_bug.cgi?id=160425

            Reviewed by Michael Saboff.

            * ftl/FTLLink.cpp:
            (JSC::FTL::link): AboveOrEqual 0 is a tautology. The code meant GreaterThanOrEqual, since the error code is -1.
            * runtime/CommonSlowPaths.h:
            (JSC::CommonSlowPaths::arityCheckFor): Use roundUpToMultipleOf(), which is almost certainly what we meant when we said %.

2016-07-28  Babak Shafiei  <bshafiei@apple.com>

        Merge r203851. rdar://problem/27299339

    2016-07-28  Michael Saboff  <msaboff@apple.com>

            ARM64: Fused left shift with a right shift can create NaNs from integers
            https://bugs.webkit.org/show_bug.cgi?id=160329

            Reviewed by Geoffrey Garen.

            When we fuse a left shift and a right shift of integers where the shift amounts
            are the same and the size of the quantity being shifted is 8 bits, we rightly
            generate a sign extend byte instruction.  On ARM64, we were sign extending
            to a 64 bit quantity, when we really wanted to sign extend to a 32 bit quantity.

            Checking the ARM64 marco assembler and we were extending to 64 bits for all
            four combinations of zero / sign and 8 / 16 bits.

            * assembler/MacroAssemblerARM64.h:
            (JSC::MacroAssemblerARM64::zeroExtend16To32):
            (JSC::MacroAssemblerARM64::signExtend16To32):
            (JSC::MacroAssemblerARM64::zeroExtend8To32):
            (JSC::MacroAssemblerARM64::signExtend8To32):
            * tests/stress/regress-160329.js: New test added.
            (narrow):

2016-07-28  Babak Shafiei  <bshafiei@apple.com>

        Merge r203793. rdar://problem/27572612

    2016-07-27  Saam Barati  <sbarati@apple.com>

            We don't optimize for-in properly in baseline JIT (maybe other JITs too) with an object with symbols
            https://bugs.webkit.org/show_bug.cgi?id=160211
            <rdar://problem/27572612>

            Reviewed by Geoffrey Garen.

            The fast for-in iteration mode assumes all inline/out-of-line properties
            can be iterated in linear order. This is not true if we have Symbols
            because Symbols should not be iterated by for-in.

            * runtime/Structure.cpp:
            (JSC::Structure::add):
            * tests/stress/symbol-should-not-break-for-in.js: Added.
            (assert):
            (foo):

2016-07-28  Babak Shafiei  <bshafiei@apple.com>

        Merge r203790. rdar://problem/27328525

    2016-07-27  Mark Lam  <mark.lam@apple.com>

            The second argument for Function.prototype.apply should be array-like or null/undefined.
            https://bugs.webkit.org/show_bug.cgi?id=160212
            <rdar://problem/27328525>

            Reviewed by Filip Pizlo.

            The spec for Function.prototype.apply says its second argument can only be null,
            undefined, or must be array-like.  See
            https://tc39.github.io/ecma262/#sec-function.prototype.apply and
            https://tc39.github.io/ecma262/#sec-createlistfromarraylike.

            Our previous implementation was not handling this correctly for SymbolType.
            This is now fixed.

            * interpreter/Interpreter.cpp:
            (JSC::sizeOfVarargs):
            * tests/stress/apply-second-argument-must-be-array-like.js: Added.

2016-07-22  Babak Shafiei  <bshafiei@apple.com>

        Merge r203488. rdar://problem/27439330

    2016-07-20  Filip Pizlo  <fpizlo@apple.com>

            FTL snippet generators should be able to request a different register for output and input
            https://bugs.webkit.org/show_bug.cgi?id=160010
            rdar://problem/27439330

            Reviewed by Saam Barati.

            The BitOr and BitXor snippet generators have problems if the register for the right input is
            the same as the register for the result. We could fix those generators, but I'm not convinced
            that the other snippet generators don't have this bug. So, the approach that this patch takes
            is to teach the FTL to request that B3 to use a different register for the result than for
            any input to the snippet patchpoint.

            Air already has the ability to let any instruction do an EarlyDef, which means exactly this.
            But B3 did not expose this via ValueRep. This patch exposes this in ValueRep as
            SomeEarlyRegister. That's most of the change.

            This adds a testb3 test for SomeEarlyRegister and a regression test for this particular
            problem. The regression test failed on trunk JSC before this.

            * b3/B3LowerToAir.cpp:
            (JSC::B3::Air::LowerToAir::lower):
            * b3/B3PatchpointSpecial.cpp:
            (JSC::B3::PatchpointSpecial::forEachArg):
            (JSC::B3::PatchpointSpecial::admitsStack):
            * b3/B3StackmapSpecial.cpp:
            (JSC::B3::StackmapSpecial::forEachArgImpl):
            (JSC::B3::StackmapSpecial::isArgValidForRep):
            * b3/B3Validate.cpp:
            * b3/B3ValueRep.cpp:
            (JSC::B3::ValueRep::addUsedRegistersTo):
            (JSC::B3::ValueRep::dump):
            (WTF::printInternal):
            * b3/B3ValueRep.h:
            (JSC::B3::ValueRep::ValueRep):
            (JSC::B3::ValueRep::reg):
            (JSC::B3::ValueRep::isAny):
            (JSC::B3::ValueRep::isReg):
            (JSC::B3::ValueRep::isSomeRegister): Deleted.
            * b3/testb3.cpp:
            * ftl/FTLLowerDFGToB3.cpp:
            (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
            (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
            (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
            * tests/stress/ftl-bit-xor-right-result-interference.js: Added.

2016-07-19  Babak Shafiei  <bshafiei@apple.com>

        Merge r203419.

    2016-07-19  Anders Carlsson  <andersca@apple.com>

            WebCore-7602.1.42 fails to build: error: private field 'm_vm' is not used
            https://bugs.webkit.org/show_bug.cgi?id=159944
            rdar://problem/27420308

            Reviewed by Dan Bernstein.

            Wrap the m_vm declaration and initialization in conditional guards.

            * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
            (generate_members):
            * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
            (BuiltinsInternalsWrapperImplementationGenerator.generate_constructor):
            Add guards.

            * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
            * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
            * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
            * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
            * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
            Update expected results.

2016-07-18  Babak Shafiei  <bshafiei@apple.com>

        Merge r203351.

    2016-07-18  Keith Miller  <keith_miller@apple.com>

            Fix bad assertions in genericTypedArrayViewPrivateFuncSubarrayCreate
            https://bugs.webkit.org/show_bug.cgi?id=159882
            <rdar://problem/27327111>

            Reviewed by Mark Lam.

            According the spec toInteger can return values we don't consider ints.
            Such as, -0 and +/-Infinity. This broke some assertions in
            genericTypedArrayViewPrivateFuncSubarrayCreate.

            * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
            (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
            * tests/stress/typedarray-subarray.js:

2016-07-18  Babak Shafiei  <bshafiei@apple.com>

        Merge patch for rdar://problem/27360961.

    2016-06-23  Dean Jackson  <dino@apple.com>

            Disable some features on safari-602-branch.
            <rdar://problem/27360961>

            * Configurations/FeatureDefines.xcconfig:

2016-07-18  Babak Shafiei  <bshafiei@apple.com>

        Merge r203353.

    2016-07-18  Youenn Fablet  <youenn@apple.com>

            REGRESSION(r202975): --minimal build is broken
            https://bugs.webkit.org/show_bug.cgi?id=159765

            Reviewed by Chris Dumez.

            Covered partially by builtin generated test code.

            Updating generator to add a global compilation guard around the code that generates all global internal properties.
            Split the generate_methods function in two, one dedicated to the visit method and the second one dedicated to
            the initialize method.

            * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
            (BuiltinsInternalsWrapperImplementationGenerator.generate_section_for_object): Use splitted generation functions.
            (BuiltinsInternalsWrapperImplementationGenerator.generate_visit_method): Response to generate the visit method.
            (BuiltinsInternalsWrapperImplementationGenerator._generate_initialize_static_globals): Responsible to generate
            the code to initialize the internal globals. This code is put in a global compilation guard in case all
            internals are compiled out by specific builds.
            (BuiltinsInternalsWrapperImplementationGenerator):
            (BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method): Responsible to generate the
            initialize method.
            (BuiltinsInternalsWrapperImplementationGenerator.generate_methods): Deleted.
            * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Copyright change.
            * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
            * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
            * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
            * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Reflects partially the built-in
            generator change.

2016-07-16  Filip Pizlo  <fpizlo@apple.com>

        DFG CSE is broken for MultiGetByOffset
        https://bugs.webkit.org/show_bug.cgi?id=159858

        Reviewed by Saam Barati.
        
        This disabled CSE for MultiGetByOffset. I opened bug 159859 for the long-term fix, which
        would teach CSE (and other passes also) how to decay a removed MultiGetByOffset to a
        CheckStructure. Since we currently just decay MultiGetByOffset to Check, we forget the
        structure checks. So, if we CSE a MultiGetByOffset that checks for one set of structures with
        a heap access on the same property and base that checks for different structures, then we
        will forget some structure checks that we had previously. It's unsound to forget checks in
        DFG IR.
        
        This bug mostly manifested as a high-volume crash at Unreachable in FTL, because we'd prove
        that the code after the MultiGetByOffset was unreachable due to the structure checks and then
        CSE would remove everything but the Unreachable.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Remove the def() for MultiGetByOffset to disable CSE for this node for now.
        * tests/stress/cse-multi-get-by-offset-remove-checks.js: Added. This used to fail with FTL enabled.
        (Cons1):
        (Cons2):
        (Cons3):
        (foo):
        (bar):

2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Enable test262 module tests
        https://bugs.webkit.org/show_bug.cgi?id=159854

        Reviewed by Saam Barati.

        This patch enables test262 module tests. Before this patch, the modules tests in test262 do not work fine.
        This patch fixes the following 2 things.

        1. Test harness

            Before this patch, there is only one global switch "-m" in jsc shell. So we cannot load the test262 test harness before evaluating the module tests.
            This patch adds a new option, "--module-file=". It is similar to "--strict-file=". When we specify the file with "--module-file=", it is evaluated as
            a module, while the other files are evaluated by following the JSC's default manner. This option allows us to load the test harness files into the
            global context before loading the module tests.

        2. Module's asynchronous errors

            Before this patch, the errors caused in the module evaluation are not handled as the same to the usual sync files. In synchronous execution, we have
            "--exception=" option to pass the expected exception to the JSC shell. But this option does not work in the module evaluation.
            This patch correctly handles this expected exception in the module evaluation promise's fulfill and reject handlers.

        And we fix the YAML file. Now the recorded :fail and :normal are the correct test results for the module tests.

        * jsc.cpp:
        (Script::Script):
        (checkUncaughtException):
        (runWithScripts):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (dumpException): Deleted.
        * tests/test262.yaml:

2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Mask TrustedImm32 to 8bit in MacroAssembler for 8bit operations
        https://bugs.webkit.org/show_bug.cgi?id=159334

        Reviewed by Filip Pizlo.

        Previously, in 8bit operations (like add8, compare8, test8, branch8, branchTest8 etc.),
        we require that the given TrustedImm32 is in range of 8bit. While achieving this in
        the manual MacroAssembler calling is easy, in Air, we don't guarantee that the higher bit
        of the 8bit argument is cleared. So the current assertions are invalid.

        This patch relaxes the above restriction. By removing this assertion,
        8bit operations can take arbitrary 32bit imms. And only lower 8bit are effective when
        emitting the code in these methods.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::branchTest8):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::store8):
        (JSC::MacroAssemblerARM::branch8):
        (JSC::MacroAssemblerARM::branchTest8):
        (JSC::MacroAssemblerARM::compare8):
        (JSC::MacroAssemblerARM::test8):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::store8):
        (JSC::MacroAssemblerARM64::branch8):
        (JSC::MacroAssemblerARM64::branchTest8):
        (JSC::MacroAssemblerARM64::compare8):
        (JSC::MacroAssemblerARM64::test8):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (JSC::MacroAssemblerARMv7::branch8):
        (JSC::MacroAssemblerARMv7::branchTest8):
        (JSC::MacroAssemblerARMv7::compare8):
        (JSC::MacroAssemblerARMv7::test8):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::store8):
        (JSC::MacroAssemblerMIPS::branch8):
        (JSC::MacroAssemblerMIPS::compare8):
        (JSC::MacroAssemblerMIPS::branchTest8):
        (JSC::MacroAssemblerMIPS::test8):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::store8):
        (JSC::MacroAssemblerSH4::branchTest8):
        (JSC::MacroAssemblerSH4::branch8):
        (JSC::MacroAssemblerSH4::compare8):
        (JSC::MacroAssemblerSH4::test8):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::store8):
        (JSC::MacroAssemblerX86::branch8):
        (JSC::MacroAssemblerX86::branchTest8):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add8):
        (JSC::MacroAssemblerX86Common::store8):
        (JSC::MacroAssemblerX86Common::branch8):
        (JSC::MacroAssemblerX86Common::branchTest8):
        (JSC::MacroAssemblerX86Common::compare8):
        (JSC::MacroAssemblerX86Common::test8):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::store8):
        (JSC::MacroAssemblerX86_64::branch8):
        (JSC::MacroAssemblerX86_64::branchTest8):

2016-07-16  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r203318.

        Regressed most JS Benchmarks on MacBook Air by ~2% (7% on
        SunSpider)

        Reverted changeset:

        "[JSC] Change some parameters based on a random search"
        https://bugs.webkit.org/show_bug.cgi?id=158514
        http://trac.webkit.org/changeset/203318

2016-07-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Convert the remaining createOutOfMemoryError()+throwException() into throwOutOfMemoryError()
        https://bugs.webkit.org/show_bug.cgi?id=159665

        Reviewed by Saam Barati.

        * API/JSTypedArray.cpp:
        (createTypedArray):
        * runtime/Error.cpp:
        (JSC::createOutOfMemoryError):
        * runtime/Error.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwOutOfMemoryError):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::create):
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):

2016-07-15  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Change some parameters based on a random search
        https://bugs.webkit.org/show_bug.cgi?id=158514

        Reviewed by Saam Barati.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        * runtime/Options.h:

2016-07-15  Mark Lam  <mark.lam@apple.com>

        Assertion failures and crashes with missing TDZ checks for catch-node bindings.
        https://bugs.webkit.org/show_bug.cgi?id=158797

        Reviewed by Saam Barati.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPushCatchScope):
        (JSC::BytecodeGenerator::emitPopCatchScope):
        * tests/stress/catch-clause-should-be-under-tdz1.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz2.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz3.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz4.js: Added.
        * tests/stress/catch-clause-should-be-under-tdz5.js: Added.

2016-07-15  Geoffrey Garen  <ggaren@apple.com>

        Added a makeRef<T> helper
        https://bugs.webkit.org/show_bug.cgi?id=159835

        Reviewed by Andreas Kling.

        Anders told me to!

        * inspector/InjectedScriptHost.cpp:
        (Inspector::InjectedScriptHost::wrapper):

2016-07-15  Mark Lam  <mark.lam@apple.com>

        FunctionOverride's parseClause() needs to keep the CString instance in scope while its data is being used.
        https://bugs.webkit.org/show_bug.cgi?id=159828

        Reviewed by Saam Barati.

        Otherwise, we'll have a use after free.  This issue was caught when running an
        ASan debug build of testapi.

        * tools/FunctionOverrides.cpp:
        (JSC::parseClause):

2016-07-15  Keith Miller  <keith_miller@apple.com>

        %TypedArray%.prototype.indexOf is coercing non-integers or non-floats to numbers wrongly
        https://bugs.webkit.org/show_bug.cgi?id=159400

        Reviewed by Geoffrey Garen.

        This patch fixes coercion of non-numbers in indexOf/lastIndexOf.
        Additionally, this patch fixes an issue with includes where it
        would not check that the buffer remained non-neutered after
        calling the toInteger() function. Lastly, some extra release
        asserts have been added in some places to inform us of any issues
        in the future.

        Additionally, this patch changes bool toNativeFromDouble to
        Optional<Type> toNativeFromDoubleWithoutCoercion. This makes it a
        little clearer what the function does and also removes the return
        argument. The only behavior change is that the function no longer
        coerces non-numbers into numbers. That behavior was unused (maybe
        unintended), however.

        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValueWithoutCoercion):
        (JSC::JSGenericTypedArrayView::sort):
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        * runtime/ToNativeFromValue.h:
        (JSC::toNativeFromValueWithoutCoercion):
        (JSC::toNativeFromValue): Deleted.
        * runtime/TypedArrayAdaptors.h:
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32WithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::FloatTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32WithoutCoercion):
        (JSC::Uint8ClampedAdaptor::toNativeFromDoubleWithoutCoercion):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32): Deleted.
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32): Deleted.
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDouble): Deleted.
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32): Deleted.
        (JSC::FloatTypedArrayAdaptor::toNativeFromDouble): Deleted.
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32): Deleted.
        (JSC::Uint8ClampedAdaptor::toNativeFromDouble): Deleted.
        * tests/stress/resources/typedarray-test-helper-functions.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (callWithArgs):
        * tests/stress/typedarray-includes.js: Added.
        * tests/stress/typedarray-indexOf.js:
        * tests/stress/typedarray-lastIndexOf.js:

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        Add new functions to ARMAssembler after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159713

        Reviewed by Saam Barati.

        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::fillNops):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::patchableBranch32):
        (JSC::MacroAssemblerARM::internalCompare32):

2016-07-15  Mark Lam  <mark.lam@apple.com>

        Stack overflow error for deeply nested classes.
        https://bugs.webkit.org/show_bug.cgi?id=157086

        Reviewed by Geoffrey Garen.

        Changed the StructureStubClearingWatchpoint destructor to iteratively destruct
        its chain of next StructureStubClearingWatchpoints instead of recursively doing
        so.

        The added deep-StructureStubClearingWatchpoint-destructor-recursion.js test
        produces a crash before the fix is applied, but takes about 14 minutes to run.
        Hence, it is skipped.

        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint):
        * tests/stress/deep-StructureStubClearingWatchpoint-destructor-recursion.js: Added.

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        Fix expectations in test262.yaml
        https://bugs.webkit.org/show_bug.cgi?id=159810

        Reviewed by Keith Miller.

        * tests/test262.yaml:

2016-07-15  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Disable Inline Caching on ARMv7 traditional until proper fix
        https://bugs.webkit.org/show_bug.cgi?id=159759

        Reviewed by Saam Barati.

        * jit/Repatch.cpp:
        (JSC::forceICFailure):

2016-07-14  Keith Miller  <keith_miller@apple.com>

        Add Test262 test files and yaml

        Rubber Stamped by Benjamin Poulain.

        This patch adds all the test262 test files and the yaml that drives
        run-jsc-stress-tests.

        * tests/test262.yaml: Added. Yaml file to drive the test262 test suite with our driver.
        * tests/test262/LICENSE: Added. License for the test262 test suite.
        * tests/test262/harness/: Added. Harness directory for the test262 tests.
        * tests/test262/test/: Added. Directory with all the actual test files.

2016-07-14  Joseph Pecoraro  <pecoraro@apple.com>

        Return the correct value from Heap::externalMemorySize
        https://bugs.webkit.org/show_bug.cgi?id=159797
        <rdar://problem/27362446>

        Reviewed by Timothy Hatcher.

        * heap/Heap.h:
        (JSC::Heap::externalMemorySize):
        We should have been returning m_externalMemorySize which is a subset
        of m_extraMemorySize. In practice the difference can be small. A major
        difference in "extra memory size" may be from deprecated memory size
        and array buffer sizes.

2016-07-14  Saam Barati  <sbarati@apple.com>

        It should be a syntax error to have a 'use strict' directive inside a function that has a non-simple parameter list
        https://bugs.webkit.org/show_bug.cgi?id=159790
        <rdar://problem/27171636>

        Reviewed by Geoffrey Garen.

        Is is a syntax error for a function's parameter list to be non-simple
        and for the function to also contain a 'use strict' directive.

        See section 14.2.1 of the spec:
        https://tc39.github.io/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseFormalParameters):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::strictMode):
        (JSC::Scope::isValidStrictMode):
        (JSC::Scope::shadowsArguments):
        (JSC::Scope::setHasNonSimpleParameterList):
        (JSC::Scope::hasNonSimpleParameterList):
        (JSC::Scope::copyCapturedVariablesToVector):

2016-07-14  Geoffrey Garen  <ggaren@apple.com>

        ASSERTION FAILED: : this != replacement()
        https://bugs.webkit.org/show_bug.cgi?id=159779

        Reviewed by Michael Saboff.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison): If we jettison during GC, and our owner
        is dead, we choose not to replace ourselves. (See
        https://bugs.webkit.org/show_bug.cgi?id=159588.) So, it's possible to
        invalidate and still be our owner's CodeBlock. Relax our ASSERT to allow
        for this.

2016-07-14  Mark Lam  <mark.lam@apple.com>

        JSONObject Walker::walk must save array length before processing array elements.
        https://bugs.webkit.org/show_bug.cgi?id=153485

        Reviewed by Darin Adler and Michael Saboff.

        According to https://tc39.github.io/ecma262/#sec-internalizejsonproperty,
        JSON.parse() should cache the length of an array and use the cached length when
        iterating array elements (see section 24.3.1.1 2.b.iii).

        * runtime/JSONObject.cpp:
        (JSC::Walker::walk):
        * tests/stress/JSON-parse-should-cache-array-lengths.js: Added.
        (toString):
        (shouldBe):
        (test):
        (test2):

2016-07-14  Julien Brianceau  <jbriance@cisco.com>

        [mips] Handle properly unaligned halfword load
        https://bugs.webkit.org/show_bug.cgi?id=153226

        Reviewed by Michael Catanzaro.

        Waiting for the kernel to silently fix-up unaligned accesses is
        not efficient, so let's provide an implementation of load16Unaligned
        in mips macro assembler.

        Performance improvement seen with SunSpider's regexp-dna test.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::load16Unaligned):
        (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords):

2016-07-14  Youenn Fablet  <youenn@apple.com>

        DOM value iterable interfaces should use Array prototype methods
        https://bugs.webkit.org/show_bug.cgi?id=159296

        Reviewed by Chris Dumez and Mark Lam.

        * JavaScriptCore.xcodeproj/project.pbxproj: Marking some header files as private so that they can be included in
        WebCore.
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation): copying iterable methods (entries, forEach, keys and values) to private slots.

2016-07-13  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the magic numbers for ARM traditional in InlineAccess.h
        https://bugs.webkit.org/show_bug.cgi?id=159708

        Reviewed by Saam Barati.

        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):

2016-07-13  Michael Saboff  <msaboff@apple.com>

        YARR uses mixture of int and unsigned values to index into subject string
        https://bugs.webkit.org/show_bug.cgi?id=159744

        Reviewed by Benjamin Poulain.

        In most cases, we refer to characters in subject strings using a negative index from the number of
        "checked" characters in a subject string.  The required length is compared against the actual length
        and then we use that required length as the checked amount.  For example, when matching the string of
        4 digits in the RegExp /abc \d{4}/, we know that need 8 characters in the subject string.  We refer
        to the digits part of the expression from an already checked index of 8 and use negative offsets of
        -4 through -1.  In many cases we used a signed int for the negative offsets.  There are other cases
        where we used unsigned values as the amount of negative offset to use when accessing subject characters.

        Changed all occurrances of character offsets to unsigned or Checked Arithmetic unsigned values.  Note
        that the pre-existing Checked class is used in other places to check for under/overflow with arithmetic
        operations.  Those unsigned offsets are always the number of characters before (negative) from the
        current checked character offset.  Also added some asserts for cases where arithmetic is not protected
        by other checks or with Checked<> wrapped values.

        In the case of the JIT, subject characters are accessed using base with scaled index and offset
        addressing.  The MacroAssembler provides this addressing using the BaseIndex struct.  The offset for
        this struct is a 32 bit signed quantity.  Since we only care about negative offsets, we really only
        have 31 bits.  Changed the generation of a BaseOffset address to handle the case when the offset and
        scaled combination will exceed the 31 bits of negative offset.  This is done by moving the base value
        into a temp register and biasing the temp base and offset to smaller values so that we can emit
        instructions that can reference characters without exceeding the 31 bits of negative offset.

        To abstract the character address generation, put the base with scaled index and offset into
        one function and used that function everywhere the YARR JIT wants to access subject characters.
        Also consilidated a few cases where we were generating inline what readCharacter() does.  Usually
        this was due to using a different index register.

        Added a new regression test.

        * tests/stress/regress-159744.js: Added regression test.
        (testRegExp):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::recordParenthesesMatch):
        (JSC::Yarr::Interpreter::resetMatches):
        (JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
        (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::closeBodyAlternative):
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
        (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
        (JSC::Yarr::ByteCompiler::emitDisjunction):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::ByteTerm::ByteTerm):
        (JSC::Yarr::ByteTerm::BOL):
        (JSC::Yarr::ByteTerm::UncheckInput):
        (JSC::Yarr::ByteTerm::EOL):
        (JSC::Yarr::ByteTerm::WordBoundary):
        (JSC::Yarr::ByteTerm::BackReference):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::notAtEndOfInput):
        (JSC::Yarr::YarrGenerator::negativeOffsetIndexedAddress):
        (JSC::Yarr::YarrGenerator::readCharacter):
        (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
        (JSC::Yarr::YarrGenerator::storeToFrame):
        (JSC::Yarr::YarrGenerator::generateAssertionBOL):
        (JSC::Yarr::YarrGenerator::backtrackAssertionBOL):
        (JSC::Yarr::YarrGenerator::generateAssertionEOL):
        (JSC::Yarr::YarrGenerator::matchAssertionWordchar):
        (JSC::Yarr::YarrGenerator::generateAssertionWordBoundary):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
        (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generate):
        (JSC::Yarr::YarrGenerator::backtrack):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternTerm::PatternTerm):

2016-07-13  Keith Miller  <keith_miller@apple.com>

        Crashes with detached ArrayBuffers
        https://bugs.webkit.org/show_bug.cgi?id=157088
        <rdar://problem/27327362>

        Reviewed by Filip Pizlo.

        TypedArray.prototype.fill was incorrect because it should perform
        ToNumber coercion each time it tries to store the
        object. Currently, we only perform the coercion once at the
        beginning of the loop. If we find that we need to improve the
        performance of this function, we can add a faster C++ path back
        that only handles the primitive case.

        This patch also moves the isNeutered() checks from put and
        putByIndex into setIndex. This fixes an issue where setIndex might
        store to a no longer valid offset.

        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArrayClampArgumentToStartOrEnd):
        (fill):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndex):
        (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncFill): Deleted.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncFill): Deleted.
        * tests/stress/typedarray-fill.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (test2):
        (checkArgumentsForType): Deleted.
        (checkArguments): Deleted.

2016-07-13  Michael Saboff  <msaboff@apple.com>

        Some bad unicode regex escapes aren't flagged as errors
        https://bugs.webkit.org/show_bug.cgi?id=158080

        Reviewed by Saam Barati.

        If we have a partial unicode escape, eg /\u{1/u or /\u12|abc/u, we
        didn't check for the closing '}' and processed the unicode escape with
        the hex value provided.  

        Added a check that we properly terminated a \u{} unicode escape.
        If we fail that check and there isn't a prior error, we record that we
        have an invalid unicode escape.  The next existing line in the code will
        terminate parsing and bubble up the error.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):

2016-07-13  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r203199.

        Broke the build

        Reverted changeset:

        "Crashes with detached ArrayBuffers"
        https://bugs.webkit.org/show_bug.cgi?id=157088
        http://trac.webkit.org/changeset/203199

2016-07-13  Keith Miller  <keith_miller@apple.com>

        Crashes with detached ArrayBuffers
        https://bugs.webkit.org/show_bug.cgi?id=157088
        <rdar://problem/27327362>

        Reviewed by Filip Pizlo.

        TypedArray.prototype.fill was incorrect because it should perform
        ToNumber coercion each time it tries to store the
        object. Currently, we only perform the coercion once at the
        beginning of the loop. If we find that we need to improve the
        performance of this function, we can add a faster C++ path back
        that only handles the primitive case.

        This patch also moves the isNeutered() checks from put and
        putByIndex into setIndex. This fixes an issue where setIndex might
        store to a no longer valid offset.

        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArrayClampArgumentToStartOrEnd):
        (fill):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndex):
        (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::put): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncFill): Deleted.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncFill): Deleted.
        * tests/stress/typedarray-fill.js:
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (test2):
        (checkArgumentsForType): Deleted.
        (checkArguments): Deleted.

2016-07-13  Enrica Casucci  <enrica@apple.com>

        Update supported platforms in xcconfig files to match the sdk names.
        https://bugs.webkit.org/show_bug.cgi?id=159728

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:

2016-07-13  Csaba Osztrogonác  <ossy@webkit.org>

        CLoop buildfix after r203142
        https://bugs.webkit.org/show_bug.cgi?id=159706

        Unreviewed buildfix.

        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::isSafeToRecurse):
        * interpreter/CLoopStack.h:
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::isSafeToRecurse): Deleted.

2016-07-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Array.prototype.join() fails some conformance tests
        https://bugs.webkit.org/show_bug.cgi?id=159657

        Reviewed by Saam Barati.

        There were a couple of failures:
        -separator.toString() was called *before* we get the length
         and process ToLength() on it.
        -We were using toUInt32() on length instead of ToLength(),
         failing on big integers and various negative numbers.

        Additionally, I replaced the "fast" ArrayStorage path
        by a fully generic implementation that does not depends on StringJoiner.

        The reason is StringJoiner was doing poorly on sparse objects
        in certain cases.
        If you have a sparse object with a length > INT_MAX but very few
        indices defined, and you join on the empty string, it should be possible
        to join the array (albeit very slowly). With StringJoiner, we fail
        because we try to allocate > INT_MAX empty strings in a contiguous vector.

        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::join): Deleted.
        * runtime/JSArray.h:
        (JSC::toLength):

2016-07-12  Mark Lam  <mark.lam@apple.com>

        Gardening: C Loop build fix after r203142.

        Not reviewed.

        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::isSafeToRecurse):

2016-07-12  Commit Queue  <commit-queue@webkit.org>

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

        This change caused an existing LayoutTest to time out on debug
        testers (Requested by ryanhaddad on #webkit).

        Reverted changeset:

        "[JSC] Array.prototype.join() fails some conformance tests"
        https://bugs.webkit.org/show_bug.cgi?id=159657
        http://trac.webkit.org/changeset/203131

2016-07-12  Mark Lam  <mark.lam@apple.com>

        We should use different stack limits for stack checks from JS and host code.
        https://bugs.webkit.org/show_bug.cgi?id=159442
        <rdar://problem/26889188>

        Reviewed by Geoffrey Garen.

        We have 2 stack reservedZoneSizes:
        1. Options::softReservedZoneSize()
        2. Options::reservedZoneSize()

        Respectively, there are used to define 2 stack limits based on these reserved
        zone sizes:
        1. VM::m_softStackLimit
        2. VM::m_stackLimit

        Options::reservedZoneSize() is the amount of the stack space that JSC guarantees
        to the VM and client host code for it's use.  Host code that has well known
        stack usage characteristics (i.e. doesn't call arbitrary code) may do stack
        checks against the VM::m_stackLimit limit (which is computed using
        Options::reservedZoneSize()).

        Options::softReservedZoneSize() is a more conservative amount of reserved stack
        space.  This is used to compute the VM::m_softStackLimit limit.  Any code that
        is difficult to have its stack usage characterized (i.e. may call arbitrary code)
        may need more stack space for its work.  Hence, these should do stack checks
        against the VM::m_softStackLimit limit.

        JS code and host code that may call into JS code falls into the category of code
        that may call arbitrary code.  Hence, they should do stack checks against the
        VM::m_softStackLimit limit.

        Accordingly, the VM now provides 2 recursion check functions:

        1. VM::isSafeToRecurseSoft() will do a stack check against VM::m_softStackLimit.
           In addition, for C Loop builds, VM::isSafeToRecurseSoft() will also
           check the CLoopStack against VM::m_cloopStackLimit.

        2. VM::isSafeToRecurse() will do a stack check against VM::m_stackLimit.

        Also added a promise-infinite-recursion-should-not-crash.js test.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNodeInTailPosition):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::grow):
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::size):
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::isSafeToRecurse):
        (JSC::CLoopStack::topOfFrameFor):
        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/Parser.cpp:
        * runtime/Options.h:
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        * runtime/VM.cpp:
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::preCommitStackMemory):
        (JSC::VM::updateStackLimits):
        (JSC::VM::updateStackLimit): Deleted.
        * runtime/VM.h:
        (JSC::VM::stackLimit):
        (JSC::VM::softStackLimit):
        (JSC::VM::addressOfSoftStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::lastStackTop):
        (JSC::VM::setException):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft):
        (JSC::VM::shouldTriggerTermination):
        * tests/stress/promise-infinite-recursion-should-not-crash.js: Added.
        (testPromise):
        (promiseFunc):
        * yarr/YarrPattern.cpp:

2016-07-12  Per Arne Vollan  <pvollan@apple.com>

        [Win] Fix for build error when trying to version stamp dll.
        https://bugs.webkit.org/show_bug.cgi?id=159692

        Reviewed by Brent Fulgham.

        Use correct path to version stamp script.

        * CMakeLists.txt:

2016-07-12  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Array.prototype.join() fails some conformance tests
        https://bugs.webkit.org/show_bug.cgi?id=159657

        Reviewed by Saam Barati.

        There were a couple of failures:
        -separator.toString() was called *before* we get the length
         and process ToLength() on it.
        -We were using toUInt32() on length instead of ToLength(),
         failing on big integers and various negative numbers.

        Additionally, I replaced the "fast" ArrayStorage path
        by a fully generic implementation that does not depends on StringJoiner.

        The reason is StringJoiner was doing poorly on sparse objects
        in certain cases.
        If you have a sparse object with a length > INT_MAX but very few
        indices defined, and you join on the empty string, it should be possible
        to join the array (albeit very slowly). With StringJoiner, we fail
        because we try to allocate > INT_MAX empty strings in a contiguous vector.

        * runtime/ArrayPrototype.cpp:
        (JSC::slowJoin):
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncJoin):
        (JSC::join): Deleted.
        * runtime/JSArray.h:
        (JSC::toLength):

2016-07-12  Mark Lam  <mark.lam@apple.com>

        More stack limit and reserved zone renaming.
        https://bugs.webkit.org/show_bug.cgi?id=159690

        Rubber-stamped by Geoffrey Garen.

        We should rename the following:
            osStackLimitWithReserve => softStackLimit
            reservedZoneSize => softReservedZoneSize
            errorModeReservedZoneSize => reservedZoneSize

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::grow):
        (JSC::CLoopStack::releaseExcessCapacity):
        (JSC::CLoopStack::addToCommittedByteCount):
        (JSC::CLoopStack::setSoftReservedZoneSize):
        (JSC::CLoopStack::setReservedZoneSize): Deleted.
        * interpreter/CLoopStack.h:
        (JSC::CLoopStack::size):
        * interpreter/CLoopStackInlines.h:
        (JSC::CLoopStack::shrink):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ErrorHandlingScope.cpp:
        (JSC::ErrorHandlingScope::ErrorHandlingScope):
        (JSC::ErrorHandlingScope::~ErrorHandlingScope):
        * runtime/ErrorHandlingScope.h:
        * runtime/Options.h:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::setStackPointerAtVMEntry):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::VM::updateStackLimit):
        (JSC::VM::updateReservedZoneSize): Deleted.
        * runtime/VM.h:
        (JSC::VM::stackPointerAtVMEntry):
        (JSC::VM::softReservedZoneSize):
        (JSC::VM::softStackLimit):
        (JSC::VM::addressOfSoftStackLimit):
        (JSC::VM::cloopStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::reservedZoneSize): Deleted.
        (JSC::VM::osStackLimitWithReserve): Deleted.
        (JSC::VM::addressOfOSStackLimitWithReserve): Deleted.
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-12  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Remove ENABLE_CSS3_TEXT_LINE_BREAK flag
        https://bugs.webkit.org/show_bug.cgi?id=159671

        Reviewed by Csaba Osztrogonác.

        ENABLE_CSS3_TEXT_LINE_BREAK feature was implemented without guards.
        https://bugs.webkit.org/show_bug.cgi?id=89235

        So this guard can be removed in build scripts.

        * Configurations/FeatureDefines.xcconfig:

2016-07-12  Per Arne Vollan  <pvollan@apple.com>

        [Win] DLLs are missing version information.
        https://bugs.webkit.org/show_bug.cgi?id=159349

        Reviewed by Brent Fulgham.

        Generate autoversion.h and run perl version stamp utility.

        * CMakeLists.txt:

2016-07-11  Caio Lima  <ticaiolima@gmail.com>

        ECMAScript 2016: %TypedArray%.prototype.includes implementation
        https://bugs.webkit.org/show_bug.cgi?id=159385

        Reviewed by Benjamin Poulain.

        This patch implements the ECMAScript 2016:
        %TypedArray%.prototype.includes
        following spec 22.2.3.14
        https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-07-11  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.from() and Array.of() try to build objects even if "this" is not a constructor
        https://bugs.webkit.org/show_bug.cgi?id=159604

        Reviewed by Yusuke Suzuki.

        The spec says IsConstructor(), we were just checking if "this"
        is any function.

        * builtins/ArrayConstructor.js:
        (of):
        (from):

2016-07-11  Keith Miller  <keith_miller@apple.com>

        defineProperty on a index of a TypedArray should throw if configurable
        https://bugs.webkit.org/show_bug.cgi?id=159653

        Reviewed by Saam Barati.

        When I fixed this before I misread the spec and thought it said we
        should throw if the descriptor said the proprety is not
        configurable. This is the opposite. We should throw if the
        descriptor says the property is configurable.

        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * tests/stress/typedarray-access-monomorphic-neutered.js:
        * tests/stress/typedarray-access-neutered.js:
        * tests/stress/typedarray-configure-index.js: Added.
        (assert):
        (assertThrows):
        (makeDescriptor):
        (test):

2016-07-11  Saam Barati  <sbarati@apple.com>

        some paths in Array.prototype.splice don't account for the array not having certain indexed properties
        https://bugs.webkit.org/show_bug.cgi?id=159641
        <rdar://problem/27171999>

        Reviewed by Filip Pizlo and Keith Miller.

        Array.prototype.splice was incorrectly putting properties on
        the result array even if the |this| array didn't have those
        properties. This is not the behavior of the spec. However, this
        could also cause a crash because we can construct a program where
        we would putByIndex on a typed array where the value we are
        putting is JSValue(). This is bad because the typed array will
        try to convert JSValue() into an integer.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * tests/stress/array-prototype-splice-making-typed-array.js: Added.
        (assert):
        (test):

2016-07-11  Mark Lam  <mark.lam@apple.com>

        Refactor JSStack to only be the stack data structure for the C Loop.
        https://bugs.webkit.org/show_bug.cgi?id=159545

        Reviewed by Geoffrey Garen.

        Changes made:
        1. Renamed JSStack to CLoopStack.
        2. Made all of CLoopStack code to conditional on #if !ENABLE(JIT) i.e. they will
           only be in effect for the C Loop build.
        3. Changed clients of JSStack to use new equivalent VM APIs:
            a. JSStack::ensureCapacityFor() => VM::ensureStackCapacityFor()
            b. JSStack::committedByteCount() => VM::committedStackByteCount()
        4. Made VM::updateReservedZoneSize() call CLoopStack::setReservedZoneSize()
           instead of calling it from all the clients of VM::updateReservedZoneSize().
        5. Removed all unnecessary references to JSStack.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MaxFrameExtentForSlowPathCall.h:
        * bytecode/BytecodeConventions.h:
        * dfg/DFGGraph.h:
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::willStartIterating):
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::stack): Deleted.
        * heap/Heap.h:
        * interpreter/CLoopStack.cpp: Copied from Source/JavaScriptCore/interpreter/JSStack.cpp.
        (JSC::commitSize):
        (JSC::CLoopStack::CLoopStack):
        (JSC::CLoopStack::~CLoopStack):
        (JSC::CLoopStack::grow):
        (JSC::CLoopStack::gatherConservativeRoots):
        (JSC::CLoopStack::sanitizeStack):
        (JSC::CLoopStack::releaseExcessCapacity):
        (JSC::CLoopStack::addToCommittedByteCount):
        (JSC::CLoopStack::setReservedZoneSize):
        (JSC::CLoopStack::committedByteCount):
        (JSC::JSStack::JSStack): Deleted.
        (JSC::JSStack::~JSStack): Deleted.
        (JSC::JSStack::growSlowCase): Deleted.
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        (JSC::JSStack::sanitizeStack): Deleted.
        (JSC::JSStack::releaseExcessCapacity): Deleted.
        (JSC::JSStack::addToCommittedByteCount): Deleted.
        (JSC::JSStack::setReservedZoneSize): Deleted.
        (JSC::JSStack::lowAddress): Deleted.
        (JSC::JSStack::highAddress): Deleted.
        (JSC::JSStack::committedByteCount): Deleted.
        * interpreter/CLoopStack.h: Copied from Source/JavaScriptCore/interpreter/JSStack.h.
        (JSC::CLoopStack::containsAddress):
        (JSC::CLoopStack::lowAddress):
        (JSC::CLoopStack::highAddress):
        (JSC::CLoopStack::reservationTop):
        (JSC::JSStack::containsAddress): Deleted.
        (JSC::JSStack::lowAddress): Deleted.
        (JSC::JSStack::highAddress): Deleted.
        (JSC::JSStack::reservationTop): Deleted.
        * interpreter/CLoopStackInlines.h: Copied from Source/JavaScriptCore/interpreter/JSStackInlines.h.
        (JSC::CLoopStack::ensureCapacityFor):
        (JSC::CLoopStack::topOfFrameFor):
        (JSC::CLoopStack::topOfStack):
        (JSC::CLoopStack::shrink):
        (JSC::CLoopStack::setCLoopStackLimit):
        (JSC::JSStack::ensureCapacityFor): Deleted.
        (JSC::JSStack::topOfFrameFor): Deleted.
        (JSC::JSStack::topOfStack): Deleted.
        (JSC::JSStack::shrink): Deleted.
        (JSC::JSStack::grow): Deleted.
        (JSC::JSStack::setCLoopStackLimit): Deleted.
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::unsafeCallSiteIndex):
        (JSC::CallFrame::currentVPC):
        (JSC::CallFrame::stack): Deleted.
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForForwardArguments):
        (JSC::sizeFrameForVarargs):
        (JSC::Interpreter::Interpreter):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::cloopStack):
        (JSC::Interpreter::getOpcode):
        (JSC::Interpreter::isCallBytecode):
        (JSC::Interpreter::stack): Deleted.
        * interpreter/JSStack.cpp: Removed.
        * interpreter/JSStack.h: Removed.
        * interpreter/JSStackInlines.h: Removed.
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::dump):
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/JSInterfaceJIT.h:
        * jit/SpecializedThunkJIT.h:
        * jit/ThunkGenerators.cpp:
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::llint_stack_check_at_vm_entry):
        * llint/LLIntThunks.cpp:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/ErrorHandlingScope.cpp:
        (JSC::ErrorHandlingScope::ErrorHandlingScope):
        (JSC::ErrorHandlingScope::~ErrorHandlingScope):
        * runtime/JSGlobalObject.h:
        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):
        * runtime/StackAlignment.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateReservedZoneSize):
        (JSC::sanitizeStackForVM):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::osStackLimitWithReserve):
        (JSC::VM::addressOfOSStackLimitWithReserve):
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::shouldTriggerTermination):

2016-07-11  Keith Miller  <keith_miller@apple.com>

        STP TypedArray.subarray 5x slowdown compared to 9.1
        https://bugs.webkit.org/show_bug.cgi?id=156404
        <rdar://problem/26493032>

        Reviewed by Geoffrey Garen.

        This patch moves the species constructor work for
        %TypedArray%.prototype.subarray to a js wrapper. By moving the
        species constructor work to JS we are able to completely optimize
        it out in DFG. The actual work of creating a TypedArray is still
        done in C++ since we are able to avoid calling into the
        constructor, which is expensive. This patch also changes the error
        message when a %TypedArray%.prototype function is passed a non-typed
        array this value. Finally, we used to check that the this value
        had not been detached, however, this behavior was incorrect.

        * builtins/BuiltinNames.h:
        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArraySpeciesConstructor):
        (subarray):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/ConstructData.h:
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSubarrayCreate):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSTypedArrayViewPrototype.h:

2016-07-11  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r202992): JSC varargs tests are broken
        https://bugs.webkit.org/show_bug.cgi?id=159616

        Reviewed by Csaba Osztrogonác.

        The substitution miss in r202992 causes varargs tests failures in GTK port.

        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):

2016-07-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Promise.{all,race} no longer use @@species
        https://bugs.webkit.org/show_bug.cgi?id=159615

        Reviewed by Keith Miller.

        As per the latest ES draft, Promise.{all,race} no longer use @@species.
        So, this patch drops FIXMEs.

        * builtins/PromiseConstructor.js:
        (all):
        (race):
        * tests/stress/ignore-promise-species.js: Added.
        (shouldBe):
        (DerivedPromise.prototype.get Symbol):
        (DerivedPromise):

2016-07-10  Commit Queue  <commit-queue@webkit.org>

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

        The JSC tests are breaking in elcapitan-debug-tests-jsc and
        elcapitan-release-tests-jsc (Requested by caiolima on
        #webkit).

        Reverted changeset:

        "ECMAScript 2016: %TypedArray%.prototype.includes
        implementation"
        https://bugs.webkit.org/show_bug.cgi?id=159385
        http://trac.webkit.org/changeset/203037

2016-07-10  Caio Lima  <ticaiolima@gmail.com>

        ECMAScript 2016: %TypedArray%.prototype.includes implementation
        https://bugs.webkit.org/show_bug.cgi?id=159385

        Reviewed by Benjamin Poulain.

        This patch implements the ECMAScript 2016:
        %TypedArray%.prototype.includes
        following spec 22.2.3.14
        https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIncludes):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncIncludes):
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-07-09  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(201900): validation failure for GetByOffset/PutByOffset in VALIDATE((node), node->child1().node() == node->child2().node() || node->child1()->result() == NodeResultStorage)
        https://bugs.webkit.org/show_bug.cgi?id=159603

        Reviewed by Keith Miller.
        
        This removes an incorrect validation rule and replaces it with a FIXME about how to make this
        aspect of IR easier to validate soundly.
        
        It's not valid to assert that two children of a node are the same. It should always be valid
        to take:
        
        Foo(@x, @x)
        
        and turn it into:
        
        a: ValueRep(@x)
        b: ValueRep(@x)
        Foo(@a, @b)
        
        or even something like:
        
        y: Identity(@y)
        Foo(@x, @y)
        
        That's because it should be possible to rewire any data flow edge something that produces an
        equivalent value.
        
        The validation rule that this patch removes meant that such rewirings were invalid on
        GetByOffset/PutByOffset. FixupPhase did such a rewiring sometimes.

        * dfg/DFGValidate.cpp:
        * tests/stress/get-by-offset-double.js: Added.

2016-07-09  Keith Miller  <keith_miller@apple.com>

        appendMemcpy might fail in concatAppendOne
        https://bugs.webkit.org/show_bug.cgi?id=159601
        <rdar://problem/27211300>

        Reviewed by Mark Lam.

        There are multiple reasons why we might fail appendMemcpy. One
        reason, which I suspect was the source of the crashes, is that one
        of the Array prototypes has an indexed property. This patch
        consolidates the two old cases by just creating an array then
        attempting to memcpy append. If that fails, we fall back to
        moveElements.

        * runtime/ArrayPrototype.cpp:
        (JSC::concatAppendOne):
        * tests/stress/concat-with-holesMustForwardToPrototype.js: Added.
        (arrayEq):

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

        [JSC] Fix the Template Raw Value of \ (escape) + LineTerminatorSequence
        https://bugs.webkit.org/show_bug.cgi?id=159595

        Reviewed by Yusuke Suzuki.

        The spec (https://tc39.github.io/ecma262/#sec-static-semantics-tv-and-trv)
        says:
        "The TRV of LineContinuation::\LineTerminatorSequence is the sequence
         consisting of the code unit value 0x005C followed by the code units
         of TRV of LineTerminatorSequence."
        
        We were not normalizing the LineTerminatorSequence in that case, but it should
        be as it is the TRV of LineTerminatorSequence.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseTemplateLiteral):
        * tests/stress/tagged-templates-raw-strings.js:

2016-07-08  Saam Barati  <sbarati@apple.com>

        We may add a ReadOnly property without setting the corresponding bit on Structure
        https://bugs.webkit.org/show_bug.cgi?id=159542
        <rdar://problem/27084591>

        Reviewed by Benjamin Poulain.

        The reason this usually is OK is due to happenstance. Often, instances that putDirectWithoutTransition
        also happen to have a static property table. Having a static property table causes the
        HasReadOnlyOrGetterSetterPropertiesExcludingProto on the structure to be set. However, 
        there are times where an object calls putDirectWithoutTransition, and it doesn't have a
        static property hash table. The fix is simple, putDirectWithTransition needs to set the
        HasReadOnlyOrGetterSetterPropertiesExcludingProto if it puts a ReadOnly property.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectWithoutTransition):
        * tests/stress/proper-property-store-with-prototype-property-that-is-not-writable.js: Added.
        (assert):

2016-07-08  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: Heap::isMarked(cell) in SlotVisitor::appendToMarkStack(JSC::JSCell *)
        https://bugs.webkit.org/show_bug.cgi?id=159588

        Reviewed by Geoffrey Garen.

        We were jettisoning a CodeBlock during GC that won't survive and its owning script
        won't survive either.  We can't install any code on the owning script as that involves
        a write barrier that will "pull" the script back into the remembered set.  Badness would
        ensue.  Added an early return in CodeBlock::jettison() when we are garbage collecting
        and the owning script isn't marked.

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

2016-07-08  Mark Lam  <mark.lam@apple.com>

        Move CallFrame header info from JSStack.h to CallFrame.h
        https://bugs.webkit.org/show_bug.cgi?id=159549

        Reviewed by Geoffrey Garen.

        CallFrame.h is a much better location for CallFrame header info.

        Replaced CallFrame::init() with ExecState::initGlobalExec() because normal
        CallFrames are setup by a different mechanism now.  Only the globalExec is still
        using it.  So, might as well change it to be specifically for the globalExec.

        Removed the use of JSStack::containsAddress() in ExecState::initGlobalExec()
        because it is not relevant to the globalExec.

        Also removed some unused code: JSStack::gatherConservativeRoots() and
        JSStack::sanitizeStack() is never called for JIT builds.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::isValid):
        (JSC::VirtualRegister::isLocal):
        (JSC::VirtualRegister::isArgument):
        (JSC::VirtualRegister::isHeader):
        (JSC::VirtualRegister::isConstant):
        (JSC::VirtualRegister::toLocal):
        (JSC::VirtualRegister::toArgument):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::thisRegister):
        (JSC::CallArguments::argumentRegister):
        (JSC::CallArguments::stackOffset):
        (JSC::CallArguments::argumentCountIncludingThis):
        (JSC::CallArguments::argumentsNode):
        (JSC::BytecodeGenerator::registerFor):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitGetSuperFunctionForConstruct):
        (JSC::CallArguments::CallArguments):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::getArgumentCount):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
        (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
        (JSC::FTL::DFG::LowerDFGToB3::callPreflight):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLSlowPathCall.h:
        (JSC::FTL::callOperation):
        * interpreter/CallFrame.cpp:
        (JSC::ExecState::initGlobalExec):
        (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
        (JSC::CallFrame::callSiteAsRawBits):
        (JSC::CallFrame::unsafeCallSiteAsRawBits):
        (JSC::CallFrame::callSiteIndex):
        (JSC::CallFrame::setCurrentVPC):
        (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
        * interpreter/CallFrame.h:
        (JSC::CallSiteIndex::CallSiteIndex):
        (JSC::ExecState::calleeAsValue):
        (JSC::ExecState::callee):
        (JSC::ExecState::unsafeCallee):
        (JSC::ExecState::codeBlock):
        (JSC::ExecState::unsafeCodeBlock):
        (JSC::ExecState::scope):
        (JSC::ExecState::setCallerFrame):
        (JSC::ExecState::setScope):
        (JSC::ExecState::argumentCount):
        (JSC::ExecState::argumentCountIncludingThis):
        (JSC::ExecState::argumentOffset):
        (JSC::ExecState::argumentOffsetIncludingThis):
        (JSC::ExecState::offsetFor):
        (JSC::ExecState::noCaller):
        (JSC::ExecState::setArgumentCountIncludingThis):
        (JSC::ExecState::setCallee):
        (JSC::ExecState::setCodeBlock):
        (JSC::ExecState::setReturnPC):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::callerFrameAndPC):
        (JSC::ExecState::unsafeCallerFrameAndPC):
        (JSC::ExecState::init): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        * interpreter/Interpreter.h:
        (JSC::calleeFrameForVarargs):
        * interpreter/JSStack.h:
        (JSC::JSStack::containsAddress):
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        (JSC::JSStack::sanitizeStack): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
        (JSC::AssemblyHelpers::emitRandomThunk):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::restoreReturnAddressBeforeReturn):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
        (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue):
        (JSC::AssemblyHelpers::calleeFrameSlot):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::logShadowChickenProloguePacket):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::dump):
        (JSC::CallFrameShuffler::extendFrameIfNeeded):
        (JSC::CallFrameShuffler::prepareForSlowPath):
        (JSC::CallFrameShuffler::prepareForTailCall):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::snapshot):
        (JSC::CallFrameShuffler::setCalleeJSValueRegs):
        (JSC::CallFrameShuffler::assumeCalleeIsCell):
        (JSC::CallFrameShuffler::numLocals):
        (JSC::CallFrameShuffler::getOld):
        (JSC::CallFrameShuffler::setOld):
        (JSC::CallFrameShuffler::firstOld):
        (JSC::CallFrameShuffler::lastOld):
        (JSC::CallFrameShuffler::isValidOld):
        (JSC::CallFrameShuffler::argCount):
        (JSC::CallFrameShuffler::getNew):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITInlines.h:
        (JSC::JIT::getConstantOperand):
        (JSC::JIT::emitPutIntToCallFrameHeader):
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_get_rest_length):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_get_scope):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfNotType):
        (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr):
        (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
        (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetVarargsFrame):
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        (JSC::arityFixupGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/StackAlignment.h:
        (JSC::roundArgumentCountToAlignFrame):
        (JSC::roundLocalRegisterCountForFramePointerOffset):
        (JSC::logStackAlignmentRegisters):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):

2016-07-08  Chris Dumez  <cdumez@apple.com>

        Object.defineProperty() should maintain existing getter / setter if not overridden in the new descriptor
        https://bugs.webkit.org/show_bug.cgi?id=159576
        <rdar://problem/27242197>

        Reviewed by Mark Lam.

        Object.defineProperty() should maintain existing getter / setter if not
        overridden in the new descriptor. Previously, if the property is a had
        a custom getter / setter, and if the new descriptor only had a setter
        (or only a getter), JSC would clear the existing getter (or setter).
        This behavior did not match the EcmaScript specification or Firefox /
        Chrome. This patch fixes the issue.

        This fixes searching and search suggestions on www.iciba.com.

        * runtime/JSObject.cpp:
        (JSC::validateAndApplyPropertyDescriptor):

2016-07-08  Michael Saboff  <msaboff@apple.com>

        Dumping the object graph doesn't work with verbose GC logging
        https://bugs.webkit.org/show_bug.cgi?id=159569

        Reviewed by Mark Lam.

        The current object graph logging code tries to revisits the graph.  This doesn't work
        correctly and asking around it isn't used.  The only way to dump the true object graph
        is to log while we GC and that has obvious performance implications.
        Therefore I eliminated GCLogging::dumpObjectGraph() and related code.  

        * heap/GCLogging.cpp:
        (JSC::GCLogging::levelAsString):
        (JSC::LoggingFunctor::LoggingFunctor): Deleted.
        (JSC::LoggingFunctor::~LoggingFunctor): Deleted.
        (JSC::LoggingFunctor::operator()): Deleted.
        (JSC::LoggingFunctor::log): Deleted.
        (JSC::LoggingFunctor::reviveCells): Deleted.
        (JSC::LoggingFunctor::returnValue): Deleted.
        (JSC::GCLogging::dumpObjectGraph): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::didFinishCollection):

2016-07-08  Keith Miller  <keith_miller@apple.com>

        speculateTypedArrayIsNotNeutered has an inverted speculation
        https://bugs.webkit.org/show_bug.cgi?id=159571

        Reviewed by Mark Lam.

        For some confusing reason FTLLowerDFGToB3 takes the condition the
        speculation wants to be false. This issue caused
        typedarray-access-monomorphic-neutered.js to fail on the bots.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):

2016-07-08  Mark Lam  <mark.lam@apple.com>

        Rename jsCPUStackLimit to osStackLimitWithReserve and jsEmulatedStackLimit to cloopStackLimit.
        https://bugs.webkit.org/show_bug.cgi?id=159544

        Reviewed by Geoffrey Garen.

        This patch does the following refactoring:
        1. Rename jsCPUStackLimit to osStackLimitWithReserve.
        2. Rename jsEmulatedStackLimit to cloopStackLimit.
        2. Remove llintStackLimit (which previously is either an alias for
           jsCPUStackLimit or jsEmulatedStackLimit depending on whether we have a JIT or
           C Loop build).  Instead, we'll change the LLINT to conditionally use the
           osStackLimitWithReserve or cloopStackLimit.

        There are no semantic changes.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        * interpreter/JSStack.h:
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::ensureCapacityFor):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        (JSC::JSStack::setCLoopStackLimit):
        (JSC::JSStack::setJSEmulatedStackLimit): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::updateStackLimit):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::osStackLimitWithReserve):
        (JSC::VM::addressOfOSStackLimitWithReserve):
        (JSC::VM::cloopStackLimit):
        (JSC::VM::setCLoopStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::jsCPUStackLimit): Deleted.
        (JSC::VM::addressOfJSCPUStackLimit): Deleted.
        (JSC::VM::jsEmulatedStackLimit): Deleted.
        (JSC::VM::setJSEmulatedStackLimit): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-08  Commit Queue  <commit-queue@webkit.org>

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

        Caused build failure (Requested by perarne on #webkit).

        Reverted changeset:

        "[Win] DLLs are missing version information."
        https://bugs.webkit.org/show_bug.cgi?id=159349
        http://trac.webkit.org/changeset/202799

2016-07-08  Youenn Fablet  <youenn@apple.com>

        Built-in generator should generate files with a default copyright
        https://bugs.webkit.org/show_bug.cgi?id=159561

        Reviewed by Alex Christensen.

        * Scripts/builtins/builtins_model.py:
        (BuiltinsCollection._parse_copyright_lines): Adding default copyright to the parsed copyrights.
        * Scripts/builtins/builtins_templates.py:
        (BuiltinsGeneratorTemplates): Adding a default copyright.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Rebasing with added default copyright.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Ditto.


2016-07-08  Keith Miller  <keith_miller@apple.com>

        TypedArrays need more isNeutered checks.
        https://bugs.webkit.org/show_bug.cgi?id=159231

        Reviewed by Filip Pizlo.

        According to the ES6 spec if a user tries to get, set, or define a
        property on a neutered TypedArray we should throw an
        exception. Currently, if a user tries to get an out of bounds
        access on a TypedArray we will always OSR.  This makes handling
        the exception easy as all we need to do is make out of bounds gets
        in PolymorphicAccess go to the slow path, which will then throw
        the appropriate exception. For the case of set, we need ensure we
        don't OSR on each out of bounds put since, for some confusing
        reason, people do this.  Thus, for GetByVal in the DFG/FTL if the
        user accesses out of bounds we then need to check if the view has
        been neutered. If it is neutered then we will OSR.

        Additionally, this patch adds a bunch of isNeutered checks to
        various prototype functions for TypedArray, which are needed for
        correctness.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCJSValue.h:
        (JSC::encodedJSUndefined):
        (JSC::encodedJSValue):
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::throwNeuteredTypedArrayTypeError):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::deletePropertyByIndex):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncFill):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * tests/stress/fold-typed-array-properties.js:
        * tests/stress/typedarray-access-monomorphic-neutered.js: Added.
        (check):
        (test):
        (testFTL):
        * tests/stress/typedarray-access-neutered.js: Added.
        (check):
        (test):
        * tests/stress/typedarray-functions-with-neutered.js:
        (defaultForArg):
        (callWithArgs):
        (checkArgumentsForType):
        (checkArguments):
        * tests/stress/typedarray-view-string-properties-neutered.js: Added.
        (call):
        (test):

2016-07-08  Youenn Fablet  <youenn@apple.com>

        Generate WebCore builtin wrapper files
        https://bugs.webkit.org/show_bug.cgi?id=159461

        Reviewed by Brian Burg.

        Updating builtin generator to generate wrapper files used in WebCore (See WebCore change log).
        Rebasing builtins generator test results according generator changes by activating wrapper file generation for
        WebCore builtins tests.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins.py: Adding new generators.
        * Scripts/builtins/builtins_generate_internals_wrapper_header.py: Added to generate WebCoreJSBuiltinInternals.h.
        * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: Added to generate WebCoreJSBuiltinInternals.cpp.
        * Scripts/builtins/builtins_generate_wrapper_header.py: Added to generate WebCoreJSBuiltins.h.
        * Scripts/builtins/builtins_generate_wrapper_implementation.py: Added to generate WebCoreJSBuiltins.cpp.
        * Scripts/generate-js-builtins.py: Adding new option to activate generation of the wrapper files.
        (generate_bindings_for_builtins_files):
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>

        padStart/padEnd with Infinity produces unexpected result
        https://bugs.webkit.org/show_bug.cgi?id=159543

        Reviewed by Benjamin Poulain.

        * builtins/GlobalOperations.js:
        (globalPrivate.toLength):
        Fix style.

        * builtins/StringPrototype.js:
        (padStart):
        (padEnd):
        After all observable operations, and after empty string has been handled,
        throw an out of memory error if the resulting string would be greater
        than the maximum string size.

        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
        (shouldThrow): Deleted.
        * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
        (shouldThrow):
        (testMeta):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        (shouldThrow):
        (TestToLength):
        (TestMemoryLimits):
        (TestMeta): Deleted.
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        (shouldThrow):
        (TestToLength):
        (TestMemoryLimits):
        Replace incorrect shouldThrow(..., errorType) with explicit shouldThrow(..., errorMessage).
        The old shouldThrow would incorrectly succeed if the expected error type was just "Error".
        Now we explicitly check the error message.

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] String.prototype[Symbol.iterator] needs a name
        https://bugs.webkit.org/show_bug.cgi?id=159541

        Reviewed by Yusuke Suzuki.

        A man needs a name.
        Spec: https://tc39.github.io/ecma262/#sec-string.prototype-@@iterator

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

2016-07-07  Michael Saboff  <msaboff@apple.com>

        REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch
        https://bugs.webkit.org/show_bug.cgi?id=159537

        Reviewed by Benjamin Poulain.

        We weren't checking the case of a child node with a null epoch.  The problem surfaces
        when the base node of a PutByVal variant has a non-null epoch, because it represents an
        allocation in the current function, while the child of the same node has an unknown epoch.
        Added a check that the child node is not null before comparing the epochs of the base and
        child nodes.

        The added test creates the problem circumstance by doing a full GC to place an array in
        remembered space, allocating a new object followed by an eden GC.  The new object is
        only referenced by the array and therefore won't be visited Without the store barrier.
        The test may crash or more likely get the wrong answer with the bug.

        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * tests/stress/regress-159537.js: Added test.
        (MyNumber):
        (MyNumber.prototype.plusOne):
        (bar):
        (foo):
        (test):

2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>

        Unexpected "Out of memory" error for "x".repeat(-1)
        https://bugs.webkit.org/show_bug.cgi?id=159529

        Reviewed by Benjamin Poulain.

        * builtins/StringPrototype.js:
        (globalPrivate.repeatSlowPath):
        (repeat):
        Move the @toInteger and range checking to the always path,
        since the spec does say it should always happen. Also remove
        the duplication of the fast path here.

        * runtime/StringPrototype.cpp:
        (JSC::repeatCharacter):
        Remove unused function.

        (JSC::stringProtoFuncRepeatCharacter):
        ASSERT if given a negative number. This is a private function
        only used internally.

        * tests/stress/string-repeat-edge-cases.js:
        (shouldThrow):
        Update expected error message.

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.prototype[Symbol.unscopables] should have the "includes" property
        https://bugs.webkit.org/show_bug.cgi?id=159504

        Reviewed by Keith Miller.

        The property "includes" was missing.
        Spec: https://tc39.github.io/ecma262/#sec-array.prototype-@@unscopables

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * tests/stress/unscopables.js:

2016-07-07  Saam Barati  <sbarati@apple.com>

        ToThis constant folding in DFG is incorrect when the structure indicates that toThis is overridden
        https://bugs.webkit.org/show_bug.cgi?id=159501
        <rdar://problem/27109354>

        Reviewed by Mark Lam.

        We *cannot* constant fold ToThis when the structure of an object
        indicates that toThis() is overridden. isToThisAnIdentity() inside
        AbstractInterpreterInlines accidentally wrote the opposite rule.
        The rule was written as we can constant fold ToThis only when
        toThis() is overridden. To fix the bug, we must write the rule
        as isToThisAnIdentity() can only be true as long as the structure
        set indicates that no structures override toThis().

        We could probably get more clever in the future and notice
        when we're dealing with a constant |this| values. For example,
        a ToThis might occur on a constant JSLexicalEnvironment. We could
        implement the rules of JSLexicalEnvironment's toThis() implementation
        inside AI/constant folding.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        * tests/stress/to-this-on-constant-lexical-environment.js: Added.
        (foo.bar):
        (foo.inner):
        (foo):

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Array.prototype.includes uses ToInt32 instead of ToInteger on the index argument
        https://bugs.webkit.org/show_bug.cgi?id=159505

        Reviewed by Mark Lam.

        The code was using (value)|0 which is effectively a ToInt32.
        This fails on large integers and +-Infinity.

        Spec: https://tc39.github.io/ecma262/#sec-array.prototype.includes

        * builtins/ArrayPrototype.js:
        (includes):

2016-07-07  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] String.prototype.normalize should have a length of zero
        https://bugs.webkit.org/show_bug.cgi?id=159506

        Reviewed by Yusuke Suzuki.

        Spec: https://tc39.github.io/ecma262/#sec-string.prototype.normalize
        The argument is optional, the length should be zero.

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

2016-07-07  Csaba Osztrogonác  <ossy@webkit.org>

        [ARMv7] REGRESSION(r197655): ASSERTION FAILED: (cond == Zero) || (cond == NonZero)
        https://bugs.webkit.org/show_bug.cgi?id=159419

        Reviewed by Benjamin Poulain.

        Allow Signed and PositiveOrZero conditions too because tst instruction updates N and Z flags.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchTest32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::branchTest32): Add assertions to avoid possible bugs in the future.

2016-07-06  Youenn Fablet  <youenn@apple.com>

        Builtin generator should use pragma once for header files
        https://bugs.webkit.org/show_bug.cgi?id=159462

        Reviewed by Alex Christensen.

        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output): 
        * Scripts/builtins/builtins_generate_separate_header.py:
        (BuiltinsSeparateHeaderGenerator.generate_output):
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2016-07-06  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Unify how we throw TypeError from C++
        https://bugs.webkit.org/show_bug.cgi?id=159500

        Reviewed by Saam Barati.

        Throwing a TypeError is an uncommon case. We should minimize the impact
        on the call sites.

        This patch does that by:
        -Replace the 2 calls createTypeError()->throwException() by throwTypeError().
        -Use ASCIILiteral when possible.
        -Add an overload of throwTypeError() taking ASCIILiteral directly
         (that way, the String creation and destruction is done by the callee).

        On x86_64, this reduces the __TEXT__ segment by 29kb.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToJSON):
        * runtime/Error.cpp:
        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
        (JSC::throwTypeError):
        * runtime/Error.h:
        (JSC::throwVMTypeError):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::toStringSlowCase):
        * runtime/JSCJSValueInlines.h:
        (JSC::toPreferredPrimitiveType):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):
        (JSC::callToPrimitiveFunction):
        (JSC::JSObject::ordinaryToPrimitive):
        (JSC::JSObject::defaultHasInstance):
        (JSC::validateAndApplyPropertyDescriptor):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::constructTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncFill):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoGetterFuncBuffer):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncSlice):
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        * runtime/Symbol.cpp:
        (JSC::Symbol::toNumber):

2016-07-06  Saam Barati  <sbarati@apple.com>

        InlineAccess::sizeForLengthAccess() is wrong on some platforms because it should also consider "length" not being array length
        https://bugs.webkit.org/show_bug.cgi?id=159429

        Reviewed by Filip Pizlo.

        The calculation inside sizeForLengthAccess() was not taking into
        account that an access to a "length" property might not be an
        array length access. sizeForLengthAccess() should always have enough
        room for a regular self property accesses. This only changes how
        much of a nop sled we emit if array length access size is smaller
        than self access size. This matters on ARM64.

        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):

2016-07-06  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r198928 and r198985.
        https://bugs.webkit.org/show_bug.cgi?id=159478

        "It's breaking some websites" (Requested by saamyjoon on
        #webkit).

        Reverted changesets:

        "[ES6] Disallow var assignments in for-in loops"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198928

        "Unreviewed, turn ES6 for-in loop test success"
        https://bugs.webkit.org/show_bug.cgi?id=155451
        http://trac.webkit.org/changeset/198985

2016-07-05  Mark Lam  <mark.lam@apple.com>

        Rename VM stack limit fields to better describe their purpose.
        https://bugs.webkit.org/show_bug.cgi?id=159451

        Reviewed by Keith Miller.

        This is in preparation for an upcoming patch that changes what stack limit values
        are used under various circumstances.  This patch aims to do some minimal work to
        rename the fields so that it will be easier to reason about the upcoming patch.
    
        In this patch, we make the following changes:

        1. Rename VM::m_stackLimit to VM::m_jsCPUStackLimit.

        2. VM::m_jsStackLimit used to have an overloaded meaning:
           a. For JIT builds, m_jsStackLimit is synonymous with m_stackLimit.
           b. For C Loop builds, m_jsStackLimit is a separate pointer that points to the
              emulated JS stack that the C Loop uses.

           In place of m_jsStackLimit, this patch introduces 2 new fields:
           VM::m_jsEmulatedStackLimit and VM::m_llintStackLimit.

           m_llintStackLimit is the limit that the LLInt assembly uses for its stack
           check.  m_llintStackLimit behaves like the old m_jsStackLimit in that:
           a. For JIT builds, m_llintStackLimit is synonymous with m_jsCPUStackLimit.
           b. For C Loop builds, m_llintStackLimit is synonymous with m_jsEmulatedStackLimit.

           m_jsEmulatedStackLimit is used for the emulated stack that the C Loop uses.

        3. Rename the following methods to match the above:
             VM::stackLimit() ==> VM::jsCPUStackLimit()
             VM::addressOfStackLimit() ==> VM::addressOfJSCPUStackLimit()
             VM::jsStackLimit() ==> VM::jsEmulatedStackLimit()
             VM::setJSStackLimit() ==> VM::setJSEmulatedStackLimit()
             JSStack::setStackLimit() ==> JSStack::setEmulatedStackLimit()

        4. With change (2) and (3), the limits will be used as follows:
           a. VM code doing stack recursion checks will only use m_jsCPUStackLimit.
           b. JIT code will only use m_jsCPUStackLimit.
           c. C Loop emulated stack code in JSStack will only use m_jsEmulatedStackLimit.
              Note: the part of JSStack that operates on a JIT build will use
                    m_jsCPUStackLimit as expected.
           d. LLINT assembly code will only use m_llintStackLimit.

        This patch only contains the above refactoring changes.  There is no behavior
        change.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        * interpreter/JSStack.h:
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::ensureCapacityFor):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        (JSC::JSStack::setJSEmulatedStackLimit):
        (JSC::JSStack::setStackLimit): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::updateStackLimit):
        * runtime/VM.h:
        (JSC::VM::reservedZoneSize):
        (JSC::VM::jsCPUStackLimit):
        (JSC::VM::addressOfJSCPUStackLimit):
        (JSC::VM::jsEmulatedStackLimit):
        (JSC::VM::setJSEmulatedStackLimit):
        (JSC::VM::isSafeToRecurse):
        (JSC::VM::jsStackLimit): Deleted.
        (JSC::VM::setJSStackLimit): Deleted.
        (JSC::VM::stackLimit): Deleted.
        (JSC::VM::addressOfStackLimit): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):

2016-07-05  Saam Barati  <sbarati@apple.com>

        StackVisitor::unwindToMachineCodeBlockFrame() may unwind past a VM entry frame when catching an exception and the frame has inlined tail calls
        https://bugs.webkit.org/show_bug.cgi?id=159448
        <rdar://problem/27084459>

        Reviewed by Mark Lam.

        Consider the following stack trace:
        (machine) foo -> VM entry frame -> (machine) bar -> (inlined tailcall) baz

        If an exception is thrown at 'baz', we will do exception unwinding,
        which will eventually call unwindToMachineCodeBlockFrame() which will call
        gotoNextFrame() on the 'baz' frame. The next logical frame for 'baz' is 'foo' because
        'bar' tail called 'baz' even though there is a machine frame for 'bar' on the stack.
        This is a bug. unwindToMachineCodeBlockFrame() should not care about the next
        logical frame, it just wants to move StackVisitor's state to the current machine
        frame. The bug here is that we would end up unwinding past the VM entry frame
        which can have all kinds of terrible consequences.

        This bug fixes unwindToMachineCodeBlockFrame() by having it not rely
        on gotoNextFrame() and instead using its own mechanism for setting
        the StackVisotor's state to the current machine frame.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
        * tests/stress/dont-unwind-past-vm-entry-frame.js: Added.
        (let.p.new.Proxy):
        (let.p.new.Proxy.apply):
        (bar):
        (let.good):
        (getItem):
        (start):

2016-07-05  Joseph Pecoraro  <pecoraro@apple.com>

        RELEASE_ASSERT(!thisObject) in ObjCCallbackFunctionImpl::call when calling JSExport ObjC Constructor without operator new
        https://bugs.webkit.org/show_bug.cgi?id=159446

        Reviewed by Mark Lam.

        Treat ObjC JSExport init constructors like ES6 Class Constructors
        and throw a TypeError when called without 'new'.

        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunctionImpl::type):
        (JSC::objCCallbackFunctionCallAsFunction):
        When calling an init method as a function instead of construction
        throw a TypeError.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        Improve error message.

        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):
        Test we get an exception when calling an ObjC constructor without 'new'.

2016-07-05  Mark Lam  <mark.lam@apple.com>

        Remove some unneeded #include "CachedCall.h".
        https://bugs.webkit.org/show_bug.cgi?id=159449

        Reviewed by Saam Barati.

        * runtime/ArrayPrototype.cpp:
        * runtime/JSArray.cpp:
        * runtime/MapPrototype.cpp:
        * runtime/SetPrototype.cpp:

2016-07-05  Geoffrey Garen  <ggaren@apple.com>

        Crash @ bankofamerica.com, University of Vienna
        https://bugs.webkit.org/show_bug.cgi?id=159439

        Reviewed by Saam Barati.

        * ftl/FTLLink.cpp:
        (JSC::FTL::link): Do check for stack overflow in the arity mismatch thunk
        because it can happen. Don't store a CallSiteIndex because we haven't
        stored a CodeBlock yet, and our stack frame is not fully constructed,
        so it would be an error for any client to try to load this value (and
        operationCallArityCheck does not load this value).

        * tests/stress/arity-check-ftl-throw.js: Added. New test case for stressing
        a stack overflow with arity mismatch. Sadly, after hours of fiddling, I
        can't seem to get this to fail in trunk. Still, it's good to have some
        more testing in this area.

2016-07-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] The prototype cycle checks throws the wrong error type
        https://bugs.webkit.org/show_bug.cgi?id=159393

        Reviewed by Geoffrey Garen.

        We were supposed to throw the TypeError:
        -https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__

        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeWithCycleCheck):

2016-07-05  Saam Barati  <sbarati@apple.com>

        our parsing for "use strict" is wrong when we first parse other directives that are not "use strict" but are located in a place where "use strict" would be valid
        https://bugs.webkit.org/show_bug.cgi?id=159376
        <rdar://problem/27108773>

        Reviewed by Benjamin Poulain.

        Our strict mode detection algorithm used to break if we ever saw a directive
        that is not "use strict" but is syntactically located in a location where our
        parser looks for "use strict". It broke as follows:

        If a function started with a non "use strict" string literal, we will allow
        "use strict" to be in any arbitrary statement inside the top level block in
        the function body. For example, this meant that if we parsed a sequence of string
        literals, followed by arbitrary statements, followed by "use strict", we would parse
        the function as if it's in strict mode. This is the wrong behavior with respect to
        the spec. This has consequences in other ways that break invariants of the language.
        For example, we used to allow functions that are lexically nested inside what we deemed
        a strict function to be non-strict. This used to fire an assertion if we ever skipped over
        that function using the source provider cache, but it worked just fine in release builds.

        This patch fixes this bug.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseStatement):
        * tests/stress/ensure-proper-strict-mode-parsing.js: Added.
        (foo.bar):
        (foo):
        (bar.foo):
        (bar):
        (bar.call.undefined.this.throw.new.Error.string_appeared_here.baz):
        (baz.call.undefined.undefined.throw.new.Error.string_appeared_here.jaz):
        (jaz.call.undefined.this.throw.new.Error.string_appeared_here.vaz):

2016-07-05  Saam Barati  <sbarati@apple.com>

        reportAbandonedObjectGraph should report abandoned bytes based on capacity() so it works even if a GC has never happened
        https://bugs.webkit.org/show_bug.cgi?id=159222
        <rdar://problem/27001991>

        Reviewed by Geoffrey Garen.

        When reportAbandonedObjectGraph() was called before the first GC, it used to
        not indicate to the GC timers that we have memory that needs to be collected
        because the calculation was based on m_sizeAfterLastCollect (which was zero).
        This patch makes the calculation based on capacity() which is a valid number
        even before the first GC.

        * heap/Heap.cpp:
        (JSC::Heap::reportAbandonedObjectGraph):
        (JSC::Heap::protect):
        (JSC::Heap::didAbandon): Deleted.
        * heap/Heap.h:
        (JSC::Heap::jitStubRoutines):

2016-07-05  Csaba Osztrogonác  <ossy@webkit.org>

        Typo fix after r202214
        https://bugs.webkit.org/show_bug.cgi?id=159416

        Reviewed by Saam Barati.

        * bytecode/InlineAccess.h:

2016-07-03  Per Arne Vollan  <pvollan@apple.com>

        [Win] DLLs are missing version information.
        https://bugs.webkit.org/show_bug.cgi?id=159349

        Reviewed by Brent Fulgham.

        Run perl version stamp utility.
        
        * CMakeLists.txt:

2016-07-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] MacroAssemblerX86::branch8 should accept unsigned 8bit value
        https://bugs.webkit.org/show_bug.cgi?id=159334

        Reviewed by Benjamin Poulain.

        As described in branchTest8 functions, byte in TrustedImm32 is not well defined.
        So the assertion here should be a little permissive; accepting -128 to 255.

        This assertion is originally fired when executing misc-bugs-847389-jpeg2000 benchmark in Debug build.
        So this patch includes misc-bugs-847389-jpeg2000 benchmark.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchTest8):
        (JSC::MacroAssemblerX86Common::branch8):
        * b3/testb3.cpp:
        (JSC::B3::testBranch8WithLoad8ZIndex):
        (JSC::B3::run):

2016-07-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] __lookupGetter__ and __lookupSetter__ should not ignore exceptions
        https://bugs.webkit.org/show_bug.cgi?id=159390

        Reviewed by Mark Lam.

        See:
        -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupGetter__
        -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupSetter__

        They are both supposed to be regular [[GetOwnProperty]].

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):

2016-07-03  Saam Barati  <sbarati@apple.com>

        BytecodeGenerator::getVariablesUnderTDZ is too conservative
        https://bugs.webkit.org/show_bug.cgi?id=159387

        Reviewed by Filip Pizlo.

        We were too conservative in the following type of programs:
        ```
        {
            {
                let x;
                ...
            }
            let x;
        }
        ```
        We used to report "x" as under TDZ when calling getVariablesUnderTDZ at the
        "...", even though "x" is not under TDZ. This patch removes this conservatism
        and makes the algorithm precise.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        * bytecompiler/BytecodeGenerator.h:

2016-07-03  Filip Pizlo  <fpizlo@apple.com>

        FTL should refer to B3 types directly
        https://bugs.webkit.org/show_bug.cgi?id=159389

        Reviewed by Saam Barati.
        
        When we used LLVM, types were objects that were allocated by the LLVMContext. We had to
        remember pointers to them or else call through the C API every time we wanted the type. We
        stored the type pointers inside FTL::CommonValues.
        
        But in B3, types are just members of an enum. We don't have to remember pointers to them.
        
        This change replaces all prior uses of things like "m_out.int32" with just "Int32", and
        likewise for m_out.boolean, m_out.int64, m_out.intPtr, m_out.floatType, m_out.doubleType,
        and m_out.voidType.
        
        We still use FTL::CommonValues for common constants that we have pre-hoisted. Hopefully we
        will come up with a better story for those eventually, since that's still kinda ugly.

        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::createPhiVariables):
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorById):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutGetterSetterById):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateScopedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsString):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckTypeInfoFlags):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
        (JSC::FTL::DFG::LowerDFGToB3::compileCountExecution):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumerableLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
        (JSC::FTL::DFG::LowerDFGToB3::compileToIndexString):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
        (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
        (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTruthyObject):
        (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
        (JSC::FTL::DFG::LowerDFGToB3::buildSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt52):
        (JSC::FTL::DFG::LowerDFGToB3::unboxInt32):
        (JSC::FTL::DFG::LowerDFGToB3::boxInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc):
        (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
        (JSC::FTL::DFG::LowerDFGToB3::boxDouble):
        (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::callCheck):
        (JSC::FTL::DFG::LowerDFGToB3::crash):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::bitCast):

2016-07-02  Filip Pizlo  <fpizlo@apple.com>

        DFG LICM needs to go all-in on the idea that some loops can't be LICMed
        https://bugs.webkit.org/show_bug.cgi?id=159388

        Reviewed by Mark Lam.
        
        Some time ago I acknowledged that LICM required loops to meet certain requirements that
        may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK.
        It used to be that we just ignored that requirement and would hoist anyway, but since
        r189126 we've stopped hoisting out of loops that don't have ExitOK.  We also added tests
        for the case that the pre-header doesn't exist or is invalid.

        It turns out that this patch didn't go far enough: even though it made LICM avoid loops
        that had an invalid pre-header, the part that updated the AI state in nested loops still
        assumed that these loops had valid pre-headers.  We would crash in null dereference in
        that loop if a nested loop had an invalid pre-header.

        The fix is simple: don't update the AI state of nested loops that don't have pre-headers,
        since we won't try to hoist out of those loops anyway.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix.
        (foo):
        * tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway.
        (foo):
        (valueOf):

2016-06-30  Filip Pizlo  <fpizlo@apple.com>

        Scopes that are not under TDZ should still push their variables onto the TDZ stack so that lifting TDZ doesn't bypass that scope
        https://bugs.webkit.org/show_bug.cgi?id=159332
        rdar://problem/27018958

        Reviewed by Saam Barati.
        
        This fixes an instacrash in this code:
        
            try{}catch(e){}print(e);let e;
        
        We lift TDZ for "e" in "catch (e){}", but since that scope doesn't push anything onto the
        TDZ stack, we lift TDZ from "let e".
        
        The problem is that we weren't tracking the set of variables that do not have TDZ. We need
        to track them to "block" the traversal that lifts TDZ. This change fixes this issue by
        using a map that tracks all known variables, and tells you if they are under TDZ or not.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numParameters):
        * bytecode/CodeOrigin.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::Variable::dump):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::popLexicalScope):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::needsTDZCheck):
        (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
        (JSC::BytecodeGenerator::pushTDZVariables):
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        (JSC::BytecodeGenerator::endGenerator):
        (WTF::printInternal):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::Variable::isConst):
        (JSC::Variable::setIsReadOnly):
        * interpreter/CallFrame.h:
        (JSC::ExecState::topOfFrame):
        * tests/stress/lift-tdz-bypass-catch.js: Added.
        (foo):
        (catch):

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] RegExp.compile is not returning the regexp when it succeed
        https://bugs.webkit.org/show_bug.cgi?id=159381

        Reviewed by Mark Lam.

        Spec:
        -https://tc39.github.io/ecma262/#sec-regexp.prototype.compile
        -https://tc39.github.io/ecma262/#sec-regexpinitialize

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):

2016-07-01  Saam Barati  <sbarati@apple.com>

        fix "ASSERTION FAILED: currentOffset() >= currentLineStartOffset()"
        https://bugs.webkit.org/show_bug.cgi?id=158572
        <rdar://problem/26884092>

        Reviewed by Mark Lam.

        There is a bug in our lexer when we notice the pattern:
        ```<return|continue|break|...etc> // some comment here```
        Our code will say that the token for the comment is a semicolon.
        This is the correct semantics, however, it would give the semicolon
        a start offset of the comment, but it will give its line start offset
        the newline after the comment.  This breaks the invariant in the lexer/parser
        that the offset for the current line starting point must be less than or equal to
        than the start offset of any token on that line. This invariant was broken because
        the line start offset was greater than the token start offset. To maintain this
        invariant, we claim that the semicolon token is located where the comment starts,
        and that its line start offset is the line start offset for the line with the
        comment on it.  There are other solutions that maintain this invariant, but this
        solution provides the best error messages.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Parser.h:
        (JSC::Parser::internalSaveLexerState):
        * tests/stress/obscure-error-message-dont-crash.js: Added.
        (try.eval.or.catch):

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        __defineGetter__/__defineSetter__ should throw exceptions
        https://bugs.webkit.org/show_bug.cgi?id=142934

        Reviewed by Mark Lam.

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

2016-07-01  Jon Davis  <jond@apple.com>

        Moved Web Animations and Resource Timing feature entries to WebCore.
        https://bugs.webkit.org/show_bug.cgi?id=159356

        Reviewed by Timothy Hatcher.

        * features.json:

2016-07-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Date.toGMTString should be the Date.toUTCString function
        https://bugs.webkit.org/show_bug.cgi?id=159318

        Reviewed by Mark Lam.

        See https://tc39.github.io/ecma262/#sec-date.prototype.togmtstring

        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToGMTString): Deleted.

2016-07-01  Mark Lam  <mark.lam@apple.com>

        Update JSC_functionOverrides to handle the new SourceCode strings that have params.
        https://bugs.webkit.org/show_bug.cgi?id=159321

        Reviewed by Geoffrey Garen.

        And add tests so that this won't fail silently and bit rot anymore.

        * API/tests/FunctionOverridesTest.cpp: Added.
        (testFunctionOverrides):
        * API/tests/FunctionOverridesTest.h: Added.
        * API/tests/testapi-function-overrides.js: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * shell/PlatformWin.cmake:
        * tools/FunctionOverrides.cpp:
        (JSC::FunctionOverrides::FunctionOverrides):
        (JSC::FunctionOverrides::reinstallOverrides):
        (JSC::initializeOverrideInfo):
        (JSC::FunctionOverrides::initializeOverrideFor):
        * tools/FunctionOverrides.h:
        (JSC::FunctionOverrides::clear):

2016-07-01  Caio Lima  <ticaiolima@gmail.com>

        ES6: Implement HasRestrictedGlobalProperty when checking for global lexical tier conflicts
        https://bugs.webkit.org/show_bug.cgi?id=148763

        Reviewed by Saam Barati

        I've implemented the ES6 spec 8.1.1.4.14
        (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasrestrictedglobalproperty)
        that defines when a global property can be shadowed.

        Added some test cases into global-lexical-redeclare-variable.js

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * tests/stress/global-lexical-redeclare-variable.js:
        (catch):
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/eighth.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/nineth.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/seventh.js: Added.
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js:
        * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/tenth.js: Added.

2016-07-01  Youenn Fablet  <youennf@gmail.com>

        Add a runtime flag for DOM iterators
        https://bugs.webkit.org/show_bug.cgi?id=159300

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h:

2016-06-30  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Wrong function name next to scope
        https://bugs.webkit.org/show_bug.cgi?id=158210
        <rdar://problem/26543093>

        Reviewed by Timothy Hatcher.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add DebuggerLocation. A helper for describing a unique location.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantRegisters):
        When compiled with debug info, add a SymbolTable rare data pointer
        back to the CodeBlock. This will be used later to get JSScope debug
        info if Web Inspector pauses.

        * runtime/SymbolTable.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::globalTypeSetForVariable):
        Rename rareData and include a CodeBlock pointer.

        (JSC::SymbolTable::rareDataCodeBlock):
        (JSC::SymbolTable::setRareDataCodeBlock):
        Setter and getter for the rare data. It should only be set once.

        (JSC::SymbolTable::visitChildren):
        Visit the rare data code block if we have one.

        * runtime/JSSymbolTableObject.h:
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::deleteProperty):
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        Give JSSymbolTable its own class info. JSWithScope was unexpectedly
        inheriting from JSSymbolTable since it did not have its own and
        was using JSScope's class info. Also do a bit of cleanup.

        * debugger/DebuggerLocation.cpp: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        * debugger/DebuggerLocation.h: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        Construction from a ScriptExecutable.

        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * debugger/DebuggerScope.h:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        Name and location for a scope. This uses:
        JSScope -> SymbolTable -> CodeBlock -> Executable

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
        (InjectedScript.CallFrameProxy._createScopeJson):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeType):
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
        Simplify this code to build the objects we will send across the protocol
        to descript a Scope.

2016-06-30  Saam Barati  <sbarati@apple.com>

        missing exception checks in arrayProtoFuncReverse
        https://bugs.webkit.org/show_bug.cgi?id=159319
        <rdar://problem/27083696>

        Reviewed by Filip Pizlo.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncReverse):

2016-06-30  Saam Barati  <sbarati@apple.com>

        get_by_id_with_this does not trigger a to_this in caller.
        https://bugs.webkit.org/show_bug.cgi?id=159226

        Reviewed by Keith Miller.

        This is a bug if the caller is in sloppy mode and the callee is in strict
        mode. This can't happen with ES6 classes because they're all in strict mode,
        but it can happen with method syntax on an object literal. The caller must
        to_this on |this| when it knows that it performs super property accesses.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/super-property-access-object-literal-to-this-2.js: Added.
        (assert):
        (test):
        (let.o1.get foo):
        (let.o2.a):
        (let.o2.aa):
        * tests/stress/super-property-access-object-literal-to-this.js: Added.
        (assert):
        (test):
        (let.o1.get foo):
        (let.o2.a):
        (let.o2.aa):
        (let.o2.b):
        (let.o2.bb):
        * tests/stress/super-property-access-to-this.js: Added.
        (assert):
        (test):
        (Base.prototype.get foo):
        (Base):
        (Child.prototype.a):
        (Child.prototype.b):
        (Child):

2016-06-30  Saam Barati  <sbarati@apple.com>

        We need to to_this when an inner arrow function uses 'this'
        https://bugs.webkit.org/show_bug.cgi?id=159290
        <rdar://problem/27058322>

        Reviewed by Geoffrey Garen.

        We put the |this| value into the closure object when there
        is an arrow function that uses |this|. However, an arrow function
        using |this| wasn't causing the creator of the closure that
        holds |this| to to_this its value before putting it in the
        closure. That's a huge bug because it means some arrow functions
        can capture the raw |this| value, which might be a JSLexicalEnvironment.
        This patch fixes this by adding an easy to check to see if any
        inner arrow functions use |this|, and if any do, it will to_this
        the |this| value.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/to-this-before-arrow-function-closes-over-this-that-starts-as-lexical-environment.js: Added.
        (assert):
        (obj):
        (foo.capture):
        (foo.wrapper.let.x.):
        (foo2.capture):
        (foo2.wrapper.let.x.):
        (foo2.wrapper.bar):

2016-06-29  Filip Pizlo  <fpizlo@apple.com>

        Generators violate bytecode liveness validation
        https://bugs.webkit.org/show_bug.cgi?id=159279

        Reviewed by Yusuke Suzuki.
        
        Fix a liveness bug found by Basic. The problem is that resume's intended liveness rule is:
        "live-in is just the token argument", but the liveness analysis thought that the rule was
        "live-in is live-out minus defs plus live-at-catch". Clearly these two rules are quite
        different. The way this sort of worked before is that we would define the defs of resume
        as being equal to our prediction of what the live-outs would be. We did this in the hope
        that we would subtract all live-outs. But, this misses the live-at-catch part. So, this
        change adds another hack to neutralize live-at-catch.
        
        This would make a lot more sense if we wrote a new liveness analysis that was just for
        generator conversion. It could reuse BytecodeUseDef but otherwise it would be a new thing.
        It would be easy to write crazy rules for save/resume in such an analysis, especially if
        that analysis rewrote the bytecode. We could then just have an op_yield that is a no-op.
        We would just record the live-outs of op_yield and use that for rewriting the code in terms
        of a switch statement.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):

2016-06-30  Commit Queue  <commit-queue@webkit.org>

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

        The test for this change times out on mac-wk2 debug and caused
        an existing test to crash. (Requested by ryanhaddad on
        #webkit).

        Reverted changeset:

        "Web Inspector: Wrong function name next to scope"
        https://bugs.webkit.org/show_bug.cgi?id=158210
        http://trac.webkit.org/changeset/202659

2016-06-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Date.setYear() misses timeClip()
        https://bugs.webkit.org/show_bug.cgi?id=159289

        Reviewed by Geoffrey Garen.

        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncSetYear):

2016-06-30  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
        https://bugs.webkit.org/show_bug.cgi?id=154022

        Reviewed by Filip Pizlo.

        We aim at optimizing @toInteger operation.
        While it still has an unoptimized part[1], this patch should be a first step.

        We introduce the @toNumber builtin intrinsic operation.
        This converts the given value to the JS number by emitting op_to_number bytecode.
        Previously @toInteger called C++ @Number constructor for that purpose.

        And in DFG, op_to_number is converted to DFG ToNumber node.
        During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
        we just fall back to calling the C++ function.

        To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
        to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.

        Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
        But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.

        By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.

        ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
        This value profiling is provided from either NumberConstructor's call operation or op_to_number.

        The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
        And ASMBench/n-body.c also shows stable ~2% progression.

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

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/GlobalObject.js:
        (globalPrivate.isFinite):
        (globalPrivate.isNaN):
        (globalPrivate.toInteger): Deleted.
        (globalPrivate.toLength): Deleted.
        (globalPrivate.isDictionary): Deleted.
        (globalPrivate.speciesGetter): Deleted.
        (globalPrivate.speciesConstructor): Deleted.
        * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
        (globalPrivate.toInteger):
        (globalPrivate.toLength):
        (globalPrivate.isDictionary):
        (globalPrivate.speciesGetter):
        (globalPrivate.speciesConstructor):
        * builtins/NumberConstructor.js: Added.
        (isFinite):
        (isNaN):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitUnaryOpProfiled):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
        (JSC::UnaryPlusNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
        According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToNumber):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Always on the heap prediction.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
        `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
        it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
        Currently, we allocate the additional temporary register for that scratch register.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
        This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
        we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
        the spills to call the operation. The example of the actually emitted code is the following.

        76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
            0x7f986d5fe693: test %rax, %r14
            0x7f986d5fe696: jz 0x7f986d5fe6a1
            0x7f986d5fe69c: jmp 0x7f986d5fe6d1
            0x7f986d5fe6a1: mov %rax, %rsi
            0x7f986d5fe6a4: mov %rbp, %rdi
            0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
            0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
            0x7f986d5fe6b8: call *%r11
            0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
            0x7f986d5fe6c5: mov (%r11), %r11
            0x7f986d5fe6c8: test %r11, %r11
            0x7f986d5fe6cb: jnz 0x7f986d5fe88c

        It effectively removes the unnecessary spill to call the operation!

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::UnaryOpNode::opcodeID):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncIsNaN): Deleted.
        (JSC::globalFuncIsFinite): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        (JSC::numberConstructorFuncIsFinite): Deleted.
        (JSC::numberConstructorFuncIsNaN): Deleted.
        * runtime/NumberConstructor.h:
        * tests/stress/Number-isNaN-basics.js: Added.
        (numberIsNaNOnInteger):
        (testNumberIsNaNOnIntegers):
        (verifyNumberIsNaNOnIntegerWithOtherTypes):
        (numberIsNaNOnDouble):
        (testNumberIsNaNOnDoubles):
        (verifyNumberIsNaNOnDoublesWithOtherTypes):
        (numberIsNaNNoArguments):
        (numberIsNaNTooManyArguments):
        (testNumberIsNaNOnConstants):
        (numberIsNaNStructTransition):
        (Number.isNaN):
        * tests/stress/global-is-finite.js: Added.
        (shouldBe):
        * tests/stress/global-is-nan.js: Added.
        (shouldBe):
        * tests/stress/global-isNaN-basics.js: Added.
        (isNaNOnInteger):
        (testIsNaNOnIntegers):
        (verifyIsNaNOnIntegerWithOtherTypes):
        (isNaNOnDouble):
        (testIsNaNOnDoubles):
        (verifyIsNaNOnDoublesWithOtherTypes):
        (verifyIsNaNOnCoercedTypes):
        (isNaNNoArguments):
        (isNaNTooManyArguments):
        (testIsNaNOnConstants):
        (isNaNTypeCoercionSideEffects):
        (i.value.isNaNTypeCoercionSideEffects.valueOf):
        (isNaNStructTransition):
        (isNaN):
        * tests/stress/number-is-finite.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/number-is-nan.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/to-number-basics.js: Added.
        (shouldBe):
        * tests/stress/to-number-convert-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-intrinsic-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object.js: Added.
        (shouldBe):
        (test12):
        (object1.valueOf):
        (test2):
        (test22):
        (object2.valueOf):
        (test3):
        (test32):
        (object3.valueOf):
        * tests/stress/to-number-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):

2016-06-29  Benjamin Poulain  <benjamin@webkit.org>

        Fix the debug build after r202667

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        The putDirect was missing the Accessor flag for the GetterSetter.

2016-06-29  Michael Saboff  <msaboff@apple.com>

        REGRESSION(200114): Netflix app does not see ChromeCast
        https://bugs.webkit.org/show_bug.cgi?id=159287

        Reviewed by Benjamin Poulain.

        Change set 200114 changed the behavior of how we check for whether or not we
        wrap Objective C init methods in JavaScript constructors.  The prior method
        checked the version of JavaScriptCore that was linked with the application.
        If the application was not directly linked with JavaScriptCore the prior
        method indicated that we shouldn't create constructors.  The new method uses
        the SDK the application was compiled with.  Using the new method, an
        application compiled with iOS SDK 8.0 or greater would create constructors
        and not export init methods to JavaScript.  The problem is that an existing
        application that hasn't been recompiled will get a different answer using
        the new method.  We need to come up with a method that works in a compatible
        way with existing programs, but provides a newly compiled program with the
        "is built with SDK N or greater" check.
        
        Added back the prior check of the version of JavaScriptCore the program was
        directly linked against.  However we only use this check if we directly linked
        with JavaScriptCore.  Otherwise we fall through to check against the SDK the
        program was built with.  Changed the iOS SDK version we check
        against to be the new version of iOS, iOS 10.

        This provides compatible behavior for existing programs.  It may be the case
        that some of those programs may require changes when they are rebuilt with the
        iOS 10 SDK or later.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):

2016-06-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Minor TypedArray fixes
        https://bugs.webkit.org/show_bug.cgi?id=159286

        Reviewed by Keith Miller.

        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        See https://tc39.github.io/ecma262/#sec-%typedarray%

        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncLength):
        See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length

        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        Yep, that's odd.
        See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype-@@tostringtag

        (JSC::JSTypedArrayViewPrototype::finishCreation):
        See the last paragraph of https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: API View of Native DOM APIs looks poor (TypeErrors for native getters)
        https://bugs.webkit.org/show_bug.cgi?id=158334
        <rdar://problem/26615366>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._getProperties):
        (InjectedScript.prototype._propertyDescriptors):
        Do not create fake value property descriptors for native accessors
        unless requested. This means, getProperties for a native prototype
        should return  accessors for native accessors just like it does
        for normal non-native accessors (getters/setters).

        (InjectedScript.prototype.getProperties):
        Do not produce fake value accessors for native accessors.

        (InjectedScript.prototype.getDisplayableProperties):
        (InjectedScript.RemoteObject.prototype._generatePreview):
        Do produce fake value accessors for native accessors.

2016-06-29  Saam barati  <sbarati@apple.com>

        JSGlobalLexicalEnvironment needs a toThis implementation
        https://bugs.webkit.org/show_bug.cgi?id=159285

        Reviewed by Mark Lam.

        This was a huge oversight of my original implementation. It gave users
        of the language direct access to the JSGlobalLexicalEnvironment object.

        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::isConstVariable):
        (JSC::JSGlobalLexicalEnvironment::toThis):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::isEmpty):
        * tests/stress/global-lexical-environment-to-this.js: Added.
        (assert):
        (let.f):
        (let.fStrict):

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Wrong function name next to scope
        https://bugs.webkit.org/show_bug.cgi?id=158210
        <rdar://problem/26543093>

        Reviewed by Brian Burg.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add DebuggerLocation. A helper for describing a unique location.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantRegisters):
        When compiled with debug info, add a SymbolTable rare data pointer
        back to the CodeBlock. This will be used later to get JSScope debug
        info if Web Inspector pauses.

        * runtime/SymbolTable.h:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForVariable):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::globalTypeSetForVariable):
        Rename rareData and include a CodeBlock pointer.

        (JSC::SymbolTable::rareDataCodeBlock):
        (JSC::SymbolTable::setRareDataCodeBlock):
        Setter and getter for the rare data. It should only be set once.

        (JSC::SymbolTable::visitChildren):
        Visit the rare data code block if we have one.

        * debugger/DebuggerLocation.cpp: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        * debugger/DebuggerLocation.h: Added.
        (JSC::DebuggerLocation::DebuggerLocation):
        Construction from a ScriptExecutable.

        * runtime/JSScope.cpp:
        (JSC::JSScope::symbolTable):
        * runtime/JSScope.h:
        * debugger/DebuggerScope.h:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::name):
        (JSC::DebuggerScope::location):
        Name and location for a scope. This uses:
        JSScope -> SymbolTable -> CodeBlock -> Executable

        * inspector/protocol/Debugger.json:
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
        (InjectedScript.CallFrameProxy._createScopeJson):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::valueForScopeType):
        (Inspector::valueForScopeLocation):
        (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
        (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
        Simplify this code to build the objects we will send across the protocol
        to descript a Scope.

2016-06-29  Saam barati  <sbarati@apple.com>

        We don't emit TDZ checks for call_eval
        https://bugs.webkit.org/show_bug.cgi?id=159277
        <rdar://problem/27018801>

        Reviewed by Benjamin Poulain.

        This is a problem if you're trying to call a TDZ variable
        that is named 'eval'.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::EvalFunctionCallNode::emitBytecode):
        * tests/stress/variable-named-eval-under-tdz.js: Added.
        (shouldThrowTDZ):
        (test):
        (test.foo):
        (throw.new.Error):

2016-06-29  Mark Lam  <mark.lam@apple.com>

        Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option.
        https://bugs.webkit.org/show_bug.cgi?id=159274

        Reviewed by Keith Miller.

        * jsc.cpp:
        (main):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::finalizeStats):
        (JSC::LLInt::compareStats):
        (JSC::LLInt::Data::dumpStats):
        (JSC::LLInt::Data::ensureStats):
        (JSC::LLInt::Data::loadStats):
        (JSC::LLInt::Data::resetStats):
        (JSC::LLInt::Data::saveStats):
        * llint/LLIntData.h:
        (JSC::LLInt::Data::opcodeStats):
        * runtime/Options.cpp:
        (JSC::Options::isAvailable):
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:

2016-06-29  Saam barati  <sbarati@apple.com>

        Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs
        https://bugs.webkit.org/show_bug.cgi?id=159267

        Reviewed by Mark Lam.

        We were parsing something without checking if it had a syntax error.
        This is wrong for many reasons, but it could actually cause a crash
        in a debug build if you parsed particular programs.

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

2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Show Shadow Root type in DOM Tree
        https://bugs.webkit.org/show_bug.cgi?id=159236
        <rdar://problem/27068521>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/DOM.json:
        Include optional shadowRootType property for DOMNodes.

2016-06-29  Commit Queue  <commit-queue@webkit.org>

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

        patch is broken on arm (Requested by keith_miller on #webkit).

        Reverted changeset:

        "LLInt should support other types of prototype GetById
        caching."
        https://bugs.webkit.org/show_bug.cgi?id=158083
        http://trac.webkit.org/changeset/202627

2016-06-29  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix small issues of TypedArray prototype
        https://bugs.webkit.org/show_bug.cgi?id=159248

        Reviewed by Saam Barati.

        First, TypedArray's toString and Array's toString
        should be the same function.
        I moved the function to GlobalObject and each array type
        gets it as needed.

        Then TypedArray length was supposed to be configurable.
        I removed the "DontDelete" flag accordingly.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayProtoToStringFunction):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):

2016-06-29  Caio Lima  <ticaiolima@gmail.com>

        LLInt should support other types of prototype GetById caching.
        https://bugs.webkit.org/show_bug.cgi?id=158083

        Recently, we started supporting prototype load caching for get_by_id
        in the LLInt. This patch is expading the caching strategy to enable
        cache the prototype accessor and custom acessors.

        Similarly to the get_by_id_proto_load bytecode, we are adding new
        bytecodes called get_by_id_proto_accessor that uses the calculated
        offset of a object to call a getter function and get_by_id_proto_custom
        that stores the pointer to the custom function and call them directly
        from LowLevelInterpreter.

        Reviewed by Keith Miller

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-06-28  Commit Queue  <commit-queue@webkit.org>

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

        Caused all WKTR tests to fail on GuardMalloc and Production
        only for unknown reasons, investigating offline. (Requested by
        brrian on #webkit).

        Reverted changeset:

        "RunLoop::Timer should use constructor templates instead of
        class templates"
        https://bugs.webkit.org/show_bug.cgi?id=159153
        http://trac.webkit.org/changeset/202580

2016-06-28  Keith Miller  <keith_miller@apple.com>

        We should not crash there is a finally inside a for-in loop
        https://bugs.webkit.org/show_bug.cgi?id=159243
        <rdar://problem/27018910>

        Reviewed by Benjamin Poulain.

        Previously we would swap the m_forInContext with an empty vector
        then attempt to shrink the size of m_forInContext by the amount
        we expected. This meant that if there was more than one ForInContext
        on the stack and we wanted to pop exactly one off we would crash.
        This patch makes ForInContexts RefCounted so they can be duplicated
        into other vectors. It also has ForInContexts copy the entire stack
        rather than do the swap that we did before. This makes ForInContexts
        work the same as the other contexts.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::pushIndexedForInScope):
        (JSC::BytecodeGenerator::pushStructureForInScope):
        * bytecompiler/BytecodeGenerator.h:
        * tests/stress/finally-for-in.js: Added.
        (repeat):
        (createSimple):

2016-06-28  Saam Barati  <sbarati@apple.com>

        Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable
        https://bugs.webkit.org/show_bug.cgi?id=158796
        <rdar://problem/26984659>

        Reviewed by Michael Saboff.

        There was a bug where some functions inside of an eval were
        omitting a necessary TDZ check. This obviously leads to bad
        things because a variable under TDZ is the null pointer.
        The eval's bytecode was generated with the correct TDZ set, but 
        it created all its functions before pushing that TDZ set onto
        the stack. That's a mistake. Those functions need to be created with
        that TDZ set. The solution is simple, the TDZ set that the eval
        is created with needs to be pushed onto the TDZ stack before
        the eval creates any functions.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/variable-under-tdz-eval-tricky.js: Added.
        (assert):
        (throw.new.Error):
        (assert.try.underTDZ):

2016-06-28  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns
        https://bugs.webkit.org/show_bug.cgi?id=159233

        Reviewed by Mark Lam.

        Jump to fail exit code when the last alternative of a sticky pattern fails.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::backtrack):

2016-06-28  Saam Barati  <sbarati@apple.com>

        some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct
        https://bugs.webkit.org/show_bug.cgi?id=159198
        <rdar://problem/26302360>

        Reviewed by Filip Pizlo.

        Firing a watchpoint may cause a GC to happen. This GC could destroy various
        Watchpoints themselves while they're in the process of firing. It's not safe
        for most Watchpoints to be destructed while they're in the middle of firing.
        This GC could also destroy the WatchpointSet itself, and it's not in a safe
        state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a
        while. This prevents a GC from destructing any Watchpoints while they're
        in the process of firing. This bug was being hit by the stress GC bots
        because we would destruct a particular Watchpoint while it was firing,
        and then we would access its field after it had already been destroyed.
        This was causing all kinds of weird symptoms. Also, this was easier to
        catch when running with guard malloc because the first access after
        destruction would lead to a crash.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/VariableWriteFireDetail.cpp:
        (JSC::VariableWriteFireDetail::dump):
        (JSC::VariableWriteFireDetail::touch):
        * bytecode/VariableWriteFireDetail.h:
        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::add):
        (JSC::WatchpointSet::fireAllSlow):
        (JSC::WatchpointSet::fireAllWatchpoints):
        (JSC::InlineWatchpointSet::add):
        (JSC::InlineWatchpointSet::fireAll):
        (JSC::InlineWatchpointSet::inflateSlow):
        * bytecode/Watchpoint.h:
        (JSC::WatchpointSet::startWatching):
        (JSC::WatchpointSet::fireAll):
        (JSC::WatchpointSet::touch):
        (JSC::WatchpointSet::invalidate):
        (JSC::WatchpointSet::isBeingWatched):
        (JSC::WatchpointSet::offsetOfState):
        (JSC::WatchpointSet::addressOfSetIsNotEmpty):
        (JSC::InlineWatchpointSet::startWatching):
        (JSC::InlineWatchpointSet::fireAll):
        (JSC::InlineWatchpointSet::invalidate):
        (JSC::InlineWatchpointSet::touch):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (WTF::Masquerader::create):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ArrayBufferNeuteringWatchpoint.cpp:
        (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
        * runtime/FunctionRareData.cpp:
        (JSC::FunctionRareData::clear):
        * runtime/InferredType.cpp:
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
        * runtime/InferredValue.cpp:
        (JSC::InferredValue::notifyWriteSlow):
        (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
        * runtime/InferredValue.h:
        (JSC::InferredValue::notifyWrite):
        (JSC::InferredValue::invalidate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTablePutTouchWatchpointSet):
        (JSC::symbolTablePutInvalidateWatchpointSet):
        * runtime/Structure.cpp:
        (JSC::Structure::didCachePropertyReplacement):
        (JSC::Structure::startWatchingInternalProperties):
        (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire):
        (JSC::DeferredStructureTransitionWatchpointFire::add):
        (JSC::Structure::didTransitionFromThisStructure):
        (JSC::Structure::prototypeForLookup):
        * runtime/StructureInlines.h:
        (JSC::Structure::didReplaceProperty):
        (JSC::Structure::propertyReplacementWatchpointSet):
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::isDontEnum):
        (JSC::SymbolTableEntry::disableWatching):
        * runtime/VM.cpp:
        (JSC::VM::addImpureProperty):
        (JSC::enableProfilerWithRespectToCount):

2016-06-28  Filip Pizlo  <fpizlo@apple.com>

        JSRopeString should use release asserts, not debug asserts, about substring bounds
        https://bugs.webkit.org/show_bug.cgi?id=159227

        Reviewed by Saam Barati.
        
        According to my experiments this change costs nothing.  That's not surprising since the
        most common way to construct a rope these days is inlined into the JIT, which does its own
        safety checks.  This makes us crash sooner rather than corrupting memory.

        * runtime/JSString.h:

2016-06-28  Brian Burg  <bburg@apple.com>

        RunLoop::Timer should use constructor templates instead of class templates
        https://bugs.webkit.org/show_bug.cgi?id=159153

        Reviewed by Alex Christensen.

        Remove the RunLoop::Timer class template argument, and pass its constructor
        a reference to `this` instead of a pointer to `this`.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):

2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
        https://bugs.webkit.org/show_bug.cgi?id=159192

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.arrayIndexPropertyNames):
        Start with an empty array because we just push valid indexes.

        (InjectedScript.prototype._propertyDescriptors):
        Avoid the >100 length requirement, and always treat the
        array-like objects the same. The frontend currently
        doesn't show named indexes for arrays anyways, so they
        would have been unused.

2016-06-28  Per Arne Vollan  <pvollan@apple.com>

        [Win] Skip failing INTL test.
        https://bugs.webkit.org/show_bug.cgi?id=159141

        Reviewed by Brent Fulgham.

        INTL is not enabled on Windows.

        * tests/stress/intl-constructors-with-proxy.js:
        (shouldBe):

2016-06-28  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r202502 - 2
        https://bugs.webkit.org/show_bug.cgi?id=159194

        Reviewed by Gyuyoung Kim.

        Fix about the error message below.
        error: control reaches end of non-void function [-Werror=return-type]

        * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".

2016-06-28  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r202502
        https://bugs.webkit.org/show_bug.cgi?id=159194

        Reviewed by Alex Christensen.

        Fix about the error message below.
        error: control reaches end of non-void function [-Werror=return-type]

        * b3/B3TypeMap.h:
        (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Fix bad assert in StructureRareData::setObjectToStringValue
        https://bugs.webkit.org/show_bug.cgi?id=159171
        <rdar://problem/26987355>

        Reviewed by Mark Lam.

        We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
        There are many reasons it might fail including that there is a proxy somewhere on the
        prototype chain of the object.

        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::setObjectToStringValue):
        * tests/stress/object-toString-with-proxy.js: Added.
        (get target):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        Crashing at an unreachable code trap in FTL should give more information
        https://bugs.webkit.org/show_bug.cgi?id=159177

        Reviewed by Saam Barati.
        
        This stuffs information into registers so that we have some chance of seeing what happened
        by looking at the register dumps.

        * assembler/AbortReason.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::ftlUnreachable):
        (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
        (JSC::FTL::DFG::LowerDFGToB3::crash):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        Clean up resetting reachability in B3/Air
        https://bugs.webkit.org/show_bug.cgi?id=159170

        Reviewed by Geoffrey Garen.
        
        When I fixed bug 159165, I took the brute force approach. I still used the
        B3::resetReachability() method, and changed the callback to record the set of deleted values
        instead of deleting them eagerly. But this means tracking the set of deleted values, even
        though resetReachability() already internally tracks the set of deleted blocks. You can find
        out if a value is deleted by asking if its owning block was deleted.
        
        So, this change refactors B3::resetReachability() into a new helper called
        B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
        client delete blocks. This lets Air delete blocks the same way that it did before, and it
        lets B3 use the isBlockDead() method (which is a glorified proxy for
        block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
        Upsilons that point to dead Phis into Nops before deleting the blocks.
        
        This shouldn't affect performance or anything real. It just makes the code cleaner.

        * b3/B3BasicBlockUtils.h:
        (JSC::B3::updatePredecessorsAfter):
        (JSC::B3::recomputePredecessors):
        (JSC::B3::isBlockDead):
        (JSC::B3::resetReachability): Deleted.
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        (JSC::B3::Procedure::invalidateCFG):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):

2016-06-27  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Filip Pizlo.

        This change caused JSC stress tests to all hit an assertion in RunLoop.
        We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
        clients like testapi and jsc don't ever call initializeMainRunLoop().

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):

2016-06-27  Filip Pizlo  <fpizlo@apple.com>

        B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
        https://bugs.webkit.org/show_bug.cgi?id=159165

        Reviewed by Mark Lam.
        
        You can delete an unreachable block that has a Phi but some prior block may still have an
        Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
        exits or it can happen if we remove some successor of a block and this block had an Upsilon
        for one of the removed successors. These things are valid IR even if they are not canonical.
        Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
        in the end.
        
        The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.

        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability): Fix the bug.
        * b3/B3Validate.h:
        * b3/testb3.cpp:
        (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Add comment to Module feature in features.json
        https://bugs.webkit.org/show_bug.cgi?id=159159

        Reviewed by Saam Barati.

        * features.json:

2016-06-27  Keith Miller  <keith_miller@apple.com>

        Update features.json for ES6 completed features.
        https://bugs.webkit.org/show_bug.cgi?id=159152

        Reviewed by Mark Lam.

        * features.json:

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

        B3 should not use Nops when deleting unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=159120
        rdar://problem/26500743

        Reviewed by Michael Saboff.
        
        Prior to this change, transformations that obviated the need for some value could choose
        from these ways to kill it:
        
        - replaceWithIdentity() if we're replacing with another value.
        - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
          value.
        - deleteValue() if the code is unreachable.
        
        The bug here is that reduceStrength() was being clever about how to get rid of a value.
        reduceStrength() may find a Check that must always exit. The goal is to remove any code
        dominated by the Check. But it would be awkward to eagerly delete all of the blocks
        dominated by this one. So this code took a much simpler approach: it would
        replaceWithNop() for all of the values in this block after the Check and it would replace
        the terminal with Oops.
        
        But this corrupts the IR in a subtle way: some of those values may have been non-Void but
        now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
        dominated by the one with the Check are unreachable, so it will run all sorts of
        optimizations on those blocks. This could have probably manifested as many different kinds
        of badness, but the way I found out about this issue was through a crash in
        IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
        statement over a child's type.
        
        We could fix this by making rangeFor() tolerate Void. But I think that this would be
        dangerous. There could easily be other places in reduceStrength() that assume that value's
        children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
        prevent other optimizations from breaking the children-are-not-Void rule.
        
        This introduces two high-level changes:
        
        - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
          would cause reduceStrength() to instacrash in its Check optimization. Almost all other
          uses of replaceWithNop() were already following this rule, so they were fine. One other
          place was using replaceWithNop() on non-Void values after arranging for them to no
          longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
          doesn't have any type assertions.
        
        - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
          Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
          that the code is unreachable then it produces something that is guaranteed to be deleted
          by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
          to something harmless and cheap. This means replacing the value with an identity that
          points to a bottom constant (the 0 for whatever type we have), or just replacing it with
          Nop if it's Void.
        
        This also adds a test case for the reason why we do this: we may have two blocks, where
        the first block unconditionally exits while dominating the second block. The second block
        references values in the part of the first block that is unreachable. In trunk, this test
        would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
        reference a Nop in the first block.
        
        This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
        confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
        statement in IntRange::top(Type), clang was merging that trap with the trap it used for
        Vector OOB. The top of the stack in crash dumps looked like:
        
            JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
        
        Where Vector.h:655 is:
        
            OverflowHandler::overflowed();

        But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
        are both traps, so they got merged despite differences in debug info. This bug would have
        been so much easier to fix if I had the right line number.

        * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
        (JSC::B3::BottomProvider::BottomProvider):
        (JSC::B3::BottomProvider::operator()):
        * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
        (JSC::B3::InsertionSet::insertBottom):
        (JSC::B3::InsertionSet::execute):
        (JSC::B3::InsertionSet::bottomForType):
        * b3/B3InsertionSet.h:
        * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
        * b3/B3Procedure.h:
        * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
        * b3/B3ReduceStrength.h:
        * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::replaceWithNopIgnoringType):
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
        (JSC::B3::Value::as):
        * b3/testb3.cpp: Add new tests!
        (JSC::B3::testLateRegister):
        (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
        (JSC::B3::zero):
        (JSC::B3::run):

2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION: Web Inspector: Text search broken in resources with <CR>
        https://bugs.webkit.org/show_bug.cgi?id=159110
        <rdar://problem/27008485>

        Reviewed by Brian Burg.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::lineEndings):
        The frontend moved to only treated newlines as line endings in
        the TextEditor. The backend however was looking for many
        different types of line endings (\r\n, \r, \n). This caused
        the line endings to ultimately differ between the frontend
        and the backend, so the frontend couldn't find the lines that
        the backend was claiming search results were on. Change the
        backend to only look for \n line endings.

2016-06-27  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Timothy Hatcher.

        Move the asynchronous work to a task class that can be cancelled when the
        heap agent is reset, disabled or destroyed.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
        (Inspector::SendGarbageCollectionEventsTask::reset):
        (Inspector::SendGarbageCollectionEventsTask::timerFired):
        Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
        It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
        The data vector is guarded with a lock so that garbageCollected() can safely add
        collection data from a non-main thread while the main thread sends out events.

        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.

        (Inspector::InspectorHeapAgent::didGarbageCollect):
        Add the collection data to the task, which will dispatch an event for it asynchronously.

        * inspector/agents/InspectorHeapAgent.h:

2016-06-27  Michael Saboff  <msaboff@apple.com>

        ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
        https://bugs.webkit.org/show_bug.cgi?id=158505

        Reviewed by Geoffrey Garen.

        This change makes it so that the CharacterClassEscape \w matches the inverse of
        \W and vice versa for unicode, ignore case RegExp's.

        Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
        k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
        This was due to how the ES6 standard defined matching of character classes
        specifically that the abstract operation "Canonicalize()" is called for the
        character to be matched AND for the characters in the character class we are
        matching against.  This change is to make \W always be the inverse of \w.
        It is still the case that the characters that match against \w changes
        depending on a regular expression's flags.

        The only real changes occur for regular expressions with both the unicode and
        ignore case flags set.  Updated the character class generator to make 
        nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
        Changed BytecodePattern.wordcharCharacterClass to use the correct
        word character class for the flags.  Simplfied character class set up in
        in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
        invert as appropriate when unicode and ignore case are both set.

        * create_regex_tables:
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):

2016-06-25  Keith Miller  <keith_miller@apple.com>

        DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
        https://bugs.webkit.org/show_bug.cgi?id=159117
        <rdar://problem/26996781>

        Reviewed by Saam Barati.

        DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
        This is clearly not always the case and we should be able to handle it.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
        (let.foo.Object.test):

2016-06-24  Filip Pizlo  <fpizlo@apple.com>

        B3 should die sooner if a Value has the wrong number of children
        https://bugs.webkit.org/show_bug.cgi?id=159108

        Reviewed by Mark Lam.
        
        I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
        ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
        the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
        Clearly those should never go out-of-bounds.
        
        Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
        wrong number of children, and that path is not tested by any of our tests. This patch adds
        release assertions that will catch the latter.
        
        I've tested this a lot. It's not a regression on our benchmarks.

        * b3/B3Opcode.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::dumpMeta):
        (JSC::B3::Value::typeFor):
        (JSC::B3::Value::badOpcode):
        (JSC::B3::Value::checkOpcode): Deleted.
        * b3/B3Value.h:

2016-06-24  Mark Lam  <mark.lam@apple.com>

        [JSC] Error prototypes are called on remote scripts.
        https://bugs.webkit.org/show_bug.cgi?id=52192

        Reviewed by Keith Miller.

        Added a sanitizedToString() to the Error instance object so that it can be used
        to get an error string without invoking getters and proxies.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        (JSC::ErrorInstance::sanitizedToString):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::createStructure):
        (JSC::ErrorInstance::runtimeTypeForCause):
        (JSC::ErrorInstance::clearRuntimeTypeForCause):

2016-06-24  Commit Queue  <commit-queue@webkit.org>

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

        Introduced memory corruption crashes (Requested by ap on
        #webkit).

        Reverted changeset:

        "Web Inspector: CRASH in backend at
        Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
        closing frontend/inspected page"
        https://bugs.webkit.org/show_bug.cgi?id=159075
        http://trac.webkit.org/changeset/202443

2016-06-24  Brian Burg  <bburg@apple.com>

        Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
        https://bugs.webkit.org/show_bug.cgi?id=159075
        <rdar://problem/26094341>

        Reviewed by Joseph Pecoraro.

        Move the asynchronous work to a task class that can be cancelled when the
        heap agent is reset, disabled or destroyed.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
        (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
        (Inspector::SendGarbageCollectionEventsTask::reset):
        (Inspector::SendGarbageCollectionEventsTask::timerFired):
        Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
        It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.

        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::disable):
        Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.

        (Inspector::InspectorHeapAgent::didGarbageCollect):
        Send the object to the task to be dispatched asynchronously.

        * inspector/agents/InspectorHeapAgent.h:

2016-06-24  Commit Queue  <commit-queue@webkit.org>

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

        Broke many JSC tests (Requested by ap on #webkit).

        Reverted changeset:

        "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
        accept non number values"
        https://bugs.webkit.org/show_bug.cgi?id=154022
        http://trac.webkit.org/changeset/202413

2016-06-23  Benjamin Poulain  <bpoulain@apple.com>

        OOM Assertion failure in Array.prototype.toString
        https://bugs.webkit.org/show_bug.cgi?id=158793

        Reviewed by Saam Barati.

        JSString::create() taking a StringImpl was using a signed integer
        for the length of the string.
        The problem is StringImpl uses an unsigned integer. When a large string
        was passed to JSString, the signed integer would be negative and crash
        JSString.

        * runtime/JSString.h:
        (JSC::JSString::create):

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
        https://bugs.webkit.org/show_bug.cgi?id=154022

        Reviewed by Filip Pizlo.

        We aim at optimizing @toInteger operation.
        While it still has an unoptimized part[1], this patch should be a first step.

        We introduce the @toNumber builtin intrinsic operation.
        This converts the given value to the JS number by emitting op_to_number bytecode.
        Previously @toInteger called C++ @Number constructor for that purpose.

        And in DFG, op_to_number is converted to DFG ToNumber node.
        During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
        we just fall back to calling the C++ function.

        To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
        to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.

        Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
        But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.

        By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.

        ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
        This value profiling is provided from either NumberConstructor's call operation or op_to_number.

        The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
        And ASMBench/n-body.c also shows stable ~2% progression.

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

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/GlobalObject.js:
        (globalPrivate.isFinite):
        (globalPrivate.isNaN):
        (globalPrivate.toInteger): Deleted.
        (globalPrivate.toLength): Deleted.
        (globalPrivate.isDictionary): Deleted.
        (globalPrivate.speciesGetter): Deleted.
        (globalPrivate.speciesConstructor): Deleted.
        * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
        (globalPrivate.toInteger):
        (globalPrivate.toLength):
        (globalPrivate.isDictionary):
        (globalPrivate.speciesGetter):
        (globalPrivate.speciesConstructor):
        * builtins/NumberConstructor.js: Added.
        (isFinite):
        (isNaN):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitUnaryOpProfiled):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
        (JSC::UnaryPlusNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
        According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToNumber):
        ToNumber tells its predicted type by its heap prediction. So the fixup phase need to consider about it.
        If the heap prediction is Int32, we should attempt to convert the child value to Int32.
        Without this, misc-bugs-847389-jpeg2000 in assorted tests poses 53% regression.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        Alway rely on the heap prediction.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
        `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
        it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
        Currently, we allocate the additional temporary register for that scratch register.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
        This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
        we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
        the spills to call the operation. The example of the actually emitted code is the following.

        76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
            0x7f986d5fe693: test %rax, %r14
            0x7f986d5fe696: jz 0x7f986d5fe6a1
            0x7f986d5fe69c: jmp 0x7f986d5fe6d1
            0x7f986d5fe6a1: mov %rax, %rsi
            0x7f986d5fe6a4: mov %rbp, %rdi
            0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
            0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
            0x7f986d5fe6b8: call *%r11
            0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
            0x7f986d5fe6c5: mov (%r11), %r11
            0x7f986d5fe6c8: test %r11, %r11
            0x7f986d5fe6cb: jnz 0x7f986d5fe88c

        It effectively removes the unnecessary spill to call the operation!

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::UnaryOpNode::opcodeID):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncIsNaN): Deleted.
        (JSC::globalFuncIsFinite): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        (JSC::numberConstructorFuncIsFinite): Deleted.
        (JSC::numberConstructorFuncIsNaN): Deleted.
        * runtime/NumberConstructor.h:
        * tests/stress/Number-isNaN-basics.js: Added.
        (numberIsNaNOnInteger):
        (testNumberIsNaNOnIntegers):
        (verifyNumberIsNaNOnIntegerWithOtherTypes):
        (numberIsNaNOnDouble):
        (testNumberIsNaNOnDoubles):
        (verifyNumberIsNaNOnDoublesWithOtherTypes):
        (numberIsNaNNoArguments):
        (numberIsNaNTooManyArguments):
        (testNumberIsNaNOnConstants):
        (numberIsNaNStructTransition):
        (Number.isNaN):
        * tests/stress/global-is-finite.js: Added.
        (shouldBe):
        * tests/stress/global-is-nan.js: Added.
        (shouldBe):
        * tests/stress/global-isNaN-basics.js: Added.
        (isNaNOnInteger):
        (testIsNaNOnIntegers):
        (verifyIsNaNOnIntegerWithOtherTypes):
        (isNaNOnDouble):
        (testIsNaNOnDoubles):
        (verifyIsNaNOnDoublesWithOtherTypes):
        (verifyIsNaNOnCoercedTypes):
        (isNaNNoArguments):
        (isNaNTooManyArguments):
        (testIsNaNOnConstants):
        (isNaNTypeCoercionSideEffects):
        (i.value.isNaNTypeCoercionSideEffects.valueOf):
        (isNaNStructTransition):
        (isNaN):
        * tests/stress/number-is-finite.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/number-is-nan.js: Added.
        (shouldBe):
        (test2):
        (test3):
        * tests/stress/to-number-basics.js: Added.
        (shouldBe):
        * tests/stress/to-number-convert-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        (valueOf):
        * tests/stress/to-number-intrinsic-int52.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-intrinsic-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object-without-execution.js: Added.
        (shouldBe):
        (object.valueOf):
        * tests/stress/to-number-object.js: Added.
        (shouldBe):
        (test12):
        (object1.valueOf):
        (test2):
        (test22):
        (object2.valueOf):
        (test3):
        (test32):
        (object3.valueOf):
        * tests/stress/to-number-value-profiling.js: Added.
        (shouldBe):
        (object.valueOf):

2016-06-23  Saam Barati  <sbarati@apple.com>

        DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
        https://bugs.webkit.org/show_bug.cgi?id=159064
        <rdar://problem/26599119>

        Reviewed by Filip Pizlo.

        The DFG has a list of m_slowPathLambdas that are code generators it emits
        amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
        This caused us to use whatever Node happened to be used as the currentNode at the time
        we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
        frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
        the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
        a calleeRecovery that will not be in sync with the current stack state. Trying
        to recover that callee will often lead to a crash. The solution is to update
        m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.

        I found this bug because we were inside this bad state when calling an operation
        that happened to have a DeferGC. When this DeferGC actually GCed, it would
        take a StackTrace, which would lead to a crash because we were updating
        ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
        in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
        However, this CallSiteIndex didn't correspond to the actual state of execution
        of the program. I'm adding new options to make reproducing DeferGC related
        bugs easier by making DeferGC force a GC according to some probability. To
        always have DeferGC force a GC, you can set that probability to 1.

        There is a second bug that I discovered after solving the above bug. We were
        using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
        in the DFG. This would cause us to take a stack trace when the call frame was
        in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
        which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
        However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
        This would lead to a crash when taking a stack trace. The solution is to prevent
        stack traces from being taken when the program is in this state by using
        DeferGCForAWhie instead of DeferGC.

        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        * dfg/DFGSpeculativeJIT.h:
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC::Heap::collectAccordingToDeferGCProbability):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        (JSC::Heap::markListSet):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        * runtime/Options.h:
        * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
        (foo):
        (bar):

2016-06-23  Filip Pizlo  <fpizlo@apple.com>

        Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=158806

        Reviewed by Saam Barati.
        
        If we try to compile a CodeBlock that we already tried compiling in the past then we need
        to clean up the data structures that were partly filled in by the failed compile. That
        causes some races, since the DFG may be trying to parse those data structures while we are
        clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
        the races.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::getStubInfoMap):
        (JSC::CodeBlock::getCallLinkInfoMap):
        (JSC::CodeBlock::getByValInfoMap):
        (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
        (JSC::CodeBlock::resetJITData):
        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::setSteppingMode):
        (JSC::CodeBlock::addRareCaseProfile):
        (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::resultProfileForBytecodeOffset):
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::ensureResultProfile):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getFromAllValueProfiles):
        (JSC::CodeBlock::numberOfRareCaseProfiles):
        (JSC::CodeBlock::numberOfResultProfiles):
        (JSC::CodeBlock::numberOfArrayProfiles):
        (JSC::CodeBlock::arrayProfiles):
        (JSC::CodeBlock::addRareCaseProfile): Deleted.
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
        (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::compileNow):

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
        https://bugs.webkit.org/show_bug.cgi?id=158110
        <rdar://problem/26498584>

        Reviewed by Andreas Kling.

        * heap/Heap.cpp:
        (JSC::Heap::willStartCollection):
        (JSC::Heap::didFinishCollection):
        * heap/Heap.h:
        (JSC::Heap::externalMemorySize):
        * heap/HeapInlines.h:
        (JSC::Heap::reportExternalMemoryVisited):
        Keep count of external memory we visit.

        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExternalMemoryVisited):
        Report external memory visited like we do extra memory, since
        it will be some subset of extra memory that is external.

2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Snapshots should be cleared at some point
        https://bugs.webkit.org/show_bug.cgi?id=157907
        <rdar://problem/26373610>

        Reviewed by Timothy Hatcher.

        * heap/HeapSnapshotBuilder.h:
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
        Provide a way to reset the object identifier counter.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::clearHeapSnapshots):
        Make clearHeapSnapshots protected, so it can be called from a
        a PageHeapAgent on page navigations.

2016-06-22  Saam barati  <sbarati@apple.com>

        TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
        https://bugs.webkit.org/show_bug.cgi?id=159037
        <rdar://problem/26935349>

        Reviewed by Benjamin Poulain.

        The primary focus of this patch is to make the concurrent
        baseline JIT work with the type profiler. We were clearing
        the type profiler log on the background baseline compiler
        thread which lead to bad things happening. This patch fixes
        this by processing the log before we launch the compile on
        a background thread.

        Secondly, I audited the type profiler code inside the DFG,
        and found that we were doing some racy things. I haven't
        seen any crashes because of these things, but it is possible
        that they exist. We were grabbing a RefPtr to a TypeSet,
        even though TypeSet was RefCounted and not ThreadSafeRefCounted.
        This patch makes TypeSet ThreadSafeRefCounted. We were
        also copying a StructureSet while the execution thread could
        be augmenting the StructureSet. This patch puts changes to 
        TypeSet's StructureSet behind a ConcurrentJITLock.

        I've also added two more large running tests that run with the
        type profiler enabled. These are here just to catch any major bugs
        in the type profiler implementation.

        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        (JSC::JIT::doMainThreadPreparationBeforeCompile):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        (JSC::JIT::compile):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        (JSC::TypeSet::invalidateCache):
        * runtime/TypeSet.h:
        (JSC::TypeSet::create):
        (JSC::TypeSet::isEmpty):
        (JSC::TypeSet::seenTypes):
        (JSC::TypeSet::structureSet):
        * tests/typeProfiler/deltablue-for-of.js: Added.
        * tests/typeProfiler/getter-richards.js: Added.

2016-06-22  Keith Miller  <keith_miller@apple.com>

        We should have a DFG intrinsic that checks if a value is a TypedArrayView
        https://bugs.webkit.org/show_bug.cgi?id=159048

        Reviewed by Saam Barati.

        This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
        The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
        DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
        These changes are needed to fix regressions in %TypedArray%.prototype.subarray.

        * builtins/BuiltinNames.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
        (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
        * runtime/Intrinsic.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
        * runtime/JSTypedArrayViewPrototype.h:
        * tests/stress/istypedarrayview-intrinsic.js: Added.
        (makeFn):
        (typedArrays.forEach):
        (let.test):
        (test):

2016-06-21  Anders Carlsson  <andersca@apple.com>

        Fix build.

        * Configurations/FeatureDefines.xcconfig:

2016-06-21  Geoffrey Garen  <ggaren@apple.com>

        Options::useImmortalObjects is not safe for conservative GC
        https://bugs.webkit.org/show_bug.cgi?id=158999

        Reviewed by Geoffrey Garen.

        useImmortalObjects set the mark bit to keep an object from being
        reallocated. This had the negative side-effect of convincing the
        conservative marker that the object was a valid and live cell, which
        would cause us to visit garbage.

        * heap/Heap.cpp:
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Heap::setFullActivityCallback):
        (JSC::Heap::markDeadObjects): Deleted.
        * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
        a conservative GC.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::retire): New helper.

        (JSC::MarkedAllocator::reset): Automatically retire old blocks when
        we're doing the immortal objects thing. This has the effect of
        preserving memory for debugging because we never recycle a previously
        allocated block.

2016-06-21  Anders Carlsson  <andersca@apple.com>

        Begin moving the Apple Pay code to the open source repository
        https://bugs.webkit.org/show_bug.cgi?id=158998

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:
        Add ENABLE_APPLE_PAY.

2016-06-21  Saam Barati  <sbarati@apple.com>

        CodeBlock::shrinkToFit is racy
        https://bugs.webkit.org/show_bug.cgi?id=158994
        <rdar://problem/26920212>

        Reviewed by Filip Pizlo.

        To see why this is racy, consider the following scenario:
        - CodeBlock A is link()ing its baseline compile.
        - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
        - The race occurs when the link() step of the baseline compile calls shrinkToFit
          on its m_resultProfiles field without grabbing a lock. This leads to a bad
          time because the DFG compile will be reading from that vector as it's getting
          changed by the baseline link() method.

        This race has always existed, though the move to a concurrent baseline
        JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
        grab its lock before shrinking the vector.

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

2016-06-21  David Kilzer  <ddkilzer@apple.com>

        Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
        <https://webkit.org/b/158989>

        Reviewed by Andy Estes.

        * Configurations/ToolExecutable.xcconfig:
        (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
        ToolExecutable.xcconfig.
        (PRODUCT_NAME): Remove.  This variable is already set for both
        testair and testb3 since those build configurations use
        ToolExecutable.xcconfig as a base.

2016-06-21  Saam Barati  <sbarati@apple.com>

        LLInt doesn't throw stack exception overflow from parent frame
        https://bugs.webkit.org/show_bug.cgi?id=158962
        <rdar://problem/26902188>

        Reviewed by Filip Pizlo.

        All JIT tiers will throw stack overflow exceptions from the parent frame.
        The LLInt, on the other hand, did not use to. I've changed the LLInt to be
        consistent with the JITs. The reason I found this bug is because we had a
        test that would give different results depending on if the function was compiled
        in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
        JIT patch, this otherwise deterministic test became dependent on it being compiled
        in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
        because it runs the test with --useJIT=false.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * tests/stress/llint-stack-overflow-location.js: Added.
        (stackTraceDescription):
        (foo):
        (catch):

2016-06-21  David Kilzer  <ddkilzer@apple.com>

        CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
        <https://webkit.org/b/158990>
        <rdar://problem/26906273>

        Reviewed by Dan Bernstein.

        * Configurations/JSC.xcconfig:
        (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
        [sdk=iphone*] to apply setting to iOS Simulator as well.
        * Configurations/ToolExecutable.xcconfig:
        (CODE_SIGN_ENTITLEMENTS): Ditto.

2016-06-21  Keith Miller  <keith_miller@apple.com>

        It should be easy to add a private global helper function for builtins
        https://bugs.webkit.org/show_bug.cgi?id=158893

        Reviewed by Mark Lam.

        This patch does two things. First it moves all the builtin names
        out of CommonIdentifiers and into BuiltinNames. This means that
        adding a new function to the Builtins does not require rebuilding
        all of JavaScriptCore. This patch also adds a new decorator to our
        builtins @privateGlobal that will automatically put the function
        on the global object. The name of the property will be the same as
        the private name of the function.

        This patch, also, removes the JSArrayIterator.h/.cpp files
        as they no longer appear to be used in any real way. Finally,
        the builtins tests have been rebaselined. It appears this has
        not been done for a while so the expected files contain other
        changes.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (generate_section_for_code_name_macro):
        (generate_section_for_global_private_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * builtins/ArrayIteratorPrototype.js:
        * builtins/ArrayPrototype.js:
        * builtins/BuiltinNames.h:
        * builtins/GeneratorPrototype.js:
        * builtins/GlobalObject.js:
        * builtins/PromiseOperations.js:
        * builtins/RegExpPrototype.js:
        * builtins/StringPrototype.js:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitPutHomeObject):
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/JSArrayIterator.cpp: Removed.
        (JSC::JSArrayIterator::finishCreation): Deleted.
        (JSC::JSArrayIterator::kind): Deleted.
        (JSC::JSArrayIterator::iteratedValue): Deleted.
        * runtime/JSArrayIterator.h: Removed.
        (JSC::JSArrayIterator::createStructure): Deleted.
        (JSC::JSArrayIterator::create): Deleted.
        (JSC::JSArrayIterator::JSArrayIterator): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/TypedArrayInlines.h:

2016-06-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS
        https://bugs.webkit.org/show_bug.cgi?id=158871

        Reviewed by Sam Weinig.

        Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties.

        * builtins/ModuleLoaderObject.js:
        (newRegistryEntry):
        (fulfillFetch):
        (fulfillTranslate):
        (commitInstantiated):
        (requestFetch):
        (requestTranslate):
        (requestInstantiate):
        (requestResolveDependencies.):
        (requestResolveDependencies):
        (requestLink):
        (link):
        (provide):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::finishCreation): Deleted.

2016-06-20  Commit Queue  <commit-queue@webkit.org>

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

        breaks builds on the simulator (Requested by keith_mi_ on
        #webkit).

        Reverted changeset:

        "It should be easy to add a private global helper function for
        builtins"
        https://bugs.webkit.org/show_bug.cgi?id=158893
        http://trac.webkit.org/changeset/202248

2016-06-20  Keith Miller  <keith_miller@apple.com>

        It should be easy to add a private global helper function for builtins
        https://bugs.webkit.org/show_bug.cgi?id=158893

        Reviewed by Mark Lam.

        This patch does two things. First it moves all the builtin names
        out of CommonIdentifiers and into BuiltinNames. This means that
        adding a new function to the Builtins does not require rebuilding
        all of JavaScriptCore. This patch also adds a new decorator to our
        builtins @privateGlobal that will automatically put the function
        on the global object. The name of the property will be the same as
        the private name of the function.

        This patch, also, removes the JSArrayIterator.h/.cpp files
        as they no longer appear to be used in any real way. Finally,
        the builtins tests have been rebaselined. It appears this has
        not been done for a while so the expected files contain other
        changes.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/builtins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (generate_section_for_code_name_macro):
        (generate_section_for_global_private_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * builtins/ArrayIteratorPrototype.js:
        * builtins/ArrayPrototype.js:
        * builtins/BuiltinNames.h:
        * builtins/GeneratorPrototype.js:
        * builtins/GlobalObject.js:
        * builtins/PromiseOperations.js:
        * builtins/RegExpPrototype.js:
        * builtins/StringPrototype.js:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitHomeObjectForCallee):
        (JSC::emitPutHomeObject):
        (JSC::FunctionNode::emitBytecode):
        * dfg/DFGOperations.cpp:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IntlDateTimeFormat.cpp:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/JSArrayIterator.cpp: Removed.
        (JSC::JSArrayIterator::finishCreation): Deleted.
        (JSC::JSArrayIterator::kind): Deleted.
        (JSC::JSArrayIterator::iteratedValue): Deleted.
        * runtime/JSArrayIterator.h: Removed.
        (JSC::JSArrayIterator::createStructure): Deleted.
        (JSC::JSArrayIterator::create): Deleted.
        (JSC::JSArrayIterator::JSArrayIterator): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSInternalPromise.cpp:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.cpp:
        (JSC::JSPromise::finishCreation):
        (JSC::JSPromise::result):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::create):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::finishCreation):
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/TypedArrayInlines.h:

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

        LLInt64 Float64 get_by_val doesn't purify NaN
        https://bugs.webkit.org/show_bug.cgi?id=158956

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter64.asm: Fix the bug.
        * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug.

2016-06-20  Keith Rollin  <krollin@apple.com>

        Remove RefPtr::release() and change calls sites to use WTFMove()
        https://bugs.webkit.org/show_bug.cgi?id=158369

        Reviewed by Chris Dumez.

        RefPtr::release() releases its managed pointer awkwardly. It's more
        direct and clearer to use WTFMove to transfer ownership of the managed
        pointer.

        As part of this cleanup, also change a lot of explicit data types to
        'auto'.

        * API/JSObjectRef.cpp:
        (JSClassCreate):
        * API/JSScriptRef.cpp:
        * API/JSValueRef.cpp:
        (JSValueToStringCopy):
        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::newObject):
        (JSC::StaticPropertyAnalyzer::mov):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::invalidate):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * inspector/InspectorValues.cpp:
        (Inspector::InspectorValue::parseJSON):
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::activateExtraDomain):
        (Inspector::InspectorAgent::activateExtraDomains):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedSetupMessage):
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer):
        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::releaseData):
        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::merge):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):

2016-06-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.profile should use the new Sampling Profiler
        https://bugs.webkit.org/show_bug.cgi?id=153499
        <rdar://problem/24352431>

        Reviewed by Timothy Hatcher.

        Currently console.profile/profileEnd behave slightly differently
        between JSContext and Web inspection. Unifying will be part of:
        <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend

        Both JSContext and Web inspection keep track of active
        profiles started and stopped via console.profile/profileEnd.

        JSContext inspection sends its programmatic start/stop
        via the ScriptProfiler domain.

        Web inspection sends its programmatic start/stop
        via the Timeline domain, and also will start/stop backend
        list of Instruments.

        The functional differences between these is that for JSContext
        inspection, console.profile only starts/stops the ScriptProfiler
        domain, and does not auto-start other instruments. This isn't really
        a problem right now given the instruments available for JSContext
        inspection; but it will be nice to unify as we add more instruments.
        Also, JSContext inspection won't have "Profile (name)" records in
        its Events view, since those are currently generated only by the
        Web's Timeline domain.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        Events to inform the frontend of programmatic start/stop.

        * debugger/Debugger.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        * inspector/agents/InspectorDebuggerAgent.h:
        Expose breakpoints active state, since programmatic recording
        will temporarily disabled breakpoints if needed.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::profile):
        (Inspector::JSGlobalObjectConsoleClient::profileEnd):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        JSContext implementation of console.profile/profileEnd.

2016-06-19  Saam Barati  <sbarati@apple.com>

        We should be able to generate more types of ICs inline
        https://bugs.webkit.org/show_bug.cgi?id=158719
        <rdar://problem/26825641>

        Reviewed by Filip Pizlo.

        This patch changes how we emit code for *byId ICs inline.
        We no longer keep data labels to patch structure checks, etc.
        Instead, we just regenerate the entire IC into a designated
        region of code that the Baseline/DFG/FTL JIT will emit inline.
        This makes it much simpler to patch inline ICs. All that's
        needed to patch an inline IC is to memcpy the code from
        a macro assembler inline using LinkBuffer. This architecture
        will be easy to extend into other forms of ICs, such as one
        for add, in the future.

        To support this change, I've reworked the fields inside
        StructureStubInfo. It now has one field that is the CodeLocationLabel 
        of the start of the inline IC. Then it has a few ints that track deltas
        to other locations in the IC such as the slow path start, slow path call, the
        ICs 'done' location. We used to perform math on these ints in a bunch of different
        places. I've consolidated that math into methods inside StructureStubInfo.

        To generate inline ICs, I've implemented a new class called InlineAccess.
        InlineAccess is stateless: it just has a bunch of static methods for
        generating code into the inline region specified by StructureStubInfo.
        Repatch will now decide when it wants to generate such an inline
        IC, and it will ask InlineAccess to do so.

        I've implemented three types of inline ICs to begin with (extending
        this in the future should be easy):
        - Self property loads (both inline and out of line offsets).
        - Self property replace (both inline and out of line offsets).
        - Array length on specific array types.
        (An easy extension would be to implement JSString length.)

        To know how much inline space to reserve, I've implemented a
        method that stubs out the various inline cache shapes and 
        dumps their size. This is used to determine how much space
        to save inline. When InlineAccess ends up generating more
        code than can fit inline, we will fall back to generating
        code with PolymorphicAccess instead.

        To make generating code into already allocated executable memory
        efficient, I've made AssemblerData have 128 bytes of inline storage.
        This saves us a malloc when splatting code into the inline region.

        This patch also tidies up LinkBuffer's API for generating
        into already allocated executable memory. Now, when generating
        code that has less size than the already allocated space, LinkBuffer
        will fill the extra space with nops. Also, if branch compaction shrinks
        the code, LinkBuffer will add a nop sled at the end of the shrunken
        code to take up the entire allocated size.

        This looks like it could be a 1% octane progression.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::nop):
        (JSC::ARM64Assembler::fillNops):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::nopw):
        (JSC::ARMv7Assembler::nopPseudo16):
        (JSC::ARMv7Assembler::nopPseudo32):
        (JSC::ARMv7Assembler::fillNops):
        (JSC::ARMv7Assembler::dmbSY):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::addLinkTask):
        (JSC::AbstractMacroAssembler::emitNops):
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerData::AssemblerData):
        (JSC::AssemblerData::operator=):
        (JSC::AssemblerData::~AssemblerData):
        (JSC::AssemblerData::buffer):
        (JSC::AssemblerData::grow):
        (JSC::AssemblerData::isInlineBuffer):
        (JSC::AssemblerBuffer::AssemblerBuffer):
        (JSC::AssemblerBuffer::ensureSpace):
        (JSC::AssemblerBuffer::codeSize):
        (JSC::AssemblerBuffer::setCodeSize):
        (JSC::AssemblerBuffer::label):
        (JSC::AssemblerBuffer::debugOffset):
        (JSC::AssemblerBuffer::releaseAssemblerData):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        (JSC::LinkBuffer::linkCode):
        (JSC::LinkBuffer::allocate):
        (JSC::LinkBuffer::performFinalization):
        (JSC::LinkBuffer::shrink): Deleted.
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::LinkBuffer):
        (JSC::LinkBuffer::debugAddress):
        (JSC::LinkBuffer::size):
        (JSC::LinkBuffer::wasAlreadyDisassembled):
        (JSC::LinkBuffer::didAlreadyDisassemble):
        (JSC::LinkBuffer::applyOffset):
        (JSC::LinkBuffer::code):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::patchableBranch32):
        (JSC::MacroAssemblerARM64::patchableBranch64):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::patchableBranch32):
        (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::nop):
        (JSC::X86Assembler::fillNops):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        * bytecode/InlineAccess.cpp: Added.
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::linkCodeInline):
        (JSC::InlineAccess::generateSelfPropertyAccess):
        (JSC::getScratchRegister):
        (JSC::hasFreeRegister):
        (JSC::InlineAccess::canGenerateSelfPropertyReplace):
        (JSC::InlineAccess::generateSelfPropertyReplace):
        (JSC::InlineAccess::isCacheableArrayLength):
        (JSC::InlineAccess::generateArrayLength):
        (JSC::InlineAccess::rewireStubAsJump):
        * bytecode/InlineAccess.h: Added.
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::initGetByIdSelf):
        (JSC::StructureStubInfo::initArrayLength):
        (JSC::StructureStubInfo::initPutByIdReplace):
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::aboutToDie):
        (JSC::StructureStubInfo::propagateTransitions):
        (JSC::StructureStubInfo::containsPC):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        (JSC::StructureStubInfo::slowPathCallLocation):
        (JSC::StructureStubInfo::doneLocation):
        (JSC::StructureStubInfo::slowPathStartLocation):
        (JSC::StructureStubInfo::patchableJumpForIn):
        (JSC::StructureStubInfo::valueRegs):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::finalize):
        (JSC::JITByIdGenerator::generateFastCommon):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        (JSC::JITGetByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
        (JSC::JITPutByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::slowPathFunction):
        (JSC::JITByIdGenerator::generateFastPathChecks): Deleted.
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITByIdGenerator::reportSlowPathCall):
        (JSC::JITByIdGenerator::slowPathBegin):
        (JSC::JITByIdGenerator::slowPathJump):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id):
        * jit/Repatch.cpp:
        (JSC::repatchCall):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::linkSlowFor):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::resetIn):
        (JSC::repatchByIdSelfAccess): Deleted.
        (JSC::resetGetByIDCheckAndLoad): Deleted.
        (JSC::resetPutByIDCheckAndLoad): Deleted.
        (JSC::replaceWithJump): Deleted.

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

        REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower
        https://bugs.webkit.org/show_bug.cgi?id=158906

        Reviewed by Benjamin Poulain.
        
        The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression
        on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without
        affecting the other tests.
        
        The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init
        code that took about 16ms to compile in baseline. There's no good way to avoid letting it
        tier-up into baseline since it has a compute loop. The time it takes to run this code is
        never measured. The concurrent baseline JIT caused us to schedule the compilation of this
        huge code rather than doing it eagerly. This meant that after initialization was done and
        we started actually running real stuff, all of the real stuff's compiles would be convoyed
        behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind
        baseline compiles, since you can't schedule a DFG compile for a code block until that code
        block is in baseline.
        
        This uses the simplest fix: if we are thinking about scheduling some compile and the
        thread is busy, do the compile on the main thread instead. This doesn't completely
        eliminate the ai-astar regression (we still have a 4% regression on that test) but it now
        results in concurrent baseline JIT being an overall progression on Kraken as a whole (1%
        on my machine). This is because concurrent baseline appears to help on other tests.

        In the future, we could fix this even better by allowing the JITWorklist to spawn more
        threads or by being smarter about baseline compilation. I think it's nasty that if a giant
        piece of initialization code ends in a compute loop, we compile all of the code instead of
        just the loop. It's also gross that a constant-like object creation expression will result
        in so much code. It would result in less code if we allowed ourselves to do a bit more
        static reasoning about object literals.
        
        But for now, I think that this is a great way to recover the Kraken regression while still
        keeping the other progressions from concurrent baseline.

        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::Plan::codeBlock):
        (JSC::JITWorklist::Plan::isFinishedCompiling):
        (JSC::JITWorklist::Plan::compileNow):
        (JSC::JITWorklist::JITWorklist):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        (JSC::JITWorklist::runThread):
        (JSC::JITWorklist::Plan::isFinalized): Deleted.
        * jit/JITWorklist.h:

2016-06-17  Commit Queue  <commit-queue@webkit.org>

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

        The new test is very unstable, timing out frequently
        (Requested by ap on #webkit).

        Reverted changeset:

        "Web Inspector: console.profile should use the new Sampling
        Profiler"
        https://bugs.webkit.org/show_bug.cgi?id=153499
        http://trac.webkit.org/changeset/202152

2016-06-14  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should be concurrent
        https://bugs.webkit.org/show_bug.cgi?id=158755

        Reviewed by Geoffrey Garen.
        
        This makes the baseline JIT concurrent. We want it to be concurrent because it takes up
        about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent
        optimizations).
        
        The idea is really simple: I separated the compile and link phases of JIT::privateCompile(),
        and arranged to call the compile phase from another thread. This doesn't reuse the old
        DFG::Worklist code, because that code does things we don't need (like compilation plan
        cancellation to allow GC to interleave with compilations) and is structured in a way that
        would have required more changes to the baseline JIT. Also, I think that code uses the wrong
        API, and as a result, clients of that API have a bad time. For example, it's never clear who
        has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great
        lengths to try to help its client set those things correctly, but since it doesn't set them
        directly, the client then has to have additional complex logic to combine what it learned
        from the Worklist and what it knows to set the thresholds. This patch takes a simpler
        approach: the JITWorklist takes complete control over scheduling compilations. It's like a
        combination of DFG::Worklist and operationOptimize().
        
        Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires
        that all of its plans complete before a GC begins. This ensures that we don't have to worry
        about interactions between the concurrent baseline JIT and the GC.
        
        I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For
        example, I needed to do things to opcodes that read profiling both in the main path code
        generator and the slow path one. One trick I used was to create a copy of the instruction
        stream and provide that for anyone interested in the original value of the profiles. Most
        code still uses the CodeBlock's instruction stream because it may emit JIT code that points
        at the stream.
        
        This also fixes a LLInt bug in prototype caching. This bug was revealed by this change
        because more of our LayoutTests now run in LLInt.
        
        This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3
        speed-up. This also looks like a ~2% JSBench speed-up.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp:
        (JSC::Debugger::setSteppingMode):
        (JSC::Debugger::toggleBreakpoint):
        (JSC::Debugger::clearBreakpoints):
        (JSC::Debugger::clearDebuggerRequests):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * heap/Heap.cpp:
        (JSC::Heap::didFinishIterating):
        (JSC::Heap::completeAllJITPlans):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::Heap::collectImpl):
        (JSC::Heap::completeAllDFGPlans): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachCodeBlock):
        * jit/JIT.cpp:
        (JSC::JIT::emitNotifyWrite):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JIT.h:
        (JSC::JIT::compile):
        (JSC::JIT::getSlowCase):
        (JSC::JIT::linkSlowCase):
        (JSC::JIT::linkDummySlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::emitTagBool):
        (JSC::JIT::originalInstruction):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITWorklist.cpp: Added.
        (JSC::JITWorklist::Plan::Plan):
        (JSC::JITWorklist::Plan::compileInThread):
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::Plan::codeBlock):
        (JSC::JITWorklist::Plan::vm):
        (JSC::JITWorklist::Plan::isFinishedCompiling):
        (JSC::JITWorklist::Plan::isFinalized):
        (JSC::JITWorklist::JITWorklist):
        (JSC::JITWorklist::~JITWorklist):
        (JSC::JITWorklist::completeAllForVM):
        (JSC::JITWorklist::poll):
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        (JSC::JITWorklist::runThread):
        (JSC::JITWorklist::finalizePlans):
        (JSC::JITWorklist::instance):
        * jit/JITWorklist.h: Added.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2016-06-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.profile should use the new Sampling Profiler
        https://bugs.webkit.org/show_bug.cgi?id=153499
        <rdar://problem/24352431>

        Reviewed by Timothy Hatcher.

        Currently console.profile/profileEnd behave slightly differently
        between JSContext and Web inspection. Unifying will be part of:
        <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend

        Both JSContext and Web inspection keep track of active
        profiles started and stopped via console.profile/profileEnd.

        JSContext inspection sends its programmatic start/stop
        via the ScriptProfiler domain.

        Web inspection sends its programmatic start/stop
        via the Timeline domain, and also will start/stop backend
        list of Instruments.

        The functional differences between these is that for JSContext
        inspection, console.profile only starts/stops the ScriptProfiler
        domain, and does not auto-start other instruments. This isn't really
        a problem right now given the instruments available for JSContext
        inspection; but it will be nice to unify as we add more instruments.
        Also, JSContext inspection won't have "Profile (name)" records in
        its Events view, since those are currently generated only by the
        Web's Timeline domain.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        Events to inform the frontend of programmatic start/stop.

        * debugger/Debugger.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        * inspector/agents/InspectorDebuggerAgent.h:
        Expose breakpoints active state, since programmatic recording
        will temporarily disabled breakpoints if needed.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::profile):
        (Inspector::JSGlobalObjectConsoleClient::profileEnd):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
        * inspector/agents/InspectorScriptProfilerAgent.h:
        JSContext implementation of console.profile/profileEnd.

2016-06-16  Filip Pizlo  <fpizlo@apple.com>

        Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL
        https://bugs.webkit.org/show_bug.cgi?id=158850

        Reviewed by Keith Miller.
        
        Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's
        crazy! We never noticed this because extending OSR liveness is usually not a showstopper and
        until recently we didn't have a lot of tail-call test cases to play with. Well, we do now,
        thanks to the increasing reliance on tail calls in our builtins.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::localsLiveInBytecode): Fix the bug and add some optional tracing. Also restructure the code so that we don't break to return true, since that's counterintuitive.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information.

2016-06-16  Mark Lam  <mark.lam@apple.com>

        Add collecting of LLINT slow path stats.
        https://bugs.webkit.org/show_bug.cgi?id=158829

        Reviewed by Keith Miller.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::dumpStats):
        * llint/LLIntData.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-06-15  Keith Miller  <keith_miller@apple.com>

        Add support for Symbol.isConcatSpreadable (round 2)
        https://bugs.webkit.org/show_bug.cgi?id=158769

        Reviewed by Mark Lam.

        This patch adds support for Symbol.isConcatSpreadable. In order to
        do so, it was necessary to move the Array.prototype.concat function
        to JS. A number of different optimizations were needed to make
        such the move to a builtin performant. First, this patch adds a
        new Bytecode intrinsic, isJSArray, that checks if the value is a
        JSArray object. Specifically, isJSArray checks that the array
        object is a normal instance of JSArray and not a RuntimeArray or
        Array.prototype. isJSArray can also be converted into a constant
        by the DFG if we are able to prove that the incomming value is
        already a JSArray.

        In order to further improve the perfomance we also now cover more
        indexing types in our fast path memcpy code. Before we would only
        memcpy Arrays if they had the same indexing type and did not have
        Array storage or were undecided. Now the memcpy code covers the
        following additional three cases:

        1) One array is undecided and the other does not have array storage

        2) One array is Int32 and the other is contiguous (we map this
        into a contiguous array).

        3) The this value is an array and first argument is a non-array
        that does not have Symbol.isConcatSpreadable set.

        This patch also adds a new fast path for concat with more than one
        array argument by using memcpy to append values onto the result
        array. This works roughly the same as the two array fast path
        using the same methodology to decide if we can memcpy the other
        butterfly into the result butterfly.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath):
        (concat):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitIsJSArray):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::isArray):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_jsarray):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_jsarray):
        * jit/JITOperations.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::speciesWatchpointsValid):
        (JSC::speciesConstructArray):
        (JSC::moveElements):
        (JSC::concatAppendOne):
        (JSC::arrayProtoFuncConcat): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/IndexingType.h:
        (JSC::indexingTypeForValue):
        * runtime/JSArray.cpp:
        (JSC::JSArray::appendMemcpy):
        (JSC::JSArray::fastConcatWith): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::isJSArray):
        (JSC::JSArray::fastConcatType): Deleted.
        * runtime/JSArrayInlines.h: Added.
        (JSC::JSArray::mergeIndexingTypeForCopying):
        (JSC::JSArray::canFastCopy):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::convertUndecidedForValue):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject):
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
        (arrayEq):
        * tests/stress/array-concat-spread-proxy.js: Added.
        (arrayEq):
        * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
        (arrayEq):
        * tests/stress/array-species-config-array-constructor.js:

2016-06-15  Mark Lam  <mark.lam@apple.com>

        Assertion failure when returning incomplete property descriptor from proxy trap.
        https://bugs.webkit.org/show_bug.cgi?id=157078

        Reviewed by Saam Barati.

        If the proxy returns a descriptor that expects a value but does not specify one,
        we should use undefined for the value.

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        * tests/stress/proxy-returning-incomplete-property-descriptor.js: Added.
        (truthiness):
        (compare):
        (shouldBe):
        (test):
        (get test):

2016-06-15  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix typo in test and move tests to the correct files.

        * tests/stress/multi-get-by-offset-proto-or-unset.js:
        * tests/stress/multi-get-by-offset-proto-self-or-unset.js:

2016-06-15  Keith Miller  <keith_miller@apple.com>

        DFGByteCodeParser should be able to infer the value of unset properties in MultiGetByOffset
        https://bugs.webkit.org/show_bug.cgi?id=158802

        Reviewed by Filip Pizlo.

        This patch adds support for unset properties in MultiGetByOffset. Since MultiGetByOffset
        already supports constant values this patch just adds a constant case where the fetched
        value is undefined. Fortunately (or unfortunately) we don't support object allocation
        sinking for constant cases of MultiGetByOffset, which means we don't need to adjust any
        in that phase.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::planLoad):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * dfg/DFGMultiGetByOffsetData.h:
        * tests/stress/multi-get-by-offset-proto-or-unset.js: Added.
        (foo):
        * tests/stress/multi-get-by-offset-proto-self-or-unset.js: Added.
        (foo):
        * tests/stress/multi-get-by-offset-self-or-unset.js: Added.
        (foo):

2016-06-15  Chris Dumez  <cdumez@apple.com>

        Unreviewed GCC build fix after r202098.

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

2016-06-14  Geoffrey Garen  <ggaren@apple.com>

        compilation policy should adapt to past behavior
        https://bugs.webkit.org/show_bug.cgi?id=158759

        Reviewed by Saam Barati.

        This looks like a ~9% speedup on JSBench.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock): Record when a CodeBlock dies without ever
        making it to DFG.

        (JSC::CodeBlock::thresholdForJIT): CodeBlocks that make it to DFG should
        compile sooner; CodeBlocks that don't should compile later. The goal is
        to use past behavior, in addition to execution counts, to determine
        whether compilation is profitable.

        (JSC::CodeBlock::jitAfterWarmUp):
        (JSC::CodeBlock::jitSoon): Apply the thresholdForJIT rule.

        * bytecode/CodeBlock.h: Moved some code into the .cpp file so I could
        change stuff without recompiling.
        (JSC::CodeBlock::jitAfterWarmUp): Deleted.
        (JSC::CodeBlock::jitSoon): Deleted.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::didOptimize):
        (JSC::UnlinkedCodeBlock::setDidOptimize): Added a piece of data to track
        whether we made it to DFG.

        * jit/JITOperations.cpp: Record when we make it to DFG.

2016-06-15  Konstantin Tokarev  <annulen@yandex.ru>

        Only Mac port needs ObjC API for JSC.
        https://bugs.webkit.org/show_bug.cgi?id=158780

        Reviewed by Philippe Normand.

        * API/JSBase.h: Removed !defined(BUILDING_GTK__)

2016-06-15  Keith Miller  <keith_miller@apple.com>

        DFGByteCodeParser should be able to infer a property is unset from the Baseline inline cache.
        https://bugs.webkit.org/show_bug.cgi?id=158774

        Reviewed by Filip Pizlo.

        This patch allows the DFGByteCodeParser to speculatively convert a property access into a
        constant if that access was always a miss in the Baseline inline cache. This patch does
        not add support for MultiGetByOffset and unset properties. That functionality will come
        a future patch.

        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/GetByIdVariant.h:
        (JSC::GetByIdVariant::isPropertyUnset):
        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::isPropertyUnset):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::handleGetById):
        * tests/stress/undefined-access-then-self-change.js: Added.
        (foo):

2016-06-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Move calling convention flags to WTF
        https://bugs.webkit.org/show_bug.cgi?id=158661

        Reviewed by Keith Miller.

        Due to some calling convention flags and JIT_OPERATION flags, MathCommon.h includes MacroAssemblerCodeRef and JITOperations.h.
        But MacroAssembler and JIT part should not be necessary for the MathCommon component.
        As with other calling convention flags like JSC_HOST_CALL, these flags should be in WTF.

        * assembler/MacroAssemblerCodeRef.h:
        * jit/JITOperations.h:
        Add wtf/Platform.h inclusion driven by the Windows port build failure.

        * runtime/MathCommon.h:

2016-06-15  Romain Bellessort  <romain.bellessort@crf.canon.fr>

        Enabling Shadow DOM for all platforms
        https://bugs.webkit.org/show_bug.cgi?id=158738

        Reviewed by Ryosuke Niwa.

        Removed Shadow DOM from options (enabled by default)

        * Configurations/FeatureDefines.xcconfig:

2016-06-14  Caio Lima  <ticaiolima@gmail.com>

        The parser doesn't properly parse "super" when default parameter is an
        arrow function.
        https://bugs.webkit.org/show_bug.cgi?id=157872.

        Reviewed by Saam Barati.

        The "super" member or "super()" could not be used when default parameter is an
        arrow function, resuling in sytax error. It happened because the
        "closestOrdinaryFunctionScope" was not being initialized properly
        before "parseFunctionParameters" step and the condition
        "functionSuperBinding == SuperBinding::NotNeeded" or
        "functionConstructorKind != ConstructorKind::Derived" on
        "Parser<LexerType>::parseMemberExpression" step were being true
        resulting in SyntaxError.

        * parser/Parser.cpp: 
        (JSC::Parser<LexerType>::parseFunctionInfo): setting
        "functionScope->setExpectedSuperBinding(expectedSuperBinding)" and
        "functionScope->setConstructorKind(constructorKind)" before
        "parseFunctionParameters" step.

2016-06-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Rename Timeline.setAutoCaptureInstruments to Timeline.setInstruments
        https://bugs.webkit.org/show_bug.cgi?id=158762

        Reviewed by Timothy Hatcher.

        Rename the protocol methods since the backend may use the instruments
        for purposes other then auto-capture, such as programmatic capture
        via console.profile.

        * inspector/protocol/Timeline.json:

2016-06-14  David Kilzer  <ddkilzer@apple.com>

        Document the native format of JSChar type
        <http://webkit.org/b/156137>

        Reviewed by Darin Adler.

        * API/JSStringRef.h:
        (typedef JSChar): Update documentation.

2016-06-14  Keith Miller  <keith_miller@apple.com>

        The Array species constructor watchpoints should be created the first time they are needed rather than on creation
        https://bugs.webkit.org/show_bug.cgi?id=158754

        Reviewed by Benjamin Poulain.

        We use adaptive watchpoints for some Array prototype functions to
        ensure that the user has not overridden the value of the
        Array.prototype.constructor or Array[Symbol.species]. This patch
        changes when the Array species constructor watchpoints are
        initialized. Before, those watchpoints would be created when the
        global object is initialized. This had the advantage that it did
        not require validating the constructor and Symbol.species
        properties. On the other hand, it also meant that if the user were
        to reconfigure properties Array.prototype, which would cause the
        structure of the property to become an uncachable dictionary,
        prior to running code that the watchpoints would be
        invalidated. It turns out that JSBench amazon, for instance, does
        reconfigure some of Array.prototype's properties. This patch
        initializes the watchpoints the first time they are needed. Since
        we only initialize once we also flatten the structure of Array and
        Array.prototype.

        * runtime/ArrayPrototype.cpp:
        (JSC::speciesConstructArray):
        (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
        (JSC::ArrayPrototype::setConstructor): Deleted.
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::speciesWatchpointStatus):
        (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::speciesGetterSetter):
        (JSC::JSGlobalObject::arrayConstructor):
        * tests/stress/array-symbol-species-lazy-watchpoints.js: Added.
        (test):
        (arrayEq):
        (A):

2016-06-14  Keith Miller  <keith_miller@apple.com>

        REGRESSION(202002-202014): 845 32-bit JSC Stress Test failures
        https://bugs.webkit.org/show_bug.cgi?id=158737

        Reviewed by Filip Pizlo.

        When the this child and arguments child for the varargs nodes was switched I missed one
        case in the 32-bit build.

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

2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>

        setUpStaticFunctionSlot does not handle Builtin|Accessor properties
        https://bugs.webkit.org/show_bug.cgi?id=158637

        Reviewed by Geoff Garen.

        setUpStaticFunctionSlot contains a duplicate copy of the body of the function reifyStaticProperty
        - however it is missing handling for Accessor type under Builtin functions.
        Fix the bug by de-duplicating - setUpStaticFunctionSlot should just call reifyStaticProperty.

        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
            - should just call reifyStaticProperty.
        * runtime/Lookup.h:
        (JSC::lookupPut):
        (JSC::reifyStaticProperty):
            - changed reifyStaticProperty to take PropertyName.

2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>

        JSBoundSlotBaseFunction no longer binds slot base
        https://bugs.webkit.org/show_bug.cgi?id=157978

        Reviewed by Geoff Garen.

        This class is basically currently named after a bug. We should never have
        been binding function to slot bases - this was not ever correct behavior.
        This was fixed earlier in the year, but there is still some cruft including
        the class name to clean up.

            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
            - removed m_boundSlotBase - don't retain the original slot base
              (we were not really using it anyway).
            - ASSERT customGetterSetter->getter/setter are non-null, rather than checking.
            - Store the PropertyName such that we can pass this to the getter
              (we're currently reperforming the String->Identifier conversion every time).
            - Removed JSFunction::lookUpOrCreateNativeExecutable - this is just overhead,
              and not used consistently.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSBoundSlotBaseFunction.cpp: Removed.
        * runtime/JSBoundSlotBaseFunction.h: Removed.
            - JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
        * runtime/JSCustomGetterSetterFunction.cpp: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.cpp.
        (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
            - made a static function on JSCustomGetterSetterFunction such that accessor
              to member properties could be made private. Call variant of callCustomSetter
              that does not require slotBase, ASSERT getter/setter present, pass stored
              PropertyName to getter.
        (JSC::JSCustomGetterSetterFunction::JSCustomGetterSetterFunction):
            - renamed, store propertyName.
        (JSC::JSCustomGetterSetterFunction::create):
            - use same function name to Executable as is being passed to Function::finishCreation.
        (JSC::JSCustomGetterSetterFunction::visitChildren):
        (JSC::JSCustomGetterSetterFunction::finishCreation):
            - removed m_boundSlotBase.
        * runtime/JSCustomGetterSetterFunction.h: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.h.
        (JSC::JSCustomGetterSetterFunction::customGetterSetter):
        (JSC::JSCustomGetterSetterFunction::isSetter):
            - made private.
        (JSC::JSCustomGetterSetterFunction::propertyName):
            - new accessor.
        (JSC::JSBoundSlotBaseFunction::boundSlotBase): Deleted.
            - removed.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        (JSC::JSFunction::lookUpOrCreateNativeExecutable): Deleted.
            - removed lookUpOrCreateNativeExecutable. This inconsistently used wrapper was providing no value, only bloat.
        * runtime/JSFunction.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::customGetterSetterFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
            - removed lookUpOrCreateNativeExecutable.
        * runtime/JSObject.cpp:
        (JSC::getCustomGetterSetterFunctionForGetterSetter):
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
        * runtime/VM.h:
            - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.

2016-06-13  Saam Barati  <sbarati@apple.com>

        The sampling profiler should further protect itself against certain forms of sampling bias that arise due to the sampling interval being in sync with some other system process
        https://bugs.webkit.org/show_bug.cgi?id=158678

        Reviewed by Benjamin Poulain.

        I first became aware of this problem when I read this paper:
        http://plv.colorado.edu/papers/mytkowicz-pldi10.pdf

        To provide background for this change, I'll quote a paragraph
        from section 6.2:
        "One statically sound method for collecting random samples is to collect a
        sample at every t + r milliseconds, where t is the desired sampling interval
        and r is a random number between −t and t. One might think that sampling every
        t seconds is enough (i.e., drop the r component) but it is not: specifically,
        if a profiler samples every t seconds, the sampling rate would be synchronized
        with any program or system activity that occurs at regular time intervals [17].
        For example, if the thread scheduler switches between threads every 10ms and our
        sampling interval was also 10ms, then we may always take samples immediately after
        a thread switch. Because performance is often different immediately after a thread
        switch than at other points (e.g., due to cache and TLB warm-up effects) we would
        get biased data. The random component, r, guards against such situations."

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::timerLoop):

2016-06-13  Oliver Hunt  <oliver@apple.com>

        DFG Validation fails when performing a concatenation with only a single entry
        https://bugs.webkit.org/show_bug.cgi?id=158699

        Reviewed by Saam Barati.

        Fairly simple short circuiting of a single replacement template string
        without any padding to be planted as a simple to string rather than
        op_strcat.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TemplateLiteralNode::emitBytecode):
        * tests/stress/template-literal.js:
        (testSingleNode):

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

        FTL::Output methods should be out-of-line whenever possible
        https://bugs.webkit.org/show_bug.cgi?id=158704

        Reviewed by Benjamin Poulain.
        
        These methods turn into a non-trivial amount of code because of the template-based B3 API.
        Inlining them didn't achieve any performance advantages for the FTL, but it did make the
        code larger. This outlines most methods in FTL::Output. It makes FTL::LowerDFGToB3 smaller
        and it doesn't change performance.

        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::framePointer):
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        (JSC::FTL::Output::constInt64):
        (JSC::FTL::Output::constDouble):
        (JSC::FTL::Output::phi):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::sub):
        (JSC::FTL::Output::mul):
        (JSC::FTL::Output::div):
        (JSC::FTL::Output::chillDiv):
        (JSC::FTL::Output::mod):
        (JSC::FTL::Output::chillMod):
        (JSC::FTL::Output::neg):
        (JSC::FTL::Output::doubleAdd):
        (JSC::FTL::Output::doubleSub):
        (JSC::FTL::Output::doubleMul):
        (JSC::FTL::Output::doubleDiv):
        (JSC::FTL::Output::doubleMod):
        (JSC::FTL::Output::bitAnd):
        (JSC::FTL::Output::bitOr):
        (JSC::FTL::Output::bitXor):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::bitNot):
        (JSC::FTL::Output::logicalNot):
        (JSC::FTL::Output::ctlz32):
        (JSC::FTL::Output::doubleAbs):
        (JSC::FTL::Output::doubleCeil):
        (JSC::FTL::Output::doubleFloor):
        (JSC::FTL::Output::doubleTrunc):
        (JSC::FTL::Output::doubleSin):
        (JSC::FTL::Output::doubleCos):
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doublePowi):
        (JSC::FTL::Output::doubleSqrt):
        (JSC::FTL::Output::doubleLog):
        (JSC::FTL::Output::hasSensibleDoubleToInt):
        (JSC::FTL::Output::doubleToUInt):
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::intToDouble):
        (JSC::FTL::Output::unsignedToDouble):
        (JSC::FTL::Output::castToInt32):
        (JSC::FTL::Output::doubleToFloat):
        (JSC::FTL::Output::floatToDouble):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::baseIndex):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::doubleEqualOrUnordered):
        (JSC::FTL::Output::doubleNotEqualOrUnordered):
        (JSC::FTL::Output::doubleLessThan):
        (JSC::FTL::Output::doubleLessThanOrEqual):
        (JSC::FTL::Output::doubleGreaterThan):
        (JSC::FTL::Output::doubleGreaterThanOrEqual):
        (JSC::FTL::Output::doubleNotEqualAndOrdered):
        (JSC::FTL::Output::doubleLessThanOrUnordered):
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
        (JSC::FTL::Output::isZero32):
        (JSC::FTL::Output::notZero32):
        (JSC::FTL::Output::isZero64):
        (JSC::FTL::Output::notZero64):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::jump):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::check):
        (JSC::FTL::Output::ret):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::speculate):
        (JSC::FTL::Output::speculateAdd):
        (JSC::FTL::Output::speculateSub):
        (JSC::FTL::Output::speculateMul):
        (JSC::FTL::Output::patchpoint):
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::anchor):
        (JSC::FTL::Output::bitCast):
        (JSC::FTL::Output::fround):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::setOrigin):
        (JSC::FTL::Output::origin):
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::doubleNeg):
        (JSC::FTL::Output::zeroExtPtr):
        (JSC::FTL::Output::load32NonNegative):
        (JSC::FTL::Output::isNull):
        (JSC::FTL::Output::notNull):
        (JSC::FTL::Output::testIsZeroPtr):
        (JSC::FTL::Output::testNonZeroPtr):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::operation):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::switchInstruction):
        (JSC::FTL::Output::addIncomingToPhi):
        (JSC::FTL::Output::framePointer): Deleted.
        (JSC::FTL::Output::constBool): Deleted.
        (JSC::FTL::Output::constInt32): Deleted.
        (JSC::FTL::Output::constInt64): Deleted.
        (JSC::FTL::Output::constDouble): Deleted.
        (JSC::FTL::Output::phi): Deleted.
        (JSC::FTL::Output::add): Deleted.
        (JSC::FTL::Output::sub): Deleted.
        (JSC::FTL::Output::mul): Deleted.
        (JSC::FTL::Output::div): Deleted.
        (JSC::FTL::Output::chillDiv): Deleted.
        (JSC::FTL::Output::mod): Deleted.
        (JSC::FTL::Output::chillMod): Deleted.
        (JSC::FTL::Output::doubleAdd): Deleted.
        (JSC::FTL::Output::doubleSub): Deleted.
        (JSC::FTL::Output::doubleMul): Deleted.
        (JSC::FTL::Output::doubleDiv): Deleted.
        (JSC::FTL::Output::doubleMod): Deleted.
        (JSC::FTL::Output::bitAnd): Deleted.
        (JSC::FTL::Output::bitOr): Deleted.
        (JSC::FTL::Output::bitXor): Deleted.
        (JSC::FTL::Output::shl): Deleted.
        (JSC::FTL::Output::aShr): Deleted.
        (JSC::FTL::Output::lShr): Deleted.
        (JSC::FTL::Output::ctlz32): Deleted.
        (JSC::FTL::Output::addWithOverflow32): Deleted.
        (JSC::FTL::Output::subWithOverflow32): Deleted.
        (JSC::FTL::Output::mulWithOverflow32): Deleted.
        (JSC::FTL::Output::addWithOverflow64): Deleted.
        (JSC::FTL::Output::subWithOverflow64): Deleted.
        (JSC::FTL::Output::mulWithOverflow64): Deleted.
        (JSC::FTL::Output::doubleAbs): Deleted.
        (JSC::FTL::Output::doubleCeil): Deleted.
        (JSC::FTL::Output::doubleFloor): Deleted.
        (JSC::FTL::Output::doubleSin): Deleted.
        (JSC::FTL::Output::doubleCos): Deleted.
        (JSC::FTL::Output::doublePow): Deleted.
        (JSC::FTL::Output::doubleSqrt): Deleted.
        (JSC::FTL::Output::doubleLog): Deleted.
        (JSC::FTL::Output::signExt32To64): Deleted.
        (JSC::FTL::Output::zeroExt): Deleted.
        (JSC::FTL::Output::intToDouble): Deleted.
        (JSC::FTL::Output::castToInt32): Deleted.
        (JSC::FTL::Output::doubleToFloat): Deleted.
        (JSC::FTL::Output::floatToDouble): Deleted.
        (JSC::FTL::Output::equal): Deleted.
        (JSC::FTL::Output::notEqual): Deleted.
        (JSC::FTL::Output::above): Deleted.
        (JSC::FTL::Output::aboveOrEqual): Deleted.
        (JSC::FTL::Output::below): Deleted.
        (JSC::FTL::Output::belowOrEqual): Deleted.
        (JSC::FTL::Output::greaterThan): Deleted.
        (JSC::FTL::Output::greaterThanOrEqual): Deleted.
        (JSC::FTL::Output::lessThan): Deleted.
        (JSC::FTL::Output::lessThanOrEqual): Deleted.
        (JSC::FTL::Output::doubleEqual): Deleted.
        (JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
        (JSC::FTL::Output::doubleNotEqualOrUnordered): Deleted.
        (JSC::FTL::Output::doubleLessThan): Deleted.
        (JSC::FTL::Output::doubleLessThanOrEqual): Deleted.
        (JSC::FTL::Output::doubleGreaterThan): Deleted.
        (JSC::FTL::Output::doubleGreaterThanOrEqual): Deleted.
        (JSC::FTL::Output::doubleNotEqualAndOrdered): Deleted.
        (JSC::FTL::Output::doubleLessThanOrUnordered): Deleted.
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): Deleted.
        (JSC::FTL::Output::doubleGreaterThanOrUnordered): Deleted.
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): Deleted.
        (JSC::FTL::Output::isZero32): Deleted.
        (JSC::FTL::Output::notZero32): Deleted.
        (JSC::FTL::Output::isZero64): Deleted.
        (JSC::FTL::Output::notZero64): Deleted.
        (JSC::FTL::Output::select): Deleted.
        (JSC::FTL::Output::extractValue): Deleted.
        (JSC::FTL::Output::jump): Deleted.
        (JSC::FTL::Output::ret): Deleted.
        (JSC::FTL::Output::unreachable): Deleted.
        (JSC::FTL::Output::speculate): Deleted.
        (JSC::FTL::Output::speculateAdd): Deleted.
        (JSC::FTL::Output::speculateSub): Deleted.
        (JSC::FTL::Output::speculateMul): Deleted.
        (JSC::FTL::Output::patchpoint): Deleted.
        (JSC::FTL::Output::trap): Deleted.
        (JSC::FTL::Output::anchor): Deleted.
        (JSC::FTL::Output::bitCast): Deleted.
        (JSC::FTL::Output::fround): Deleted.

2016-06-13  Keith Miller  <keith_miller@apple.com>

        Unreviewed, Cloop build fix.

        * bytecode/BytecodeList.json:

2016-06-12  Keith Miller  <keith_miller@apple.com>

        Add new builtin opcode tailCallForwardArguments
        https://bugs.webkit.org/show_bug.cgi?id=158666

        Reviewed by Filip Pizlo.

        We should support the ability to have a builtin forward its
        arguments to a helper without allocating an arguments object. This
        patch adds a new bytecode intrinsic @tailCallForwardArguments that
        takes two values. The first is the target of the call and the
        second is the new this value. This opcode will tail call to the
        passed function without triggering an allocation of an arguments
        object for the caller function.

        In the LLInt and Baseline this function acts the same way a normal
        tail call does.  The bytecode will allocate a new stack frame
        copying all the arguments of the caller function into the new
        frame, along with the new this. Then when the actual call happens
        the new frame is copied over the caller frame. While this is not
        necessary, it allows the target function to have more arguments
        than the caller function via arity fixup.

        Once we get to the DFG we reuse existing DFG Nodes for forwarding
        arguments, although there were some minor changes. This patch
        swaps the meaning of the second and third children for each DFG
        varargs node, exchanging the argmuments and this child,
        respectively. It also makes the arguments child for each varargs
        node, as well as the ForwardVarargs node optional. If the optional
        child is missing, then forwarding node assumes that the arguments
        for the node's inlineCallFrame should be used instead. Finally,
        when inlining the target of an inlined
        op_tail_call_forward_arguments we make sure the arguments of the
        forwarding function are marked as non-unboxable since this would
        normally be done by the caller's create arguments object node,
        which does not exist in this case.

        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
        (JSC::BytecodeGenerator::emitCallVarargs):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArgumentsChild):
        (JSC::DFG::Node::argumentsChild):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        * interpreter/Interpreter.cpp:
        (JSC::sizeFrameForForwardArguments):
        (JSC::setupForwardArgumentsFrame):
        (JSC::setupForwardArgumentsFrameAndSetThis):
        * interpreter/Interpreter.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::varargsSetup):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * tests/stress/tailCallForwardArguments.js: Added.
        (putFuncToPrivateName.createBuiltin):
        (putFuncToPrivateName):
        (createTailCallForwardingFuncWith):
        (baz):
        (baz2):
        (baz3):
        (let.bodyText):
        (baz4):
        (baz5):
        (arrayEq):

2016-06-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, follow up patch for r201964
        https://bugs.webkit.org/show_bug.cgi?id=158619

        Fix typo in the comment.

        * runtime/MathCommon.h:
        (JSC::toInt32):

2016-06-13  Mark Lam  <mark.lam@apple.com>

        Add a mechanism for collecting LLINT stats.
        https://bugs.webkit.org/show_bug.cgi?id=158668

        Reviewed by Filip Pizlo.

        This patch will add a mechanism for collecting the stats on LLINT opcode
        execution counts.  The changes made to enable this are:

        1. Refactored how Options availability work so that we can add a new category:
           Configurable (in addition to the pre-existing Normal and Restricted
           availability).
               Normal options - always available.
               Restricted options - only available on debug builds.
               Configurable options - depends on #define flag options.

           This change is necessary so that:
           a. we won't have to rebuild the world when we want to enable that #define flag
              to make that Configurable option available.
           b. when the #define flag is disabled, the option will be invisible to the user.

           With this, we add our first configurable option, JSC_reportLLIntStats, which
           is dependent on the ENABLE_LLINT_STATS flag.  See next.

        2. Added the ENABLE_LLINT_STATS flag in LLIntCommon.h.  To enable LLINT stats
           collection, we'll need to set this flag to a non-zero value, and rebuilding
           the project.  By design, this will only require a minimal set of files to
           be rebuilt.

           ENABLE_LLINT_STATS is 0 (i.e. disabled) by default.

        3. Added a slow path callback to the LLINT's traceExecution() macro, to call
           _llint_count_opcode(), which in turns counts the opcode.  This callback will
           only be built into the LLINT if ENABLE_LLINT_STATS is non-zero.

        4. Added s_opcodeStatsArray to LLInt::Data.  This is where the stats are
           recorded and stored.

        5. Added calls to LLInt::Data::dumpStats() in jsc.cpp and DumpRenderTree.mm
           to dump the LLINT stats if enabled.  If enabled, the LLINT stats will be
           sorted and dumped (via dataLog) before the programs terminate.

        * interpreter/Interpreter.h:
        * jsc.cpp:
        (main):
        * llint/LLIntCommon.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::dumpStats):
        * llint/LLIntData.h:
        (JSC::LLInt::Data::opcodeStats):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_crash):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/Options.cpp:
        (JSC::parse):
        (JSC::Options::isAvailable):
        (JSC::overrideOptionWithHeuristic):
        (JSC::scaleJITPolicy):
        (JSC::Options::initialize):
        (JSC::Options::setOptionWithoutAlias):
        (JSC::Options::dumpAllOptions):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        (JSC::Option::Option):
        (JSC::Option::operator!=):
        (JSC::Option::id):

2016-06-11  Mark Lam  <mark.lam@apple.com>

        Minimize the amount of memcpy done for allocating Error stacks.
        https://bugs.webkit.org/show_bug.cgi?id=158664

        Reviewed by Darin Adler.

        Currently, Vector<StackFrame> are being copied around multiple times in the
        process of creating Error stacks.

        This patch avoids this unnecessary copying by:
        1. Sizing the StackFrame vector correctly to begin with, and skipping
           undesirable top frames before filling in the vector.
        2. Using perfect forwarding or passing by reference to pass the vector data around
           instead of copying the vectors.
        3. Changing the Exception object to take a Vector<StackFrame> instead of a
           RefCountedArray<StackFrame>.

        This patch has passed the JSC and layout tests.  Benchmarks show that perf is
        neutral.

        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::stackTraceAsString):
        (JSC::findExceptionHandler):
        * interpreter/Interpreter.h:
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/Exception.cpp:
        (JSC::Exception::finishCreation):
        * runtime/Exception.h:
        (JSC::Exception::valueOffset):
        (JSC::Exception::value):
        (JSC::Exception::stack):
        (JSC::Exception::didNotifyInspectorOfThrow):
        (JSC::Exception::setDidNotifyInspectorOfThrow):

2016-06-11  Mark Lam  <mark.lam@apple.com>

        Tests that overflows the stack should not be run with the sampling profiler.
        https://bugs.webkit.org/show_bug.cgi?id=158663

        Reviewed by Saam Barati.

        The sampling profiler will be sampling the whole stack, and the amount of memory
        churn will make this tests time out, especially with debug builds.  Hence,
        let's not run the test with the sampling profiler configuration.

        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):

2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, attempt to fix r201964 failure on Apple ports
        https://bugs.webkit.org/show_bug.cgi?id=158619

        Reviewed by Mark Lam.

        Add Private attributes to MathCommon.h.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Inline JSC::toInt32 to improve kraken
        https://bugs.webkit.org/show_bug.cgi?id=158619

        Reviewed by Mark Lam.

        Several kraken benchmarks show that JSC::toInt32 is frequently called.
        For example, stanford-crypto-pbkdf2 reports that the hottest runtime function is JSC::toInt32.

        The data is below (taken by Linux perf tools).
        5.50%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC7toInt32Ed
        3.96%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC20arrayProtoFuncConcatEPNS_9ExecStateE
        2.48%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC19arrayProtoFuncSliceEPNS_9ExecStateE
        1.69%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZNK3JSC9Structure27holesMustForwardToPrototypeERNS_2VME

        This is because of CommonSlowPaths' bit operations's JSValue::toInt32.
        Due to the slow path, in `value | 0`, `value` may be a double number value. In that case, JSC::toInt32 is called.

        While JSC::toIn32 is hot, the function itself is very small. It's worth inlining.

        This change offers the following kraken improvements.

                                                         baseline                  patched
        Kraken:
           audio-beat-detection                       47.492+-1.701             46.657+-1.232           might be 1.0179x faster
           stanford-crypto-aes                        43.669+-0.210      ^      42.862+-0.115         ^ definitely 1.0188x faster
           stanford-crypto-ccm                        45.213+-1.424             44.490+-1.290           might be 1.0162x faster
           stanford-crypto-pbkdf2                    107.665+-0.581      ^     106.229+-0.807         ^ definitely 1.0135x faster

        This patch only focused on the call to toInt32 from the runtime functions.
        So JSC::toInt32 calls from the baseline / DFG remain.
        We ensure that JIT code uses operationToInt32 instead of JSC::toInt32 since JSC::toInt32 is now marked as ALWAYS_INLINE.
        Linux perf profiler also finds that this `operationToInt32` is frequently called in the above benchmarks.
        It may be good to introduce asm emit for that instead of calling JSC::toInt32 operation in the separated patch.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
        * runtime/JSCJSValue.cpp:
        (JSC::toInt32): Deleted.
        * runtime/JSCJSValueInlines.h:
        * runtime/MathCommon.cpp:
        (JSC::operationToInt32):
        * runtime/MathCommon.h:
        (JSC::toInt32):

2016-06-10  Filip Pizlo  <fpizlo@apple.com>

        The backend should be happy to compile Unreachable even if AI didn't prove it to be unreachable
        https://bugs.webkit.org/show_bug.cgi?id=158631

        Reviewed by Keith Miller.
        
        We've been slowly making the DFG Unreachable opcode behave like a grown-up. When we first
        added it, it was a hack for Throw, and we could always rely on AI proving that Unreachable
        was not reachable. But then we started using Unreachable as a proper Unreachable opcode,
        like Oops in B3 for example, which has a more nuanced meaning: you use it whenever you
        emit code that *you* know will not return, and you need some way of terminating the basic
        block. The DFG is not a proof-carrying compiler, and it never will be. So, when you have
        proved that something is not reachable, you should be able to use Unreachable even if
        there is no guarantee that the compiler will later be able to replicate your proof. This
        means that the backend may find itself compiling Unreachable because AI did not prove that
        it was unreachable.
        
        Prior to this change, we would crash compiling Unreachable because we would rely on AI
        preventing us from reaching Unreachable in the backend. But that's silly! We don't want
        users of Unreachable to have to also convince AI that their Unreachable is really
        Unreachable.
        
        This fixes crashes on real websites. I couldn't work out how to turn them into a reduced
        test.

        * assembler/AbortReason.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
        (JSC::DFG::SpeculativeJIT::unreachable):
        (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):

2016-06-09  Alex Christensen  <achristensen@webkit.org>

        Clean up JavaScriptCore.vcxproj directory after switching to CMake.

        * JavaScriptCore.vcxproj/LLInt: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Removed.
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed.
        * JavaScriptCore.vcxproj/jsc: Removed.
        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Removed.
        * JavaScriptCore.vcxproj/jsc/DLLLauncherWinCairo.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Removed.
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/jsc/jscCommon.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jscDebug.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncherPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscLauncherPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/jsc/jscProduction.props: Removed.
        * JavaScriptCore.vcxproj/jsc/jscRelease.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Removed.
        * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Removed.
        * JavaScriptCore.vcxproj/testapi: Removed.
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Removed.
        * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Removed.
        * shell/DLLLauncherMain.cpp: Copied from JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp.
        * shell/PlatformWin.cmake:

2016-06-09  Filip Pizlo  <fpizlo@apple.com>

        Rare failure in stress/v8-deltablue-strict.js.ftl-eager
        https://bugs.webkit.org/show_bug.cgi?id=158591

        Reviewed by Saam Barati.
        
        This is a simple and sensible fix to an amazing compiler bug that previously only
        manifested rarely in the v8-deltablue-strict test. It required on average 1000 runs while
        the system was under load for the bug to manifest. Fortunately, the bug is 100% repro with
        concurrent JIT disabled in the new "constant-fold-multi-get-by-offset-to-get-by-offset-on-
        prototype-and-sink-allocation.js" test.
        
        The problem here is that we were allowing ourselves to be super sloppy with the meaning of
        the two children of GetByOffset, and to a lesser extent, PutByOffset. The first two
        children of these nodes have these meanings:
        
        child1: the storage from which to load (or to which to store)
        child2: the logical object base
        
        Normally, child1 == child2, but child1 may point to a node that vends the storage pointer
        in case we are using multiple indirections to get to the property. That's fairly common.
        
        Where this gets nutty is that we don't validate the behavior of child1. Previously, the
        DFG::Validate phase would accept code that had child1 point to one object and child2 point
        to another object. That's bad because then, analyses will assume that we're loading from
        one object while we are actually loading from another. One of the fixes is to make
        Validate smarter about this, so that future problems with this get caught sooner.
        
        The actual bug was in ConstantFoldingPhase. When we first wrote ConstantFoldingPhase's
        logic for converting GetByIds and MultiGetByOffsets to GetByOffset, we assumed that this
        was only for non-prototype loads. This was becuase the logic was originally written based
        on a static GetByIdStatus analysis, which does not handle prototypes. So, as a shortcut,
        we would convert the GetById (or MultiGetByOffset) to a GetByOffset by doing this
        shuffling of children:
        
        child1 got the storage pointer, which might be a new GetButterfly node that we created.
        child2 got the old value of child1.
        
        The bug was introduced when I later made it possible for a monomorphic prototype
        MultiGetByOffset to be converted to a GetByOffset. Then this algorithm would mean that:
        
        child1 got either a pointer to the prototype or a storage pointer derived from the
            prototype.
        child2 got the old value of child1, which was a pointer to the base object (i.e. not the
            prototype).
        
        This happens super rarely because most prototype loads that we can statically reason about
        also happen to load constants, so we don't convert to GetByOffset at all. You need the
        strange combination of a MultiGetByOffset (not GetById or GetByOffset) on some prototypes
        and some static reasoning about the base so that we can convert it to a GetByOffset, but
        not enough static reasoning that we can convert it to a constant.
        
        Even if the bad thing happened, then this is not enough for it to cause symptons. If we
        did nothing else - like none of the other optimizations succeeded - then this would
        be OK because the backend will emit code based on child1, which is right. But disaster
        strikes when the code otherwise looks sane enough for ObjectAllocationSinkingPhase to kick
        in. This phase operates on child2, as any good phase should: child1 is only interesting
        for knowing *how* to load, not *what* we are loading. The phase is right to ignore child1.

        So the phase would assume that we are loading the prototype property ("f" in the new test
        or "addToGraph" in deltablue) from the sunken base object allocation in the inlined
        constructor. The base object has no such property, but the phase conservatively assumes
        that it does indeed have such a property. That's just how the phase does things: it is
        very abstract and general, so it assumes that the set of properties on an allocation is
        the set of properties that accesses to the allocation speak of. Clearly, this GetByOffset
        was speaking of the property as being on the allocation. When sinking completed, it would
        convert the GetByOffset to the sunken (a.k.a. promoted) property. But nobody stored to
        this property on the allocation, so we'd get the bottom value, which is 1927. Why 1927? I
        don't remember anymore, but apparently I chose it. It helped here - when I started seeing
        that value come up, it took a quick grep to realize that this was the object allocation
        sinking phase's bottom value.
        
        The real fix to the bug is to make Node::convertToGetByOffset() take an explicit new base
        since its clients will use it to potentially create a load on a different object than the
        base of the original operation, as in the relatively new
        MultiGetByOffset(prototype)->GetByOffset optimization. As far as I know, the PutByOffset
        code did not have the same bug because we don't have any optimizations that turn a PutById
        or MultiPutByOffset into a PutByOffset on anything but the base object. But the logical
        bug is definitely there: there's code in ConstantFoldingPhase that claims to be able to
        convert any node to a PutByOffset on any base, but it actually silently reuses the
        original node's child1 as the logical base (i.e. child2). This patch makes all of this
        stuff explicit. You can't make this mistake anymore.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToGetStack):
        (JSC::DFG::Node::convertToGetByOffset):
        (JSC::DFG::Node::convertToMultiGetByOffset):
        (JSC::DFG::Node::convertToPutByOffset):
        * dfg/DFGValidate.cpp:
        * tests/stress/constant-fold-multi-get-by-offset-to-get-by-offset-on-prototype-and-sink-allocation.js: Added.
        (ThingA):
        (ThingB):
        (foo):
        (bar):
        * tests/stress/sink-to-impossible-multi-get-by-offset-on-prototypes.js: Added.
        (ThingA):
        (ThingB):
        (ThingC):
        (bar):
        (foo):

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

        Make some methods const.
        https://bugs.webkit.org/show_bug.cgi?id=158594

        Reviewed by Benjamin Poulain.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::columnNumberForBytecodeOffset):
        (JSC::CodeBlock::expressionRangeForBytecodeOffset):
        * bytecode/CodeBlock.h:
        * bytecode/ExpressionRangeInfo.h:
        (JSC::ExpressionRangeInfo::encodeFatColumnMode):
        (JSC::ExpressionRangeInfo::decodeFatLineMode):
        (JSC::ExpressionRangeInfo::decodeFatColumnMode):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::getLineAndColumn):
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::isOpcode):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative):

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

        ES6: Reusing function name as a parameter name shouldn't throw Syntax Error
        https://bugs.webkit.org/show_bug.cgi?id=158575

        Reviewed by Benjamin Poulain.

        The check for a parameter with a duplicate name doesn't take into account the
        type of the prior variable.  Added a check that the duplicate is also a
        parameter.

        See the relevant spec section at:
        http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors

        * parser/Parser.h:
        (JSC::Scope::declareParameter):

2016-06-09  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r201836, r201845, and r201848.

        Looks like a 1-2% PLT regression on iOS

        Reverted changesets:

        "[JSC] Change some parameters based on a random search"
        https://bugs.webkit.org/show_bug.cgi?id=158514
        http://trac.webkit.org/changeset/201836

        "Tempory fix for the debug bots"
        http://trac.webkit.org/changeset/201845

        "Change thresholdForOptimizeSoon to match
        thresholdForOptimizeAfterWarmUp"
        http://trac.webkit.org/changeset/201848

2016-06-09  Commit Queue  <commit-queue@webkit.org>

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

        breaks build without ENABLE_WEB_ANIMATION (Requested by
        mcatanzaro on #webkit).

        Reverted changeset:

        "[web-animations] Add Animatable, AnimationEffect,
        KeyframeEffect and Animation interface"
        https://bugs.webkit.org/show_bug.cgi?id=156096
        http://trac.webkit.org/changeset/201810

2016-06-08  Gavin & Ellie Barraclough  <barraclough@apple.com>

        JSObject::reifyAllStaticProperties cleanup
        https://bugs.webkit.org/show_bug.cgi?id=158543

        Reviewed by Mark Lam.

        - JSObject & Structure contain fields labeled 'staticFunctionsReified', however reification now
          affects all properties, not just functions. Rename to 'staticPropertiesReified'.
        - reifyAllStaticProperties relies on a 'hasStaticProperties' method on ClassInfo that walks the
          ClassInfo inheritance chain looking for static property tables. We can now more efficiently
          get this information from TypeInfo.
        - reifyAllStaticProperties triggers a 'toUncacheableDictionaryTransition'; this is overzealous,
          cacheable dictionary is sufficient - this is what we do in the case of DOM prototype property
          reification (see 'reifyStaticProperties' in Lookup.h). (Changing this with an eye on switching
          DOM prototype property reification to use JSObject:: reifyAllStaticProperties, rather than
          having its own special purpose code path.)

        * runtime/ClassInfo.h:
        (JSC::ClassInfo::hasStaticProperties): Deleted.
            - deprecated by TypeInfo::hasStaticPropertyTable.
        * runtime/JSObject.cpp:
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::getOwnNonIndexPropertyNames):
            - staticFunctionsReified -> staticPropertiesReified
        (JSC::JSObject::reifyAllStaticProperties):
            - hasStaticProperties -> TypeInfo::hasStaticPropertyTable
            - toUncacheableDictionaryTransition -> toCacheableDictionaryTransition
            - staticFunctionsReified -> staticPropertiesReified
        * runtime/JSObject.h:
        (JSC::JSObject::staticPropertiesReified):
        (JSC::JSObject::staticFunctionsReified): Deleted.
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::getStaticPropertySlotFromTable):
        (JSC::replaceStaticPropertySlot):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        * runtime/Structure.h:
            - staticFunctionsReified -> staticPropertiesReified

2016-06-08  Benjamin Poulain  <bpoulain@apple.com>

        Change thresholdForOptimizeSoon to match thresholdForOptimizeAfterWarmUp

        Unreviewed.

        This adds back the assertion removed in r201845.
        Making those threshold equal is completely perf neutral
        (on Haswell rMBP with 20 runs).

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

2016-06-08  Benjamin Poulain  <bpoulain@apple.com>

        Tempory fix for the debug bots

        Unreviewed.

        * runtime/Options.cpp:
        (JSC::Options::initialize):
        Weaken an assertion while I test values for thresholdForOptimizeSoon.

2016-06-08  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Change some parameters based on a random search
        https://bugs.webkit.org/show_bug.cgi?id=158514

        Reviewed by Filip Pizlo.

        Over the weekend, I left an iMac running the JSC benchmarks
        while changing a bunch of parameters.

        The parameters were changed randomly, with a random deviation
        from the original value.
        To converge toward good values, the range was subject
        to exponential annealing over time.

        The values in this patch is the best outcome my iMac could
        find over the weekend. It is about 1% better on the Haswell
        machines I tested.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        * runtime/Options.h:

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

        Remove removeDirect
        https://bugs.webkit.org/show_bug.cgi?id=158516

        Reviewed by Ryosuke Niwa.

        removeDirect is typically used as a subroutine of deleteProperty, but is also available to
        call directly. Having this functionality factored out to a separate routine is a bad idea
        on a couple of fronts:

        - for the main use within deleteProperty there is redundancy (presence of the property
          was being checked twice) and inconsistency (the two functions returned different results
          in the case of a nonexistent property; the result from removeDirect was never observed).

        - all uses of removeDirect are in practical terms incorrect. removeDirect had the
          advantage of ignoring the configurable (DontDelete) attributes, but this is achievable
          using the DeletePropertyMode setting - and the disadvantage of failing delete static
          table properties. Last uses were one that was removed in bug #158295 (where failure to
          delete static properties was a problem), and as addressed in this patch removeDirect is
          being used to implement runtime enabled features. This only works because we currently
          force reification of all properties on the DOM prototype objects, so in effect there are
          no static properties. In order to make the code robust such that runtime enabled
          features would still work even if we were not reifying static properties (a change we
          may want to make) we should be calling deleteProperty in this case too.

        * runtime/JSObject.cpp:
        (JSC::JSObject::deleteProperty):
            - incorporated removeDirect functionality, added comments & ASSERT.
        (JSC::JSObject::removeDirect): Deleted.
            - removed.
        * runtime/JSObject.h:
            - removed removeDirect.

2016-06-08  Mark Lam  <mark.lam@apple.com>

        Simplify Interpreter::StackFrame.
        https://bugs.webkit.org/show_bug.cgi?id=158498

        Reviewed by Saam Barati.

        Previously, Interpreter::StackFrame (which is used to capture info for
        Error.stack) eagerly extracts info out of CodeBlock and duplicates the work that
        CodeBlock does to compute line and column numbers (amongst other things).

        This patch does away with the eager extraction and only stashes the CodeBlock
        pointer in the Interpreter::StackFrame.  Instead, Interpreter::StackFrame will
        provide methods for computing the desired values on request later.

        One difference in implementation: the old StackFrame offers a sourceURL and a
        friendlySourceURL().  The only difference between the 2 is that for native
        functions, sourceURL returns an empty string, and friendlySourceURL() returns
        "[native code]".  This is how it affects the clients of StackFrame:

            - In the old code, the Error object's addErrorInfoAndGetBytecodeOffset() and
              the inspector's createScriptCallStackFromException() would check if
              sourceURL is empty.  If so, they will use this as an indicator to use
              alternate source info in the Error object e.g. url and line numbers from
              the parser that produced a SyntaxError.

            - In the new implementation, StackFrame only has a sourceURL() function that
              behaves like the old friendlySourceURL().  The client code which were
              relying on sourceURL being empty, will now explicitly check if the
              StackFrame is for native code using a new isNative() query in addition to
              the sourceURL being empty.  This achieve functional parity with the old
              behavior.

        Also fix Error.cpp's addErrorInfoAndGetBytecodeOffset() to take a bytecodeOffset
        pointer instead of a reference.  The bytecodeOffset arg is supposed to be
        optional, but was implemented in a unclear way.  This change clarifies it.

        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::sourceID):
        (JSC::StackFrame::sourceURL):
        (JSC::StackFrame::functionName):
        (JSC::eval):
        (JSC::Interpreter::isOpcode):
        (JSC::StackFrame::computeLineAndColumn):
        (JSC::StackFrame::toString):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::StackFrame::friendlySourceURL): Deleted.
        (JSC::StackFrame::friendlyFunctionName): Deleted.
        (JSC::getStackFrameCodeType): Deleted.
        (JSC::StackFrame::expressionInfo): Deleted.
        * interpreter/Interpreter.h:
        (JSC::StackFrame::isNative):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        (JSC::addErrorInfo):
        * runtime/Error.h:
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):

2016-06-08  Keith Miller  <keith_miller@apple.com>

        We should be able to lookup symbols by identifier in builtins
        https://bugs.webkit.org/show_bug.cgi?id=158530

        Reviewed by Mark Lam.

        This patch allows us to lookup the value of a symbol property on a
        object by identifier in builtins. Before, it was only possible to
        do so if we were directly emitting the bytecodes, such as in a
        for-of loop looking for Symbol.iterator. As we tier up we convert
        the builtin's get_by_val symbol lookups into get_by_id
        lookups. However, there is still a significant performance
        difference between get_by_id and get_by_val in the LLInt, where
        this transformation does not take place.

        In order to make this work we hijack BuiltinNames'
        m_publicToPrivateMap so that it points the @<symbol>Symbol to the
        appropriate vm symbol. This way when we lex the identifier it will
        become the appropriate symbol's identifier.  Currently, if the
        symbol is used to name a property in an object literal we will not
        keep a cache of the Symbol objects we have already seen. We could
        add a map for symbols but since we can only load symbols by
        identifier in builtins its likely not worth it. Additionally, even
        in builtins it is extremely rare to use Symbols in object
        literals.

        * builtins/ArrayConstructor.js:
        (from):
        * builtins/ArrayPrototype.js:
        (filter):
        (map):
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinUtils.h:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/StringPrototype.js:
        (match):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (search):
        (split):
        * builtins/TypedArrayConstructor.js:
        (from):
        * builtins/TypedArrayPrototype.js:
        (map):
        (filter):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):

2016-06-08  Rawinder Singh  <rawinder.singh-webkit@cisra.canon.com.au>

        [web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface
        https://bugs.webkit.org/show_bug.cgi?id=156096

        Reviewed by Dean Jackson.

        Adds:
        - Animatable interface and implementation of getAnimations in Element
        - Interface and implementation for Document getAnimations method.
        - AnimationEffect interface and class stub.
        - KeyframeEffect interface and constructor implementation.
        - 'Animation' interface, constructor and query methods for effect and timeline.
        - Remove runtime condition on Web animation interfaces (compile time flag is specified).

        * runtime/CommonIdentifiers.h:

2016-06-08  Chris Dumez  <cdumez@apple.com>

        self.hasOwnProperty() does not work inside Web workers
        https://bugs.webkit.org/show_bug.cgi?id=158446
        <rdar://problem/26638397>

        Reviewed by Geoffrey Garen.

        Add a factory function to JSProxy to create a JSProxy without a target.
        Also make the setTarget() method public so that the target can now be
        set after creation. This is needed so that we can create a proxy for
        JSWorkerGlobalScope, then create the JSWorkerGlobalScope object,
        passing it the proxy and finally set the target on the proxy.

        * runtime/JSProxy.h:
        (JSC::JSProxy::create):

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

        Add result validation to JSAir
        https://bugs.webkit.org/show_bug.cgi?id=158493

        Reviewed by Saam Barati.
        
        Add a ::jsHash() method to some things, to compute a hash code that is suitable for
        comparing a C++ Code to a JSAir Code. This is different from existing hashing functionality
        because it errs on the side of easy reproducibility from JS rather than speed.

        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isCompatibleType):
        (JSC::B3::Air::Arg::jsHash):
        (JSC::B3::Air::Arg::dump):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::asDoubleCondition):
        (JSC::B3::Air::Arg::isInvertible):
        (JSC::B3::Air::Arg::isUnsignedCond):
        (JSC::B3::Air::Arg::Arg):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addFastTmp):
        (JSC::B3::Air::Code::jsHash):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::lastPhaseName):
        * b3/air/AirDumpAsJS.cpp:
        (JSC::B3::Air::dumpAsJS):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasArgEffects):
        (JSC::B3::Air::Inst::jsHash):
        (JSC::B3::Air::Inst::dump):
        * b3/air/AirInst.h:
        * b3/air/AirStackSlot.cpp:
        (JSC::B3::Air::StackSlot::setOffsetFromFP):
        (JSC::B3::Air::StackSlot::jsHash):
        (JSC::B3::Air::StackSlot::dump):
        * b3/air/AirStackSlot.h:
        * b3/air/opcode_generator.rb:

2016-06-07  Mark Lam  <mark.lam@apple.com>

        Need an exception check after constructEmptyArray().
        https://bugs.webkit.org/show_bug.cgi?id=158411

        Reviewed by Saam Barati.

        Added an exception check after each call to constructEmptyArray().

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        (Inspector::JSInjectedScriptHost::weakMapEntries):
        (Inspector::JSInjectedScriptHost::weakSetEntries):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::functionsOnStack):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::addSequenceProperties):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::toJS):
        * profiler/ProfilerOSRExitSite.cpp:
        (JSC::Profiler::OSRExitSite::toJS):
        * profiler/ProfilerOriginStack.cpp:
        (JSC::Profiler::OriginStack::toJS):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectRequestedModules):
        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):
        * runtime/RegExpObject.cpp:
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncSplitFast):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncSplitFast):
        * runtime/TemplateRegistry.cpp:
        (JSC::TemplateRegistry::getTemplateObject):

        * tests/stress/regress-158411.js: Added.

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

        Implement Air::allocateStack() in ES6 to see how much of a bad idea that is
        https://bugs.webkit.org/show_bug.cgi?id=158318

        Reviewed by Saam Barati.
        
        Most of these changes are to support dumpAsJS(). But I also found some duplicate and dead
        code while rewriting it to JS.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateStack.cpp:
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isSomeImm):
        (JSC::B3::Air::Arg::isAddr):
        (JSC::B3::Air::Arg::tmpIndex):
        (JSC::B3::Air::Arg::isValidImmForm):
        (JSC::B3::Air::Arg::withOffset): Deleted. This was dead code.
        * b3/air/AirArgInlines.h: It turns out that Inst has a ForEach thing that duplicated some of the logic of ArgThingHelper, so I just made ArgThingHelper more powerful.
        (JSC::B3::Air::ArgThingHelper<Arg>::forEach):
        (JSC::B3::Air::ArgThingHelper<Reg>::is):
        (JSC::B3::Air::ArgThingHelper<Reg>::as):
        (JSC::B3::Air::ArgThingHelper<Reg>::forEachFast):
        (JSC::B3::Air::ArgThingHelper<Reg>::forEach):
        (JSC::B3::Air::Arg::is):
        * b3/air/AirDumpAsJS.cpp: Added.
        (JSC::B3::Air::dumpAsJS):
        * b3/air/AirDumpAsJS.h: Added.
        * b3/air/AirFixObviousSpills.cpp:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::forEach):
        (JSC::B3::Air::Inst::extraClobberedRegs):
        (JSC::B3::Air::ForEach<Tmp>::forEach): Deleted. This was doing what ArgThingHelper would have done but not as well.
        (JSC::B3::Air::ForEach<Arg>::forEach): Deleted.
        (JSC::B3::Air::ForEach<Reg>::forEach): Deleted.
        * b3/air/AirLogRegisterPressure.cpp:
        * b3/air/AirReportUsedRegisters.cpp:
        * b3/air/AirSpillEverything.cpp:
        * b3/air/opcode_generator.rb: Make this dump opcode.js, which is like what it dumps for C++.
        * jit/Reg.cpp:
        (JSC::Reg::debugName):
        (JSC::Reg::dump):
        * jit/Reg.h:
        (JSC::Reg::hash):
        * jsc.cpp: Fix jsc so that it reports the filename and line number of parser errors.
        (dumpException):
        * parser/ParserError.h: Make it easier to debug this code.
        (WTF::printInternal):
        * runtime/Options.h:

2016-06-07  Keith Rollin  <krollin@apple.com>

        Remove all uses of PassRefPtr in WTF
        https://bugs.webkit.org/show_bug.cgi?id=157596
        <rdar://problem/26234391>

        Reviewed by Chris Dumez.

        Update calls to interfaces that no longer take or return PassRefPtrs.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRope):
        * runtime/JSString.h:
        (JSC::JSString::JSString):
        (JSC::jsSubstring):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStringsStorage::SmallStringsStorage):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCodeSlowCase):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::replaceUsingStringSearch):
        (JSC::repeatCharacter):
        (JSC::stringProtoFuncFontsize):
        (JSC::stringProtoFuncLink):
        (JSC::normalize):

2016-06-07  Saam barati  <sbarati@apple.com>

        InvalidationPointInjectionPhase creates bogus InvalidationPoints that may even be inserted when it's not OK to exit
        https://bugs.webkit.org/show_bug.cgi?id=158499
        <rdar://problem/26647473>

        Reviewed by Mark Lam and Benjamin Poulain.

        InvalidationPointInjectionPhase forgot to clear m_originThatHadFire 
        before analyzing the current block it's analyzing. This meant that
        the phase allowed a residual m_originThatHadFire that was set from the
        previous block to effect a completely unrelated block. This is usually
        harmless, but sometimes we would insert an InvalidationPoint at a point
        in the graph when exiting is invalid. This would cause a crash.

        * dfg/DFGInvalidationPointInjectionPhase.cpp:
        (JSC::DFG::InvalidationPointInjectionPhase::run):
        * tests/stress/dont-crash-on-bad-invalidation-point.js: Added.
        (dontCrash):

2016-06-07  Saam Barati  <sbarati@apple.com>

        operationProcessTypeProfilerLogDFG doesn't update topCallFrame
        https://bugs.webkit.org/show_bug.cgi?id=158428
        <rdar://problem/26571493>

        Reviewed by Mark Lam.

        * dfg/DFGOperations.cpp:

2016-06-07  Mark Lam  <mark.lam@apple.com>

        calculatedDisplayName() and friends actually need a VM& and not a ExecState/CallFrame.
        https://bugs.webkit.org/show_bug.cgi?id=158488

        Reviewed by Geoffrey Garen.

        calculatedDisplayName() (and some of its friends) actually just need a VM&.
        Their work has nothing to do with an ExecState at all.  This patch will make that
        clear by changing these functions to take a VM& arg instead of an ExecState* or
        CallFrame*.

        Also removed the JS_EXPORT_PRIVATE attribute from Interpreter::StackFrame::toString().
        The JS_EXPORT_PRIVATE attribute was a holdover from the days when WebInspector
        was entirely in WebCore.  It is no longer needed.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::functionName):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::createScriptCallStackFromException):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::friendlyFunctionName):
        * interpreter/Interpreter.cpp:
        (JSC::StackFrame::friendlySourceURL):
        (JSC::StackFrame::friendlyFunctionName):
        (JSC::StackFrame::expressionInfo):
        (JSC::StackFrame::toString):
        (JSC::Interpreter::stackTraceAsString):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::functionName):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::displayName):
        (JSC::InternalFunction::getCallData):
        (JSC::InternalFunction::calculatedDisplayName):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::createStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::name):
        (JSC::JSFunction::displayName):
        (JSC::JSFunction::calculatedDisplayName):
        (JSC::JSFunction::getConstructData):
        (JSC::getCalculatedDisplayName):
        * runtime/JSFunction.h:
        (JSC::JSFunction::executable):
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):

2016-06-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Do not allocate unnecessary UTF-8 string for encodeXXX functions
        https://bugs.webkit.org/show_bug.cgi?id=158416

        Reviewed by Darin Adler and Geoffrey Garen.

        Previously, encodeXXX functions first allocate new UTF-8 string, and generate (& allocate) the results from this UTF-8 string.
        It is costly since this UTF-8 string is always wasted. In this patch, we generate the results without this UTF-8 string.
        We precisely implement ECMA262's Encode abstract operation[1].

        This optimized encodeXXX functions provide great improvement in kraken stanford-crypto-sha256-iterative since it frequently calls
        these functions. We can see 6 - 7% improvements.

                                                      baseline                  patched

        stanford-crypto-sha256-iterative           37.952+-0.155      ^      35.484+-0.265         ^ definitely 1.0695x faster


        [1]: https://tc39.github.io/ecma262/#sec-encode

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::toSafeView):
        Use this helper function to retrieve JSString::SafeView.

        (JSC::makeCharacterBitmap):
        (JSC::encode):
        In encode, we reserve N length buffer at first. This is important when the length of the given string is long enough,
        preventing frequent unnecessary buffer reallocations. This reserving contributes to 1% kraken stanford-crypto-sha256-iterative progression.

        (JSC::decode):
        Previously, Bitmap accidentally includes \0. And instead of removing this \0, we checked character != 0.
        This patch fixes it for the Bitmap not to include \0.

        (JSC::globalFuncParseInt):
        (JSC::globalFuncEscape):
        (JSC::globalFuncUnescape):
        * tests/stress/encode-decode-ascii.js: Added.
        (shouldBe):
        * tests/stress/encode-decode-unicode.js: Added.
        (shouldBe):
        (isLowSurrogate):
        (isHighSurrogate):
        (isSurrogate):
        * tests/stress/encode-decode-uri-component-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-uri-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-zero.js: Added.
        (shouldBe):
        * tests/stress/escape-unescape-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):

2016-06-07  Ting-Wei Lan  <lantw44@gmail.com>

        [GTK] Include locale.h before using LC_ALL
        https://bugs.webkit.org/show_bug.cgi?id=158470

        Reviewed by Darin Adler.

        * jsc.cpp:

2016-06-07  Joseph Pecoraro  <pecoraro@apple.com>

        Unskip generator related stress tests
        https://bugs.webkit.org/show_bug.cgi?id=158461

        Reviewed by Darin Adler.

        * tests/stress/generator-methods.js:
        * tests/stress/generator-syntax.js:
        * tests/stress/yield-and-line-terminator.js:
        * tests/stress/yield-label-generator.js:
        * tests/stress/yield-named-accessors-generator.js:
        * tests/stress/yield-named-variable-generator.js:
        * tests/stress/yield-out-of-generator.js:

2016-06-06  Joseph Pecoraro  <pecoraro@apple.com>

        Fix typo in test name trailing-comma-in-function-paramters.js
        https://bugs.webkit.org/show_bug.cgi?id=158462

        Reviewed by Mark Lam.

        * tests/stress/trailing-comma-in-function-parameters.js: Renamed from Source/JavaScriptCore/tests/stress/trailing-comma-in-function-paramters.js.

2016-06-06  Andreas Kling  <akling@apple.com>

        REGRESSION(r197595): 2% JSBench regression on iPhone 5.
        <https://webkit.org/b/158459>

        Unreviewed rollout.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllRegExpCode): Deleted.
        * runtime/VM.h:

2016-06-06  Michael Saboff  <msaboff@apple.com>

        octal and binary parsing is wrong for some programs
        https://bugs.webkit.org/show_bug.cgi?id=158437

        Reviewed by Saam Barati.

        When there is an error parsing an binary or octal literal, we need to clear the returnValue
        of any residual value.  This is because the processing of returnValue happens before the
        syntax check for the extra character.  Without clearing returnValue, we end trying to
        categorize the value as an INTEGER or DOUBLE token.  If the value happens to be an
        impure NaN, we ASSERT.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        * tests/stress/regress-158437.js: New test.

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

        32-bit JSC stress test failing: stress/recursive-try-catch.js.ftl-no-cjit-validate-sampling-profiler
        https://bugs.webkit.org/show_bug.cgi?id=158362

        Reviewed by Michael Saboff.

        The test does infinite recursion until it overflows the stack.  That means the
        sampling profiler will have to capture excessively large samples, which in turn
        makes it run very slowly.  This is what causes the test time out.

        The fix is to not run the test with the sampling profiler.

        * tests/stress/recursive-try-catch.js:

2016-06-06  Andreas Kling  <akling@apple.com>

        Don't reportAbandonedObjectGraph() after throwing out linked code or RegExps.
        <https://webkit.org/b/158444>

        Unreviewed.

        This is a speculative change for iOS performance bots. The calls to reportAbandonedObjectGraph
        were basically redundant, since mainframe navigation will cause GC acceleration anyway via
        ScriptController.

        This appears successful at recovering the ~0.7% regression I could reproduce locally on newer
        hardware but it's a bit too noisy to say for sure.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllLinkedCode):
        (JSC::VM::deleteAllRegExpCode):

2016-06-06  Skachkov Oleksandr  <gskachkov@gmail.com>
        [ESNext] Trailing commas in function parameters.
        https://bugs.webkit.org/show_bug.cgi?id=158020

        Reviewed by Keith Miller.

        ESNext allow to add trailing commas in function parameters and function arguments.
        Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
        Example of using - (function (a, b,) { return a + b; })(1,2,);

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseArguments):
        * tests/stress/trailing-comma-in-function-paramters.js: Added.

2016-06-05  Gavin & Ellie Barraclough  <barraclough@apple.com>

        Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead.
        https://bugs.webkit.org/show_bug.cgi?id=158178

        Reviewed by Darin Adler.

        As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be
        overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism.

        Deprecate getStatic* functions in Lookup.h

        * runtime/Lookup.h:
        (JSC::getStaticPropertySlot): Deleted.
        (JSC::getStaticFunctionSlot): Deleted.
        (JSC::getStaticValueSlot): Deleted.
            - No longer required. Static table access now via JSObject.

2016-06-06  Guillaume Emont  <guijemont@igalia.com>

        [jsc][mips] Implement absDouble()
        https://bugs.webkit.org/show_bug.cgi?id=158206

        Reviewed by Mark Lam.

        Implement absDouble() for MIPS. This is needed because Math.pow() uses
        it since r200208.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::absd):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::absDouble):

2016-06-03  Oliver Hunt  <oliver@apple.com>

        RegExp unicode parsing reads an extra character before failing
        https://bugs.webkit.org/show_bug.cgi?id=158376

        Reviewed by Saam Barati.

        This was a probably harmless bug, but keeps triggering assertions
        for me locally. Essentially we'd see a parse error, set the error
        type, but then carry on parsing. In debug builds this asserts, in
        release builds you are pretty safe unless you're exceptionally
        unlucky with where the error occurs.

        * yarr/YarrParser.h:
        (JSC::Yarr::Parser::parseEscape):

2016-06-06  Guillaume Emont  <guijemont@igalia.com>

        [jsc][mips] fix JIT::emit_op_log_shadow_chicken_prologue/_tail
        https://bugs.webkit.org/show_bug.cgi?id=158209

        Reviewed by Mark Lam.

        On MIPS, changes GPRInfo::nonArgGPR0 to be regT4 instead of regT0,
        since the code of JIT::emit_op_log_shadow_chicken_prologue/_tail()
        expects nonArgGPR0 to be a different register from regT0 and regT2.

        * jit/GPRInfo.h:

2016-06-06  Chris Dumez  <cdumez@apple.com>

        Crash under JSObject::getOwnPropertyDescriptor()
        https://bugs.webkit.org/show_bug.cgi?id=158382
        <rdar://problem/26605004>

        Reviewed by Mark Lam.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        We were crashing under getOwnPropertyDescriptor() because the
        CustomAccessor was not properly reset on window.statusbar when
        setting it to false (which is allowed because the property is
        marked as [Replaceable] in the IDL). We now property reset the
        CustomAccessor flag in putDirectInternal() when needed. This
        fixes the crash.

2016-06-06  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        [EFL] Move efl include paths to JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
        https://bugs.webkit.org/show_bug.cgi?id=158418

        Reviewed by Csaba Osztrogonác.

        In Source/JavaScriptCore/PlatformEfl.cmake, we don't use JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES
        for efl include paths.

        * PlatformEfl.cmake:
        * tests/stress/encode-decode-ascii.js: Added.
        (shouldBe):
        * tests/stress/encode-decode-unicode.js: Added.
        (shouldBe):
        (isLowSurrogate):
        (isHighSurrogate):
        (isSurrogate):
        * tests/stress/encode-decode-uri-component-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-uri-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):
        * tests/stress/encode-decode-zero.js: Added.
        (shouldBe):
        * tests/stress/escape-unescape-surrogates.js: Added.
        (shouldBe):
        (toHighSurrogate):
        (toLowSurrogate):

2016-06-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Change ProxyObject.[[Get]] not to use custom accessor
        https://bugs.webkit.org/show_bug.cgi?id=157080

        Reviewed by Darin Adler.

        This patch focuses on introducing the second part of the followings.
        But to do so, first and third parts are necessary.

        1. Insert missing exception checks for getPropertySlot.

            While getPropertySlot can perform user-observable behavior if the slot is not VMInquiry,
            several places miss exeption checks. For example, ProxyObject's hasProperty already can
            throw any errors. Looking through the code, we found several missing error checks after
            hasProperty, but this will be fixed in the separated patch[1].

        2. Do not use custom accessor to implement ProxyObject's [[Get]].

            The caller already allows getOwnPropertySlot to throw an exception if the type
            is not VMInquiry. So instead of using custom accessor, we simply implement it
            directly in the ProxyObject's method.

        3. Strip slotBase from custom accessor.

            The custom accessor should not be bound to the specific slot base[2], since it
            is just an accessor. There is an alternative design: makeing this custom accessor
            to custom value accessor and accept both the slot base and the receiver instead
            of allowing throwing an error from getOwnPropertySlot. But we take the first design
            that allows getPropertySlot to throw an error, since hasProperty (that does not call
            getValue of the custom getters) can already throw any errors.

            To query the property with the non-user-observable way, we already provided the way for that:
            use VMInquiry and isTaintedByProxy() instead.

        Tests just ensure that the current semantics works correctly after this patch.
        And this patch is performance neutral.

        Later, we will attempt to rename "thisValue" to "receiver"[3].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=158398
        [2]: https://bugs.webkit.org/show_bug.cgi?id=157978
        [3]: https://bugs.webkit.org/show_bug.cgi?id=158397

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * jsc.cpp:
        (WTF::ImpureGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::lengthGetter):
        (GlobalObject::finishCreation):
        (GlobalObject::moduleLoaderFetch):
        (functionGetGetterSetter):
        (functionRun):
        (functionLoad):
        (functionLoadString):
        (functionReadFile):
        (functionCheckSyntax):
        (functionLoadWebAssembly):
        (functionLoadModule):
        (functionCreateBuiltin):
        (functionCheckModuleSyntax):
        (dumpException):
        (runWithScripts):
        (runInteractive):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::boundSlotBaseFunctionCall):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::getPropertySlot):
        * runtime/JSCellInlines.h:
        (JSC::ExecState::vm):
        This change is super important for performance. We add several `exec->hadException()` calls into the super hot path, like JSC::operationGetByIdOptimize.
        Without this change, we call ExecState::vm() and it is not inlined. This causes 1 - 2% performance regression in Octane PDFJS.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::argumentsGetter):
        (JSC::JSFunction::callerGetter):
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::callbackGetter):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        Here's UNLIKELY is important for Kraken's json-stringify-tinderbox. Without it, we can observe 0.5% regression.

        (JSC::Walker::walk):
        * runtime/JSObject.h:
        (JSC::JSObject::getPropertySlot):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customGetter):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::thisValue):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performGet):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        * runtime/ProxyObject.h:
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpConstructorDollar):
        (JSC::regExpConstructorInput):
        (JSC::regExpConstructorMultiline):
        (JSC::regExpConstructorLastMatch):
        (JSC::regExpConstructorLastParen):
        (JSC::regExpConstructorLeftContext):
        (JSC::regExpConstructorRightContext):
        * tests/stress/get-from-scope-dynamic-onto-proxy.js: Added.
        (shouldBe):
        (shouldThrow.handler.has):
        (handler.has):
        (try.handler.has):
        * tests/stress/operation-in-throw-error.js: Added.
        (testCase.handler.has):
        (testCase):
        * tests/stress/proxy-and-json-stringify.js: Added.
        (shouldThrow):
        * tests/stress/proxy-and-typed-array.js: Added.
        * tests/stress/proxy-json-path.js: Added.
        * tests/stress/proxy-with-statement.js: Added.

2016-06-03  Gavin & Ellie Barraclough  <barraclough@apple.com>

        Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead.
        https://bugs.webkit.org/show_bug.cgi?id=158178

        Reviewed by Darin Adler.

        As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be
        overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism.

        Part 1: Switch JSGlobalObject & JSDOMWindow to use HasStaticPropertyTable.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::getOwnPropertySlot):
            - Override is still required for symbol table,
              but regular property access is now via Base::getOwnPropertySlot.
        * runtime/JSGlobalObject.h:
            - add HasStaticPropertyTable to structureFlags.

2016-06-03  Benjamin Poulain  <bpoulain@apple.com>

        Eager FTL failure for strict comparison of NaN with number check
        https://bugs.webkit.org/show_bug.cgi?id=158368

        Reviewed by Darin Adler.

        DoupleRep with a RealNumberUse starts by handling double
        then falls back to Int32 if the unboxed double is NaN.

        Before handling integers, the code is checking if the input
        is indeed an int32. The problem was that this check failed
        to account for NaN as an original input of the DoubleRep.

        The call to isNotInt32() filter the doubles checks because
        that was handled by the previous block.
        The problem is the previous block handles any double except NaN.
        If the original input was NaN, the masking by "~SpecFullDouble"
        filter that possibility and isNotInt32() fails to test that case.

        This patch fixes the issue by changing the filter to SpecDoubleReal.
        The type SpecDoubleReal does not include the NaN types.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
        * tests/stress/double-rep-real-number-use-on-nan.js: Added.
        To ensure the isNotInt32() does not test anything, we want
        proven numbers as input. The (+value) are there to enforce
        a ToNumber() which in turn give us a proven Number type.

2016-06-03  Benjamin Poulain  <bpoulain@apple.com>

        JSON.stringify replacer function calls with numeric array indices
        https://bugs.webkit.org/show_bug.cgi?id=158262
        rdar://problem/26613876

        Reviewed by Saam Barati.

        The spec of SerializeJSONArray is pretty clear that the index
        should be transformed into a string before calling SerializeJSONProperty.
        See http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray

        * runtime/JSONObject.cpp:
        (JSC::PropertyNameForFunctionCall::value):

2016-06-03  Saam barati  <sbarati@apple.com>

        Proxy.ownKeys should no longer throw an exception when duplicate keys are returned and the target is non-extensible
        https://bugs.webkit.org/show_bug.cgi?id=158350
        <rdar://problem/26626211>

        Reviewed by Michael Saboff.

        The spec was recently changes in Proxy [[OwnPropertyKeys]]
        to allow for duplicate property names under certain circumstances.
        This patch fixes our implementation to match the spec.
        See: https://github.com/tc39/ecma262/pull/594

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):
        * tests/stress/proxy-own-keys.js:
        (i.catch):
        (ownKeys):
        (assert):

2016-06-03  Saam barati  <sbarati@apple.com>

        Some shadow chicken code is wrong when run on a big endian CPU
        https://bugs.webkit.org/show_bug.cgi?id=158361

        Reviewed by Mark Lam.

        This code was wrong on a big endian CPU, and it was
        also an anti-pattern in the file. The code was harmless
        on a little endian CPU, but it's better to remove it.

        * llint/LowLevelInterpreter64.asm:

2016-06-03  Keith Miller  <keith_miller@apple.com>

        Add argument_count bytecode for concat
        https://bugs.webkit.org/show_bug.cgi?id=158358

        Reviewed by Geoffrey Garen.

        This patch adds a new argument count bytecode. Normally, we would
        just make sure that the argument.length bytecode was fast enough
        that we shouldn't need such an bytecode.  However, for the case of
        Array.prototype.concat the overhead of the arguments object
        allocation in the LLInt was too high and caused regressions.

        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArgumentCount):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_argument_count):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/argument-count-bytecode.js: Added.
        (inlineCount):
        (inlineCount1):
        (inlineCount2):
        (inlineCountVarArgs):
        (assert):

2016-06-03  Geoffrey Garen  <ggaren@apple.com>

        Clients of PolymorphicAccess::addCases shouldn't have to malloc
        https://bugs.webkit.org/show_bug.cgi?id=158357

        Reviewed by Keith Miller.

        We only ever have 1 or 2 cases, so we can use inline Vector capacity.

        This shows up a little in the JSBench profile.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::addCases):
        (JSC::PolymorphicAccess::addCase):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):

2016-06-03  Benjamin Poulain  <bpoulain@apple.com>

        Fix some more INFINITI->INFINITY typos

        Unreviewed.

        The tests were not covering the edge cases they were supposed to test.

        * tests/stress/math-ceil-basics.js:
        (testMathCeilOnConstants):
        * tests/stress/math-clz32-basics.js:
        (testMathClz32OnDoubles):
        (testMathClz32OnConstants):
        * tests/stress/math-floor-basics.js:
        (testMathFloorOnConstants):
        * tests/stress/math-round-basics.js:
        (testMathRoundOnConstants):
        * tests/stress/math-trunc-basics.js:
        (testMathTruncOnConstants):

2016-06-02  Gavin & Ellie Barraclough  <barraclough@apple.com>

        JSGlobalObject::addFunction should call deleteProperty rather than removeDirect
        https://bugs.webkit.org/show_bug.cgi?id=158295

        Reviewed by Saam Barati.

        When a function in declared in program code, this replaces any previosly existing
        property from the global object. JSGlobalObject::addFunction is currently calling
        removeDirect rather than deleteProperty to remove the existing property. This fails
        to remove any properties from static tables.

        We currently get away with this because (a) JSObject & JSGlobalObject don't currently
        have any properties in static tables, and (b) the current quirky property precedence
        means that the symbol table properties end up taking precedence over JSDOMWindow's
        static table, so window object properties end up being shadowed.

        As a part of bug #158178 the precedence of static tables will change, requiring this
        to be fixed.

        The deleteProperty function does what we want (has the ability to remove properties,
        including those from the static tables). Normally deleteProperty will not remove
        properties that are non-configurable (DontDelete) - we need to do so. The function
        does already support this, through a flag on VM named 'isInDefineOwnProperty', which
        causes configurability to be ignored. Generalize this mechanism for use outside of
        defineOwnProperty, renaming & moving DefineOwnPropertyScope helper class out to VM.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::deleteProperty):
            - isInDefineOwnProperty -> deletePropertyMode.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addFunction):
            - removeDirect -> deleteProperty.
        * runtime/JSObject.cpp:
        (JSC::JSObject::deleteProperty):
            - isInDefineOwnProperty -> deletePropertyMode.
        (JSC::JSObject::defineOwnNonIndexProperty):
            - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
        (JSC::DefineOwnPropertyScope::DefineOwnPropertyScope): Deleted.
        (JSC::DefineOwnPropertyScope::~DefineOwnPropertyScope): Deleted.
            - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
        * runtime/VM.cpp:
        (JSC::VM::VM):
            - removed m_inDefineOwnProperty.
        * runtime/VM.h:
        (JSC::VM::deletePropertyMode):
            - isInDefineOwnProperty -> deletePropertyMode.
        (JSC::VM::DeletePropertyModeScope::DeletePropertyModeScope):
        (JSC::VM::DeletePropertyModeScope::~DeletePropertyModeScope):
            - DefineOwnPropertyScope -> VM::DeletePropertyModeScope.
        (JSC::VM::setInDefineOwnProperty): Deleted.
            - Replaced with deletePropertyMode, can now only be set via VM::DeletePropertyModeScope.
        (JSC::VM::isInDefineOwnProperty): Deleted.
            - isInDefineOwnProperty -> deletePropertyMode.

2016-06-03  Mark Lam  <mark.lam@apple.com>

        ARMv7 vstm and vldm instructions can only operate on a maximum of 16 registers.
        https://bugs.webkit.org/show_bug.cgi?id=158349

        Reviewed by Filip Pizlo.

        According to the ARM Assembler Reference, the vstm and vldm instructions can only
        operate on a maximum of 16 registers.  See
        http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html
        and http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html.

        The ARMv7 probe code was wrongly using these instructions to store and load all
        32 'd' registers.  This is now fixed.

        * assembler/MacroAssemblerARMv7.cpp:

2016-06-03  Mark Lam  <mark.lam@apple.com>

        Gardening: CLOOP build fix (needs a #include).

        Not reviewed.

        * interpreter/StackVisitor.h:

2016-06-03  Andreas Kling  <akling@apple.com>

        Eliminate two large sources of temporary StringImpl objects.
        <https://webkit.org/b/158336>

        Reviewed by Anders Carlsson.

        We were jumping through some inefficient hoops when creating Identifiers due to the
        convenience of our String(const char*) constructor.

        This patch avoids just over 1 million temporary StringImpl objects on the PLUM benchmark.

        * runtime/JSObject.h:
        (JSC::makeIdentifier): Add an overload for string literals so we can stop creating a temporary
        String just for passing to Identifier::fromString().

        * runtime/Lookup.h:
        (JSC::reifyStaticProperties): Use the Identifier::fromString() that takes an LChar* and a length
        instead of creating a temporary String.

2016-06-03  Mark Lam  <mark.lam@apple.com>

        Clean up how StackVisitor dumps its frames.
        https://bugs.webkit.org/show_bug.cgi?id=158316

        Reviewed by Keith Miller.

        1. Updated to do dumping to a PrintStream.
        2. Added support for printing a prefix for each frame.
           This is currently used by JSDollarVMPrototype to print frame numbers.
        3. Fix the incrementing of the frame index in StackVisitor.
           It was initialized but never incremented before when iterating the frames.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::Frame::codeType):
        (JSC::StackVisitor::Frame::functionName):
        (JSC::StackVisitor::Frame::sourceURL):
        (JSC::StackVisitor::Frame::toString):
        (JSC::StackVisitor::Frame::createArguments):
        (JSC::StackVisitor::Frame::computeLineAndColumn):
        (JSC::StackVisitor::Frame::retrieveExpressionInfo):
        (JSC::StackVisitor::Frame::setToEnd):
        (JSC::StackVisitor::Frame::dump):
        (JSC::StackVisitor::Indent::dump):
        (JSC::printIndents): Deleted.
        (JSC::log): Deleted.
        (JSC::logF): Deleted.
        (JSC::StackVisitor::Frame::print): Deleted.
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Indent::Indent):
        (JSC::StackVisitor::Indent::operator++):
        (JSC::StackVisitor::Indent::operator--):
        (JSC::StackVisitor::Frame::isJSFrame):
        (JSC::StackVisitor::Frame::isInlinedFrame):
        (JSC::StackVisitor::Frame::vmEntryFrame):
        (JSC::StackVisitor::Frame::callFrame):
        (JSC::StackVisitor::Frame::Frame):
        (JSC::StackVisitor::Frame::~Frame):
        * tools/JSDollarVMPrototype.cpp:
        (JSC::PrintFrameFunctor::operator()):

2016-06-02  Saam Barati  <sbarati@apple.com>

        global lexical environment variables are not accessible through functions created using the function constructor
        https://bugs.webkit.org/show_bug.cgi?id=158319

        Reviewed by Filip Pizlo.

        When creating a function using the Function constructor, we were
        using the global object instead of the global lexical environment
        as the function's scope. We should be using the global lexical environment.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * tests/stress/function-constructor-reading-from-global-lexical-environment.js: Added.
        (assert):
        (test):
        (ClassTDZ):

2016-06-02  Oliver Hunt  <oliver@apple.com>

        JS parser incorrectly handles invalid utf8 in error messages.
        https://bugs.webkit.org/show_bug.cgi?id=158128

        Reviewed by Saam Barati.

        The bug here was caused by us using PrintStream's toString method
        to produce the error message for a parse error, even though toString
        may produce a null string in the event of invalid utf8 that causes
        the error in first case. So when we try to create an error message
        containing the invalid character code, we set m_errorMessage to the
        null string, as that signals "no error" we don't stop parsing, and
        everything goes down hill from there.

        Now we use the new toStringWithLatin1Fallback so that we can always
        produce an error message, even if it contains invalid unicode. We
        also add an additional fallback so that we can guarantee an error
        message is set even if we're given a null string. There's a debug
        mode assertion to prevent anyone accidentally attempting to clear
        the message via setErrorMessage.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::logError):
        * parser/Parser.h:
        (JSC::Parser::setErrorMessage):

2016-06-02  Saam Barati  <sbarati@apple.com>

        Teach bytecode liveness about the debugger
        https://bugs.webkit.org/show_bug.cgi?id=158288

        Reviewed by Filip Pizlo.

        There was a bug where we wouldn't always keep the scope register
        on the stack when the debugger is enabled. The debugger always assumes
        it can read from the scope. The bug happened in OSR exit from the FTL.
        The FTL uses bytecode liveness for OSR exit. Bytecode liveness proved
        that the scope register was dead, so the FTL OSR exit wrote `undefined`
        into the scope's stack slot when OSR exiting to the baseline.

        To fix this, I taught bytecode liveness' computeUsesForBytecodeOffset() that the
        scope is used by every instruction except op_enter. This causes the
        scope to be live-in at every instruction except op_enter.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::blockContainsBytecodeOffset):
        (JSC::addAlwaysLiveLocals):
        (JSC::findBasicBlockForBytecodeOffset):
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * tests/stress/shadow-chicken-reading-from-scope-after-ftl-osr-exit-bytecode-liveness.js: Added.
        (foo):
        (catch):

2016-06-02  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r200694): %ThrowTypeError% is not unique
        https://bugs.webkit.org/show_bug.cgi?id=158231

        Reviewed by Joseph Pecoraro.

        The ES6 standard in section 9.2.7.1 states that %ThrowTypeError% is unique.  This
        change reverts the handling of TypeError before r200694 and then rolls in
        throwTypeErrorGetterSetter() with the renamed throwTypeErrorArgumentsCalleeAndCallerGetterSetter().

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSFunction.cpp:
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter): Deleted.
        (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter): Deleted.
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter): Deleted.
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncThrowTypeError):
        (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
        (JSC::globalFuncThrowTypeErrorCalleeAndCaller): Deleted.
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode): Deleted.
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        * tests/stress/reflect-set.js:

2016-06-02  Michael Saboff  <msaboff@apple.com>

        [iOS]: Some JSC stress tests fail running out of executable memory when the LLInt is disabled
        https://bugs.webkit.org/show_bug.cgi?id=158317

        Reviewed by Saam Barati.

        Updated these test to not run the "no-llint" variant when running on ARM machines.

        * tests/stress/arrowfunction-lexical-bind-superproperty.js: Skip no-llint for ARM
        (testCase):
        * tests/stress/proxy-revoke.js: Skipp no-lint for ARM and ARM64
        (assert):

2016-06-02  Keith Miller  <keith_miller@apple.com>

        Unreviewed, reland r201532. The associated regressions have been fixed
        by r201584.

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

        Use "= delete" for Locker(int) 

        Rubber stamped by Saam Barati.

        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

2016-06-02  Keith Miller  <keith_miller@apple.com>

        ObjectPropertyCondition should have a isStillValidAssumingImpurePropertyWatchpoint function
        https://bugs.webkit.org/show_bug.cgi?id=158308

        Reviewed by Filip Pizlo.

        Recently, structureEnsuresValidityAssumingImpurePropertyWatchpoint was converted to check
        what should be isStillValidAssumingImpurePropertyWatchpoint. This patch fixes the API so
        it should work as expected. This patch also changes generateConditions in
        ObjectPropertyConditionSet to use isStillValidAssumingImpurePropertyWatchpoint.

        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
        (JSC::ObjectPropertyCondition::isStillValidAssumingImpurePropertyWatchpoint):
        * bytecode/ObjectPropertyCondition.h:
        * bytecode/ObjectPropertyConditionSet.cpp:

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

        Make it harder to accidentally pass an integer to a locker.

        Rubber stamped by Keith Miller.

        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

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

        Make it easier to use NoLockingNecessary
        https://bugs.webkit.org/show_bug.cgi?id=158306

        Reviewed by Keith Miller.
        
        Adapt to the new NoLockingNecessary API. More details in the WTF ChangeLog.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

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

        Structure::previousID() races with Structure::allocateRareData()
        https://bugs.webkit.org/show_bug.cgi?id=158280

        Reviewed by Mark Lam.
        
        The problem is that previousID() would test hasRareData() and then either load the
        previous Structure from the rare data, or load it directly. allocateRareData() would set
        the hasRareData() bit separately from moving the Structure pointer into the rare data. So
        we'd have a race that would cause previousID() to sometimes return the rarae data instead
        of the previous Structure.

        The fix is to get rid of the hasRareData bit. We can use the structureID of the
        previousOrRareData cell to determine if it's the previousID or the RareData. This fixes the
        race and it's probably not any slower.

        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::allocateRareData):
        * runtime/Structure.h:

2016-06-01  Michael Saboff  <msaboff@apple.com>

        Runaway WebContent process CPU & memory @ foxnews.com
        https://bugs.webkit.org/show_bug.cgi?id=158290

        Reviewed by Mark Lam.

        Clear the thrown value at the end of the catch block so that the stack scanner won't
        find the value during GC.

        Added a new stress test.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):
        * tests/stress/recursive-try-catch.js: Added.
        (logError):
        (tryCallingBadFunction):
        (recurse):
        (test):

2016-06-01  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Some setters for components of Date do not timeClip() their result
        https://bugs.webkit.org/show_bug.cgi?id=158278
        rdar://problem/25131426

        Reviewed by Geoffrey Garen.

        Many of the setters where not doing timeClip() on the computed UTC
        time since Epoch.

        See http://www.ecma-international.org/ecma-262/6.0/#sec-date.prototype.setdate
        and the following sections for the definition.

        * runtime/DatePrototype.cpp:
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):

2016-06-01  Keith Miller  <keith_miller@apple.com>

        canOptimizeStringObjectAccess should use ObjectPropertyConditions rather than structure watchpoints
        https://bugs.webkit.org/show_bug.cgi?id=158291

        Reviewed by Benjamin Poulain.

        The old StringObject primitive access code used structure watchpoints. This meant that
        if you set a watchpoint on String.prototype prior to tiering up to the DFG then added
        a new property to String.prototype then we would never use StringObject optimizations.
        This made property caching in the LLInt bad because it meant we would watchpoint
        String.prototype very early in the program, which hurt date-format-xpab.js since that
        benchmark relies on the StringObject optimizations.

        This patch also extends ObjectPropertyConditionSet to be able to handle a slotBase
        equivalence condition. Since that makes the code for generating the DFG watchpoints
        significantly cleaner.

        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint):
        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition):
        (JSC::ObjectPropertyConditionSet::slotBaseCondition):
        (JSC::generateConditionsForPrototypeEquivalenceConcurrently):
        * bytecode/ObjectPropertyConditionSet.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isStringPrototypeMethodSane):
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.h:

2016-06-01  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling in r201436.
        https://bugs.webkit.org/show_bug.cgi?id=158143

        r201562 should haved fixed the Dromaeo DOM core regression.

        Restored changeset:

        "REGRESSION: JSBench spends a lot of time transitioning
        to/from dictionary"
        https://bugs.webkit.org/show_bug.cgi?id=158045
        http://trac.webkit.org/changeset/201436


2016-06-01  Commit Queue  <commit-queue@webkit.org>

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

        Caused 23% regression on JetStream's crypto-md5 (Requested by
        rniwa on #webkit).

        Reverted changeset:

        "[ESNext] Support trailing commas in function param lists"
        https://bugs.webkit.org/show_bug.cgi?id=158020
        http://trac.webkit.org/changeset/201488

2016-05-31  Geoffrey Garen  <ggaren@apple.com>

        Dictionary property access should be fast
        https://bugs.webkit.org/show_bug.cgi?id=158250

        Reviewed by Keith Miller.

        We have some remnant code that unnecessarily takes a slow path for
        dictionaries. This caused the Dromaeo regression in r201436. Let's fix
        that.

        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID): Attempt to flatten a dictionary if necessary, but
        not too much. This is our idiom in other places.

        (JSC::tryCachePutByID): See tryCacheGetByID.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache): See tryCacheGetByID.

        * runtime/JSObject.cpp:
        (JSC::JSObject::fillGetterPropertySlot):
        * runtime/JSObject.h:
        (JSC::JSObject::fillCustomGetterPropertySlot): The rules for caching a
        getter are the same as the rules for caching anything else: We're
        allowed to cache even in dictionaries, as long as they're cacheable
        dictionaries. Any transition that would change to/from getter/setter
        or change other attributes requires a structure transition.

2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Drop "replace" from JSC_COMMON_PRIVATE_IDENTIFIERS_EACH_WELL_KNOWN_SYMBOL_NOT_IMPLEMENTED_YET
        https://bugs.webkit.org/show_bug.cgi?id=158223

        Reviewed by Darin Adler.

        This list maintains "not implemented yet" well-known symbols.
        `Symbol.replace` is already implemented.

        * runtime/CommonIdentifiers.h:

2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, roll out r201481, r201523: 0.3% regression in Octane code-load
        https://bugs.webkit.org/show_bug.cgi?id=158249

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/AsyncFunctionPrototype.js: Removed.
        (asyncFunctionResume): Deleted.
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction): Deleted.
        (JSC::UnlinkedCodeBlock::isAsyncArrowFunction): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewMethodDefinition):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): Deleted.
        (JSC::BytecodeGenerator::emitNewFunction): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode): Deleted.
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon): Deleted.
        (JSC::JIT::emit_op_new_async_func): Deleted.
        (JSC::JIT::emitNewFuncExprCommon): Deleted.
        (JSC::JIT::emit_op_new_async_func_exp): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (runInteractive):
        (printUsageStatement): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAsyncFunctionBody): Deleted.
        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements): Deleted.
        (JSC::Parser<LexerType>::parseVariableDeclarationList): Deleted.
        (JSC::Parser<LexerType>::parseDestructuringPattern): Deleted.
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement): Deleted.
        (JSC::Parser<LexerType>::parseFormalParameters): Deleted.
        (JSC::stringForFunctionMode): Deleted.
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): Deleted.
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement): Deleted.
        (JSC::Parser<LexerType>::parseAwaitExpression): Deleted.
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression): Deleted.
        (JSC::Parser<LexerType>::parseUnaryExpression): Deleted.
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        (JSC::Parser::matchSpecIdentifier):
        (JSC::parse):
        (JSC::Scope::setSourceParseMode): Deleted.
        (JSC::Scope::isAsyncFunction): Deleted.
        (JSC::Scope::isAsyncFunctionBoundary): Deleted.
        (JSC::Scope::isModule): Deleted.
        (JSC::Scope::setIsFunction): Deleted.
        (JSC::Scope::setIsAsyncArrowFunction): Deleted.
        (JSC::Scope::setIsAsyncFunction): Deleted.
        (JSC::Scope::setIsAsyncFunctionBody): Deleted.
        (JSC::Scope::setIsAsyncArrowFunctionBody): Deleted.
        (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError): Deleted.
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction): Deleted.
        (JSC::Parser::forceClassifyExpressionError): Deleted.
        (JSC::Parser::declarationTypeToVariableKind): Deleted.
        (JSC::Parser::upperScope): Deleted.
        (JSC::Parser::isDisallowedIdentifierAwait): Deleted.
        (JSC::Parser::disallowedIdentifierAwaitReason): Deleted.
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::SourceParseModeSet::SourceParseModeSet): Deleted.
        (JSC::SourceParseModeSet::contains): Deleted.
        (JSC::SourceParseModeSet::mergeSourceParseModes): Deleted.
        (JSC::isAsyncFunctionParseMode): Deleted.
        (JSC::isAsyncArrowFunctionParseMode): Deleted.
        (JSC::isAsyncFunctionWrapperParseMode): Deleted.
        (JSC::isAsyncFunctionBodyParseMode): Deleted.
        (JSC::constructAbilityForParseMode): Deleted.
        * parser/ParserTokens.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator==):
        (JSC::SourceCodeKey::runtimeFlags): Deleted.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createAsyncFunctionBody): Deleted.
        * runtime/AsyncFunctionConstructor.cpp: Removed.
        (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor): Deleted.
        (JSC::AsyncFunctionConstructor::finishCreation): Deleted.
        (JSC::callAsyncFunctionConstructor): Deleted.
        (JSC::constructAsyncFunctionConstructor): Deleted.
        (JSC::AsyncFunctionConstructor::getCallData): Deleted.
        (JSC::AsyncFunctionConstructor::getConstructData): Deleted.
        * runtime/AsyncFunctionConstructor.h: Removed.
        (JSC::AsyncFunctionConstructor::create): Deleted.
        (JSC::AsyncFunctionConstructor::createStructure): Deleted.
        * runtime/AsyncFunctionPrototype.cpp: Removed.
        (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype): Deleted.
        (JSC::AsyncFunctionPrototype::finishCreation): Deleted.
        * runtime/AsyncFunctionPrototype.h: Removed.
        (JSC::AsyncFunctionPrototype::create): Deleted.
        (JSC::AsyncFunctionPrototype::createStructure): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Completion.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/JSAsyncFunction.cpp: Removed.
        (JSC::JSAsyncFunction::JSAsyncFunction): Deleted.
        (JSC::JSAsyncFunction::createImpl): Deleted.
        (JSC::JSAsyncFunction::create): Deleted.
        (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint): Deleted.
        * runtime/JSAsyncFunction.h: Removed.
        (JSC::JSAsyncFunction::allocationSize): Deleted.
        (JSC::JSAsyncFunction::createStructure): Deleted.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::init): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::asyncFunctionPrototype): Deleted.
        (JSC::JSGlobalObject::asyncFunctionStructure): Deleted.
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/RuntimeFlags.h:
        (JSC::RuntimeFlags::operator==): Deleted.
        (JSC::RuntimeFlags::operator!=): Deleted.
        * tests/stress/async-await-basic.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrow): Deleted.
        (shouldThrowAsync): Deleted.
        (shouldThrowSyntaxError): Deleted.
        (let.AsyncFunction.async): Deleted.
        (async.asyncFunctionForProto): Deleted.
        (Object.getPrototypeOf.async): Deleted.
        (Object.getPrototypeOf.async.method): Deleted.
        (async): Deleted.
        (async.method): Deleted.
        (async.asyncNonConstructorDecl): Deleted.
        (shouldThrow.new.async): Deleted.
        (shouldThrow.new.async.nonConstructor): Deleted.
        (async.asyncDecl): Deleted.
        (async.f): Deleted.
        (MyError): Deleted.
        (async.asyncDeclThrower): Deleted.
        (shouldThrowAsync.async): Deleted.
        (resolveLater): Deleted.
        (rejectLater): Deleted.
        (async.resumeAfterNormal): Deleted.
        (O.async.resumeAfterNormal): Deleted.
        (resumeAfterNormalArrow.async): Deleted.
        (async.resumeAfterThrow): Deleted.
        (O.async.resumeAfterThrow): Deleted.
        (resumeAfterThrowArrow.async): Deleted.
        (catch): Deleted.
        * tests/stress/async-await-module-reserved-word.js: Removed.
        (shouldThrow): Deleted.
        (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await): Deleted.
        (checkModuleSyntaxError.String.raw.await): Deleted.
        (checkModuleSyntaxError.String.raw.async.await): Deleted.
        (SyntaxError.Cannot.declare.named): Deleted.
        * tests/stress/async-await-mozilla.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrow): Deleted.
        (shouldThrowAsync): Deleted.
        (assert): Deleted.
        (shouldThrowSyntaxError): Deleted.
        (mozSemantics.async.empty): Deleted.
        (mozSemantics.async.simpleReturn): Deleted.
        (mozSemantics.async.simpleAwait): Deleted.
        (mozSemantics.async.simpleAwaitAsync): Deleted.
        (mozSemantics.async.returnOtherAsync): Deleted.
        (mozSemantics.async.simpleThrower): Deleted.
        (mozSemantics.async.delegatedThrower): Deleted.
        (mozSemantics.async.tryCatch): Deleted.
        (mozSemantics.async.tryCatchThrow): Deleted.
        (mozSemantics.async.wellFinally): Deleted.
        (mozSemantics.async.finallyMayFail): Deleted.
        (mozSemantics.async.embedded.async.inner): Deleted.
        (mozSemantics.async.embedded): Deleted.
        (mozSemantics.async.fib): Deleted.
        (mozSemantics.async.isOdd.async.isEven): Deleted.
        (mozSemantics.async.isOdd): Deleted.
        (mozSemantics.hardcoreFib.async.fib2): Deleted.
        (mozSemantics.namedAsyncExpr.async.simple): Deleted.
        (mozSemantics.async.executionOrder.async.first): Deleted.
        (mozSemantics.async.executionOrder.async.second): Deleted.
        (mozSemantics.async.executionOrder.async.third): Deleted.
        (mozSemantics.async.executionOrder): Deleted.
        (mozSemantics.async.miscellaneous): Deleted.
        (mozSemantics.thrower): Deleted.
        (mozSemantics.async.defaultArgs): Deleted.
        (mozSemantics.shouldThrow): Deleted.
        (mozSemantics): Deleted.
        (mozMethods.X): Deleted.
        (mozMethods.X.prototype.async.getValue): Deleted.
        (mozMethods.X.prototype.setValue): Deleted.
        (mozMethods.X.prototype.async.increment): Deleted.
        (mozMethods.X.prototype.async.getBaseClassName): Deleted.
        (mozMethods.X.async.getStaticValue): Deleted.
        (mozMethods.Y.prototype.async.getBaseClassName): Deleted.
        (mozMethods.Y): Deleted.
        (mozFunctionNameInferrence.async.test): Deleted.
        (mozSyntaxErrors): Deleted.
        * tests/stress/async-await-reserved-word.js: Removed.
        (assert): Deleted.
        (shouldThrowSyntaxError): Deleted.
        (AsyncFunction.async): Deleted.
        * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrowAsync): Deleted.
        (noArgumentsArrow2.async): Deleted.
        * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (shouldThrowAsync): Deleted.
        (C1): Deleted.
        (C2): Deleted.
        (shouldThrowAsync.async): Deleted.
        * tests/stress/async_arrow_functions_lexical_super_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (BaseClass.prototype.baseClassValue): Deleted.
        (BaseClass.prototype.get property): Deleted.
        (BaseClass): Deleted.
        (ChildClass.prototype.asyncSuperProp): Deleted.
        (ChildClass.prototype.asyncSuperProp2): Deleted.
        (ChildClass): Deleted.
        (ChildClass2): Deleted.
        * tests/stress/async_arrow_functions_lexical_this_binding.js: Removed.
        (shouldBe): Deleted.
        (shouldBeAsync): Deleted.
        (d.y): Deleted.

2016-05-31  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r201363 and r201456.
        https://bugs.webkit.org/show_bug.cgi?id=158240

        "40% regression on date-format-xparb" (Requested by
        keith_miller on #webkit).

        Reverted changesets:

        "LLInt should be able to cache prototype loads for values in
        GetById"
        https://bugs.webkit.org/show_bug.cgi?id=158032
        http://trac.webkit.org/changeset/201363

        "get_by_id should support caching unset properties in the
        LLInt"
        https://bugs.webkit.org/show_bug.cgi?id=158136
        http://trac.webkit.org/changeset/201456

2016-05-31  Commit Queue  <commit-queue@webkit.org>

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

        "It was not a speedup on anything" (Requested by saamyjoon on
        #webkit).

        Reverted changeset:

        "We can cache lookups to JSScope::abstractResolve inside
        CodeBlock::finishCreation"
        https://bugs.webkit.org/show_bug.cgi?id=158036
        http://trac.webkit.org/changeset/201359

2016-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Recover parser performance regression by async support
        https://bugs.webkit.org/show_bug.cgi?id=158228

        Reviewed by Saam Barati.

        This patch recovers parser performance regression caused in r201481.

        Compared to the version that reverts r201481, still ~1% regression remains.
        But compared to ToT, this patch significantly improves the code-load performance.

        In Linux x64 JSCOnly port, with GCC 5.3.1.

        reverted v.s. patched.
                                 reverted                  patched

        closure              0.61805+-0.00376    ?     0.62280+-0.00525       ?
        jquery               8.03778+-0.02114          8.03453+-0.04646

        <geometric>          2.22883+-0.00836    ?     2.23688+-0.00995       ? might be 1.0036x slower

        ToT v.s. patched.
                                 baseline                  patched

        closure              0.65490+-0.00351    ^     0.62473+-0.00363       ^ definitely 1.0483x faster
        jquery               8.25373+-0.06256    ^     8.04701+-0.03455       ^ definitely 1.0257x faster

        <geometric>          2.32488+-0.00921    ^     2.24210+-0.00592       ^ definitely 1.0369x faster

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        Extend SourceParseMode.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        Do not call `matchSpecIdentifier()` as much as we can. This greatly improves the performance.

        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        Do not touch `currentScope()->isGenerator()` even if it is unnecessary in parseFunctionInfo.
        And accidental `syntaxChecker => context` changes are fixed.

        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        Do not use matchSpecIdentifier() in the hot paths.

        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText): Deleted.
        * parser/Parser.h:
        (JSC::isIdentifierOrKeyword):
        AWAIT shoud be one of the keywords. This AWAIT check is unnecessary.

        (JSC::Parser::upperScope):
        (JSC::Parser::matchSpecIdentifier):
        Touching currentScope() and its member causes significant performance degradation.
        We carefully remove the above access in the hot paths.

        (JSC::Parser::isDisallowedIdentifierAwait):
        * parser/ParserModes.h:
        (JSC::SourceParseModeSet::SourceParseModeSet):
        (JSC::SourceParseModeSet::contains):
        (JSC::SourceParseModeSet::mergeSourceParseModes):
        (JSC::isFunctionParseMode):
        (JSC::isAsyncFunctionParseMode):
        (JSC::isAsyncArrowFunctionParseMode):
        (JSC::isAsyncFunctionWrapperParseMode):
        (JSC::isAsyncFunctionBodyParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::constructAbilityForParseMode):
        The parser frequently checks SourceParseMode. And variety of SourceParseMode becomes many.
        So using switch onto SourceParseMode degrades the performance. Instead, we use bit tests to guard against
        many SourceParseModes. We expect that this will be efficiently compiled into test & jmp.

        * parser/ParserTokens.h:
        Change AWAIT to one of the keywords, as the same to YIELD / LET.

2016-05-31  Saam Barati  <sbarati@apple.com>

        Web Inspector: capturing with Allocations timeline causes GC to take 100x longer and cause frame drops
        https://bugs.webkit.org/show_bug.cgi?id=158054
        <rdar://problem/25280762>

        Reviewed by Joseph Pecoraro.

        HeapSnapshot::sweepCell was taking a long time on 
        http://bl.ocks.org/syntagmatic/6c149c08fc9cde682635
        because it has to do a binary search to find if
        an item is or is not in the list. 90% of the binary searches
        would not find anything. This resulted in a lot of wasted time.

        This patch adds a TinyBloomFilter member variable to HeapSnapshot.
        We use this filter to try to bypass doing a binary search when the
        filter tells us that a particular JSCell is definitely not in our
        list. This is a 2x speedup on the steady state GC of the above
        website.

        * heap/HeapSnapshot.cpp:
        (JSC::HeapSnapshot::appendNode):
        (JSC::HeapSnapshot::sweepCell):
        (JSC::HeapSnapshot::shrinkToFit):
        (JSC::HeapSnapshot::nodeForCell):
        * heap/HeapSnapshot.h:

2016-05-29  Saam barati  <sbarati@apple.com>

        Stack overflow crashes with deep or cyclic proxy prototype chains
        https://bugs.webkit.org/show_bug.cgi?id=157087

        Reviewed by Filip Pizlo and Mark Lam.

        Because a Proxy can call back into the JS runtime in arbitrary
        ways, we may have effectively cyclic prototype chains and property lookups
        by using a Proxy. We may also have arbitrarily long Proxy chains
        where we call into a C frame for each link in the Proxy chain.
        This means that every Proxy hook must be aware that it can stack overflow.
        Before, only certain hooks were aware of this fact. That was a bug,
        all hooks must assume they can stack overflow.

        Also, because we may have effectively cyclic prototype chains, we
        compile ProxyObject.cpp with -fno-optimize-sibling-calls. This prevents
        tail call optimization from happening on any of the calls from
        ProxyObject.cpp. We do this because we rely on the machine stack
        growing for throwing a stack overflow error. It's better for developers
        to be able to see a stack overflow error than to have their program
        infinite loop because the compiler performed TCO.

        This patch also fixes a couple call sites of various methods
        where we didn't check for an exception.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/JSArray.h:
        (JSC::getLength):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performGetOwnPropertyNames):
        (JSC::ProxyObject::getOwnPropertyNames):
        (JSC::ProxyObject::getPropertyNames):
        (JSC::ProxyObject::getOwnNonIndexPropertyNames):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/ProxyObject.h:
        (JSC::ProxyObject::create):
        * tests/stress/proxy-stack-overflow-exceptions.js: Added.
        (shouldThrowStackOverflow):
        (const.emptyFunction):
        (makeLongProxyChain):
        (shouldThrowStackOverflow.longProxyChain):
        (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain1):
        (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain2):
        (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain3):
        (shouldThrowStackOverflow.longProxyChainBind):
        (shouldThrowStackOverflow.longProxyChainPropertyAccess):
        (shouldThrowStackOverflow.longProxyChainReflectConstruct):
        (shouldThrowStackOverflow.longProxyChainReflectSet):
        (shouldThrowStackOverflow.longProxyChainReflectOwnKeys):
        (shouldThrowStackOverflow.longProxyChainGetPrototypeOf):
        (shouldThrowStackOverflow.longProxyChainSetPrototypeOf):
        (shouldThrowStackOverflow.longProxyChainGetOwnPropertyDescriptor):
        (shouldThrowStackOverflow.longProxyChainDefineProperty):
        (shouldThrowStackOverflow.longProxyChainIsExtensible):
        (shouldThrowStackOverflow.longProxyChainPreventExtensions):
        (shouldThrowStackOverflow.longProxyChainDeleteProperty):
        (shouldThrowStackOverflow.longProxyChainWithScope):
        (shouldThrowStackOverflow.longProxyChainWithScope2):
        (shouldThrowStackOverflow.longProxyChainWithScope3):
        (shouldThrowStackOverflow.longProxyChainArrayPrototypePush):
        (shouldThrowStackOverflow.longProxyChainWithScope4):
        (shouldThrowStackOverflow.longProxyChainCall):
        (shouldThrowStackOverflow.longProxyChainConstruct):
        (shouldThrowStackOverflow.longProxyChainHas):

2016-05-28  Andreas Kling  <akling@apple.com>

        JSGlobalLexicalEnvironment leaks SegmentedVector due to lack of destructor.
        <https://webkit.org/b/158186>

        Reviewed by Saam Barati.

        Give JSGlobalLexicalEnvironment a destroy() and set up a finalizer for it
        like we do with JSGlobalObject. (This is needed because they don't inherit
        from JSDestructibleObjects and thus can't use JSCell::needsDestruction to
        ask for allocation in destructor space.)

        This stops us from leaking all the SegmentedVector backing stores.

        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::destroy):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::create):

2016-05-28  Skachkov Oleksandr  <gskachkov@gmail.com>
        [ESNext] Trailing commas in function parameters.
        https://bugs.webkit.org/show_bug.cgi?id=158020

        Reviewed by Keith Miller.

        ESNext allow to add trailing commas in function parameters and function arguments.
        Link to spec - https://jeffmo.github.io/es-trailing-function-commas 
        Example of using - (function (a, b,) { return a + b; })(1,2,);

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::Parser<LexerType>::parseArguments):
        * tests/stress/trailing-comma-in-function-paramters.js: Added.

2016-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] op_new_arrow_func_exp is no longer necessary
        https://bugs.webkit.org/show_bug.cgi?id=158180

        Reviewed by Saam Barati.

        This patch removes op_new_arrow_func_exp bytecode since
        what op_new_arrow_func_exp is doing is completely the same to op_new_func_exp.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_arrow_func_exp): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:

2016-05-27  Caitlin Potter  <caitp@igalia.com>

        [JSC] implement async functions proposal
        https://bugs.webkit.org/show_bug.cgi?id=156147

        Reviewed by Yusuke Suzuki.

        Adds support for `async` functions, proposed in https://tc39.github.io/ecmascript-asyncawait/.

        On the front-end side, "await" becomes a contextual keyword when used within an async function,
        which triggers parsing an AwaitExpression. "await" becomes an illegal identifier name within
        these contexts. The bytecode generated from an "await" expression is identical to that generated
        in a "yield" expression in a Generator, as AsyncFunction reuses generator's state machine mechanism.

        There are numerous syntactic forms for language features, including a variation on ArrowFunctions,
        requiring the keyword `async` to precede ArrowFormalParameters, and similarly, MethodDefinitions,
        which are ordinary MethodDefinitions preceded by the keyword `async`.

        An async function desugars to the following:

        ```
        async function asyncFn() {
        }

        becomes:

        function asyncFn() {
            let generator = {
                @generatorNext: function(@generator, @generatorState, @generatorValue, @generatorResumeMode) {
                  // generator state machine stuff here
                },
                @generatorState: 0,
                @generatorThis: this,
                @generatorFrame: null
            };
            return @asyncFunctionResume(generator, undefined, GeneratorResumeMode::NormalMode);
        }
        ```

        `@asyncFunctionResume()` is similar to `@generatorResume`, with the exception that it will wrap the
        result of invoking `@generatorNext()` in a Promise, and will avoid allocating an iterator result
        object.

        If the generator has yielded (an AwaitExpression has occurred), resumption will occur automatically
        once the await-expression operand is finished, via Promise chaining.

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/AsyncFunctionPrototype.js: Added.
        (asyncFunctionResume):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finishCreation):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isArrowFunction):
        (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction):
        (JSC::UnlinkedCodeBlock::isAsyncArrowFunction):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewMethodDefinition):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionNode::emitBytecode):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_async_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_async_func_exp):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (runInteractive):
        (printUsageStatement):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAsyncFunctionBody):
        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::isArrowFunctionParameters):
        (JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseFormalParameters):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::parseImportClauseItem):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseAwaitExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/Parser.h:
        (JSC::isIdentifierOrKeyword):
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::isAsyncFunction):
        (JSC::Scope::isAsyncFunctionBoundary):
        (JSC::Scope::isModule):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsAsyncArrowFunction):
        (JSC::Scope::setIsAsyncFunction):
        (JSC::Scope::setIsAsyncFunctionBody):
        (JSC::Scope::setIsAsyncArrowFunctionBody):
        (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError):
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction):
        (JSC::Parser::forceClassifyExpressionError):
        (JSC::Parser::declarationTypeToVariableKind):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        (JSC::Parser::pushScope):
        (JSC::Parser::popScopeInternal):
        (JSC::Parser::matchSpecIdentifier):
        (JSC::Parser::isDisallowedIdentifierAwait):
        (JSC::Parser::disallowedIdentifierAwaitReason):
        (JSC::parse):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isAsyncFunctionParseMode):
        (JSC::isAsyncArrowFunctionParseMode):
        (JSC::isAsyncFunctionWrapperParseMode):
        (JSC::isAsyncFunctionBodyParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        (JSC::constructAbilityForParseMode):
        * parser/ParserTokens.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::runtimeFlags):
        (JSC::SourceCodeKey::operator==):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createAsyncFunctionBody):
        * runtime/AsyncFunctionConstructor.cpp: Added.
        (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
        (JSC::AsyncFunctionConstructor::finishCreation):
        (JSC::callAsyncFunctionConstructor):
        (JSC::constructAsyncFunctionConstructor):
        (JSC::AsyncFunctionConstructor::getCallData):
        (JSC::AsyncFunctionConstructor::getConstructData):
        * runtime/AsyncFunctionConstructor.h: Added.
        (JSC::AsyncFunctionConstructor::create):
        (JSC::AsyncFunctionConstructor::createStructure):
        * runtime/AsyncFunctionPrototype.cpp: Added.
        (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype):
        (JSC::AsyncFunctionPrototype::finishCreation):
        * runtime/AsyncFunctionPrototype.h: Added.
        (JSC::AsyncFunctionPrototype::create):
        (JSC::AsyncFunctionPrototype::createStructure):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Completion.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/JSAsyncFunction.cpp: Added.
        (JSC::JSAsyncFunction::JSAsyncFunction):
        (JSC::JSAsyncFunction::createImpl):
        (JSC::JSAsyncFunction::create):
        (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSAsyncFunction.h: Added.
        (JSC::JSAsyncFunction::allocationSize):
        (JSC::JSAsyncFunction::createStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::asyncFunctionPrototype):
        (JSC::JSGlobalObject::asyncFunctionStructure):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/RuntimeFlags.h:
        (JSC::RuntimeFlags::operator==):
        (JSC::RuntimeFlags::operator!=):
        * tests/stress/async-await-basic.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrow):
        (shouldThrowAsync):
        (let.AsyncFunction.async):
        (async.asyncFunctionForProto):
        (Object.getPrototypeOf.async):
        (Object.getPrototypeOf.async.method):
        (async):
        (async.method):
        (async.asyncNonConstructorDecl):
        (shouldThrow.new.async):
        (shouldThrow.new.async.nonConstructor):
        (async.asyncDecl):
        (async.f):
        (MyError):
        (async.asyncDeclThrower):
        (shouldThrowAsync.async):
        (resolveLater):
        (rejectLater):
        (async.resumeAfterNormal):
        (O.async.resumeAfterNormal):
        (resumeAfterNormalArrow.async):
        (async.resumeAfterThrow):
        (O.async.resumeAfterThrow):
        (resumeAfterThrowArrow.async):
        (catch):
        * tests/stress/async-await-module-reserved-word.js: Added.
        (shouldThrow):
        (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await):
        (checkModuleSyntaxError.String.raw.await):
        (checkModuleSyntaxError.String.raw.async.await):
        (SyntaxError.Cannot.declare.named):
        * tests/stress/async-await-mozilla.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrow):
        (shouldThrowAsync):
        (assert):
        (shouldThrowSyntaxError):
        (mozSemantics.async.empty):
        (mozSemantics.async.simpleReturn):
        (mozSemantics.async.simpleAwait):
        (mozSemantics.async.simpleAwaitAsync):
        (mozSemantics.async.returnOtherAsync):
        (mozSemantics.async.simpleThrower):
        (mozSemantics.async.delegatedThrower):
        (mozSemantics.async.tryCatch):
        (mozSemantics.async.tryCatchThrow):
        (mozSemantics.async.wellFinally):
        (mozSemantics.async.finallyMayFail):
        (mozSemantics.async.embedded.async.inner):
        (mozSemantics.async.embedded):
        (mozSemantics.async.fib):
        (mozSemantics.async.isOdd.async.isEven):
        (mozSemantics.async.isOdd):
        (mozSemantics.hardcoreFib.async.fib2):
        (mozSemantics.namedAsyncExpr.async.simple):
        (mozSemantics.async.executionOrder.async.first):
        (mozSemantics.async.executionOrder.async.second):
        (mozSemantics.async.executionOrder.async.third):
        (mozSemantics.async.executionOrder):
        (mozSemantics.async.miscellaneous):
        (mozSemantics.thrower):
        (mozSemantics.async.defaultArgs):
        (mozSemantics.shouldThrow):
        (mozSemantics):
        (mozMethods.X):
        (mozMethods.X.prototype.async.getValue):
        (mozMethods.X.prototype.setValue):
        (mozMethods.X.prototype.async.increment):
        (mozMethods.X.prototype.async.getBaseClassName):
        (mozMethods.X.async.getStaticValue):
        (mozMethods.Y.prototype.async.getBaseClassName):
        (mozMethods.Y):
        (mozFunctionNameInferrence.async.test):
        (mozSyntaxErrors):
        * tests/stress/async-await-reserved-word.js: Added.
        (assert):
        (shouldThrowSyntaxError):
        (AsyncFunction.async):
        * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrowAsync):
        (noArgumentsArrow2.async):
        * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (shouldThrowAsync):
        (C1):
        (C2):
        (shouldThrowAsync.async):
        * tests/stress/async_arrow_functions_lexical_super_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (BaseClass.prototype.baseClassValue):
        (BaseClass):
        (ChildClass.prototype.asyncSuperProp):
        (ChildClass.prototype.asyncSuperProp2):
        (ChildClass):
        * tests/stress/async_arrow_functions_lexical_this_binding.js: Added.
        (shouldBe):
        (shouldBeAsync):
        (d.y):

2016-05-27  Saam barati  <sbarati@apple.com>

        DebuggerCallFrame crashes when updated with the globalExec because neither ShadowChicken's algorithm nor StackVisitor's algorithm reasons about the globalExec
        https://bugs.webkit.org/show_bug.cgi?id=158104

        Reviewed by Filip Pizlo.

        I think globalExec is a special enough case that it should be handled
        at the layers above ShadowChicken and StackVisitor. Those APIs should
        deal with real stack frames on the machine stack, not a heap constructed frame.

        This patch makes DebuggerCallFrame::create aware that it may be
        created with the globalObject->globalExec() by having it construct
        a single DebuggerCallFrame that wraps the globalExec.

        This fixes a crasher because we will construct a DebuggerCallFrame
        with the globalExec when the Inspector is set to pause on all uncaught
        exceptions and the JS program has a syntax error. Because the program
        hasn't begun execution, there is no machine JS stack frame yet. So
        DebuggerCallFrame is created with globalExec, which will cause it
        to hit an assertion that dictates that the stack have size greater
        than zero.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::create):

2016-05-27  Filip Pizlo  <fpizlo@apple.com>

        DFG::LazyJSValue::tryGetStringImpl() crashes for empty values
        https://bugs.webkit.org/show_bug.cgi?id=158170

        Reviewed by Michael Saboff.

        The problem here is that jsDynamicCast<>() is evil! It avoids checking for the empty
        value, presumably because this makes it soooper fast. In DFG IR, empty values can appear
        anywhere because of TDZ.
        
        This patch doesn't change jsDynamicCast<>(), but it hardens our wrappers for it in the DFG
        and it has the affected code use one of those wrappers.
        
        * dfg/DFGFrozenValue.h:
        (JSC::DFG::FrozenValue::dynamicCast): Harden this.
        (JSC::DFG::FrozenValue::cast):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::tryGetStringImpl): Use the hardened wrapper.
        * tests/stress/strcat-emtpy.js: Added. This used to crash every time.
        (foo):
        (i.catch):

2016-05-27  Filip Pizlo  <fpizlo@apple.com>

        regExpProtoFuncSplitFast should OOM before it swaps
        https://bugs.webkit.org/show_bug.cgi?id=158157

        Reviewed by Mark Lam.
        
        This is a huge speed-up on some jsfunfuzz test cases because it makes us realize much
        sooner that running a regexp split will result in swapping. It uses the same basic
        approach as http://trac.webkit.org/changeset/201451: if the result array crosses a certain
        size threshold, we proceed with a dry run to see how big the array will get before
        allocating anything else. This way, bogus uses of split that would have OOMed only after
        killing the user's machine will now OOM before killing the user's machine.
        
        This is an enormous speed-up on some jsfunfuzz tests: they go from running for a long
        time to running instantly.

        * runtime/RegExpPrototype.cpp:
        (JSC::advanceStringIndex):
        (JSC::genericSplit):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        * tests/stress/big-split-captures.js: Added.
        * tests/stress/big-split.js: Added.

2016-05-27  Saam barati  <sbarati@apple.com>

        ShadowChicken/DebuggerCallFrame don't properly handle when the entry stack frame is a tail deleted frame
        https://bugs.webkit.org/show_bug.cgi?id=158131

        Reviewed by Yusuke Suzuki.

        There were bugs both in DebuggerCallFrame and ShadowChicken when the entry stack
        frame(s) are tail deleted.

        DebuggerCallFrame had an assertion saying that the entry frame shouldn't be
        tail deleted. This is clearly wrong. The following program proves that this assertion
        was misguided:
        ```
        "use strict";
        setTimeout(function foo() { return bar(); }, 0);
        ```

        ShadowChicken had a very subtle bug when creating the shadow stack when 
        the entry frames of the stack were tail deleted. Because it places frames into its shadow
        stack by walking the machine frame and looking up entries in the log,
        the machine frame doesn't have any notion of those tail deleted frames
        at the entry of execution. ShadowChicken would never find those frames
        because it would look for tail deleted frames *before* consulting the
        current machine frame. This is wrong because if the entry frames
        are tail deleted, then there is no machine frame for them because there
        is no machine frame before them! Therefore, we must search for tail deleted
        frames *after* consulting a machine frame. This is sound because we will always
        have at least one machine frame on the stack (when we are using StackVisitor on a valid ExecState).
        So when we consult the machine frame that is the entry frame on the machine stack,
        we will search for tail deleted frames that come before it in the shadow stack.
        This will allow us to find those tail deleted frames that are the entry frames
        for the shadow stack.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::create):
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::Packet::dump):
        (JSC::ShadowChicken::update):
        (JSC::ShadowChicken::dump):

2016-05-27  Chris Dumez  <cdumez@apple.com>

        WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables
        https://bugs.webkit.org/show_bug.cgi?id=158111

        Reviewed by Darin Adler.

        WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables.
        These are often used cross-thread and copying the captured lambda variables can be
        dangerous (e.g. we do not want to copy a String after calling isolatedCopy() upon
        capture).

        * runtime/Watchdog.cpp:
        (JSC::Watchdog::startTimer):
        (JSC::Watchdog::Watchdog): Deleted.
        (JSC::Watchdog::setTimeLimit): Deleted.
        * runtime/Watchdog.h:

2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>

        Removed unused headers from ExecutableAllocatorFixedVMPool.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=158159

        Reviewed by Darin Adler.

        * jit/ExecutableAllocatorFixedVMPool.cpp:

2016-05-27  Keith Miller  <keith_miller@apple.com>

        get_by_id should support caching unset properties in the LLInt
        https://bugs.webkit.org/show_bug.cgi?id=158136

        Reviewed by Benjamin Poulain.

        Recently, we started supporting prototype load caching for get_by_id
        in the LLInt. This patch extends that to caching unset properties.
        While it is uncommon in general for a program to see a single structure
        without a given property, the Array.prototype.concat function needs to
        lookup the Symbol.isConcatSpreadable property. For any existing code
        That property will never be set as it did not exist prior to ES6.

        Similarly to the get_by_id_proto_load bytecode, this patch adds a new
        bytecode, get_by_id_unset that checks the structureID of the base and
        assigns undefined to the result.

        There are no new tests here since we already have many tests that
        incidentally cover this change.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2016-05-26  Filip Pizlo  <fpizlo@apple.com>

        Bogus uses of regexp matching should realize that they will OOM before they start swapping
        https://bugs.webkit.org/show_bug.cgi?id=158142

        Reviewed by Michael Saboff.
        
        Refactored the RegExpObject::matchGlobal() code so that there is less duplication. Took
        advantage of this to make the code more resilient in case of absurd situations: if the
        result array gets large, it proceeds with a dry run to detect how many matches there will
        be. This allows it to OOM before it starts swapping.
        
        This also improves the overall performance of the code by using lightweight substrings and
        skipping the whole intermediate argument array.
        
        This makes some jsfunfuzz tests run a lot faster and use a lot less memory.
        
        * builtins/RegExpPrototype.js:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/MatchResult.cpp: Added.
        (JSC::MatchResult::dump):
        * runtime/MatchResult.h:
        (JSC::MatchResult::empty):
        (MatchResult::empty): Deleted.
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::match):
        (JSC::collectMatches):
        (JSC::RegExpObject::matchGlobal):
        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        * tests/stress/big-match.js: Added. Make sure that this optimization doesn't break big matches.

2016-05-26  Gavin & Ellie Barraclough  <barraclough@apple.com>

        Static table property lookup should not require getOwnPropertySlot override.
        https://bugs.webkit.org/show_bug.cgi?id=158059

        Reviewed by Darin Adler.

        Currently JSObject does not handle property lookup of entries in the static
        table. Each subclass with static properties mut override getOwnPropertySlot,
        and explicitly call the lookup functions. This has the following drawbacks:

        - Performance: for any class with static properties, property acces becomes
          virtual (via method table).
        - Poor encapsulation: implementation detail of static property access is
          spread throughout & cross projects, rather than being contained in JSObject.
        - Code size: this results in a great many additional functions.
        - Inconsistency: static table presence has to be be taken into account in many
          other operations, e.g. presence of read-only properties for put.
        - Memory: in order to avoid the virtual lookup, DOM prototypes eagerly reify
          all properties. This is likely suboptimal.

        Instead, JSObject::getPropertySlot / JSObject::getOwnPropertySlot should be
        able to handle static properties.

        This is actually a fairly small & simple change.

        The common pattern is for subclasses of JObject to override getOwnPropertySlot
        to first defer to JSObject for property storage lookup, and only if this fails
        consult the static table. They just want the static tables to be consulted after
        regular property storgae lookup. So just add a fast flag in TypeInfo for JSObject
        to check, and where it is set, do so. Then it's just a question of switching
        classes over to start setting this flag, and drop the override.

        The new mechanism does change static table lookup order from oldest-ancestor
        first to most-derived first. The new ordering makes more sense (means derived
        class static tables can now override entries from parents), and shoudn't affect
        any existing code (since overriding didn't previously work, there likely aren't
        shadowing properties in more derived types).

        This patch changes all classes in JavaScriptCore over to using the new mechanism,
        except JSGlobalObject. I'll move classes in WebCore over as a separate patch
        (this is also why I've not moved JSGlobalObject in this patch - doing so would
        move JSDOMWindow, and I'd rather handle that separately).

        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::hasStaticPropertyTable):
            - Add HasStaticPropertyTable flag.
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
            - Change setUpStaticFunctionSlot to take a VM&.
        * runtime/Lookup.h:
        (JSC::getStaticPropertySlotFromTable):
            - Added helper function to perform static lookup alone.
        (JSC::getStaticPropertySlot):
        (JSC::getStaticFunctionSlot):
            - setUpStaticFunctionSlot changed to take a VM&.
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnStaticPropertySlot):
            - Added, walks ClassInfo chain looking for static properties.
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnNonIndexPropertySlot):
            - getOwnNonIndexPropertySlot is used internally by getPropertySlot
              & getOwnPropertySlot. If property is not present in storage array
              then check the static table.
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::constructArrayWithSizeQuirk):
        (JSC::ArrayConstructor::getOwnPropertySlot): Deleted.
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::create):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::ArrayIteratorPrototype::getOwnPropertySlot): Deleted.
        * runtime/ArrayIteratorPrototype.h:
        (JSC::ArrayIteratorPrototype::create):
        (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        (JSC::booleanProtoFuncToString):
        (JSC::BooleanPrototype::getOwnPropertySlot): Deleted.
        * runtime/BooleanPrototype.h:
        (JSC::BooleanPrototype::create):
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        (JSC::millisecondsFromComponents):
        (JSC::DateConstructor::getOwnPropertySlot): Deleted.
        * runtime/DateConstructor.h:
        (JSC::DateConstructor::create):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToString):
        (JSC::DatePrototype::getOwnPropertySlot): Deleted.
        * runtime/DatePrototype.h:
        (JSC::DatePrototype::create):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        (JSC::ErrorPrototype::getOwnPropertySlot): Deleted.
        * runtime/ErrorPrototype.h:
        (JSC::ErrorPrototype::create):
        * runtime/GeneratorPrototype.cpp:
        (JSC::GeneratorPrototype::finishCreation):
        (JSC::GeneratorPrototype::getOwnPropertySlot): Deleted.
        * runtime/GeneratorPrototype.h:
        (JSC::GeneratorPrototype::create):
        (JSC::GeneratorPrototype::createStructure):
        (JSC::GeneratorPrototype::GeneratorPrototype):
        * runtime/InspectorInstrumentationObject.cpp:
        (JSC::InspectorInstrumentationObject::finishCreation):
        (JSC::InspectorInstrumentationObject::isEnabled):
        (JSC::InspectorInstrumentationObject::getOwnPropertySlot): Deleted.
        * runtime/InspectorInstrumentationObject.h:
        (JSC::InspectorInstrumentationObject::create):
        (JSC::InspectorInstrumentationObject::createStructure):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::getCallData):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        (JSC::IntlCollatorConstructor::getOwnPropertySlot): Deleted.
        * runtime/IntlCollatorConstructor.h:
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::finishCreation):
        (JSC::IntlCollatorFuncCompare):
        (JSC::IntlCollatorPrototype::getOwnPropertySlot): Deleted.
        * runtime/IntlCollatorPrototype.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::getCallData):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): Deleted.
        * runtime/IntlDateTimeFormatConstructor.h:
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): Deleted.
        * runtime/IntlDateTimeFormatPrototype.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::getCallData):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): Deleted.
        * runtime/IntlNumberFormatConstructor.h:
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        (JSC::IntlNumberFormatFuncFormatNumber):
        (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): Deleted.
        * runtime/IntlNumberFormatPrototype.h:
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::createStructure):
        (JSC::getData):
        (JSC::JSDataViewPrototype::getOwnPropertySlot): Deleted.
        * runtime/JSDataViewPrototype.h:
        * runtime/JSInternalPromiseConstructor.cpp:
        (JSC::JSInternalPromiseConstructor::getCallData):
        (JSC::JSInternalPromiseConstructor::getOwnPropertySlot): Deleted.
        * runtime/JSInternalPromiseConstructor.h:
        * runtime/JSONObject.cpp:
        (JSC::Walker::Walker):
        (JSC::JSONObject::getOwnPropertySlot): Deleted.
        * runtime/JSONObject.h:
        (JSC::JSONObject::create):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::getCallData):
        (JSC::JSPromiseConstructor::getOwnPropertySlot): Deleted.
        * runtime/JSPromiseConstructor.h:
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::addOwnInternalSlots):
        (JSC::JSPromisePrototype::getOwnPropertySlot): Deleted.
        * runtime/JSPromisePrototype.h:
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        (JSC::getMap):
        (JSC::MapPrototype::getOwnPropertySlot): Deleted.
        * runtime/MapPrototype.h:
        (JSC::MapPrototype::create):
        (JSC::MapPrototype::MapPrototype):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::finishCreation):
        (JSC::printableModuleKey):
        (JSC::ModuleLoaderObject::getOwnPropertySlot): Deleted.
        * runtime/ModuleLoaderObject.h:
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        (JSC::toThisNumber):
        (JSC::NumberPrototype::getOwnPropertySlot): Deleted.
        * runtime/NumberPrototype.h:
        (JSC::NumberPrototype::create):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::addDefineProperty):
        (JSC::constructObject):
        (JSC::ObjectConstructor::getOwnPropertySlot): Deleted.
        * runtime/ObjectConstructor.h:
        (JSC::ObjectConstructor::create):
        (JSC::ObjectConstructor::createStructure):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):
        (JSC::ReflectObject::getOwnPropertySlot): Deleted.
        * runtime/ReflectObject.h:
        (JSC::ReflectObject::create):
        (JSC::ReflectObject::createStructure):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::getRightContext):
        (JSC::regExpConstructorDollar):
        (JSC::RegExpConstructor::getOwnPropertySlot): Deleted.
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::create):
        (JSC::RegExpConstructor::createStructure):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        (JSC::getSet):
        (JSC::SetPrototype::getOwnPropertySlot): Deleted.
        * runtime/SetPrototype.h:
        (JSC::SetPrototype::create):
        (JSC::SetPrototype::SetPrototype):
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::finishCreation):
        (JSC::stringFromCharCodeSlowCase):
        (JSC::StringConstructor::getOwnPropertySlot): Deleted.
        * runtime/StringConstructor.h:
        (JSC::StringConstructor::create):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        (JSC::StringIteratorPrototype::getOwnPropertySlot): Deleted.
        * runtime/StringIteratorPrototype.h:
        (JSC::StringIteratorPrototype::create):
        (JSC::StringIteratorPrototype::StringIteratorPrototype):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::create):
        (JSC::substituteBackreferencesSlow):
        (JSC::StringPrototype::getOwnPropertySlot): Deleted.
        * runtime/StringPrototype.h:
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::finishCreation):
        (JSC::callSymbol):
        (JSC::SymbolConstructor::getOwnPropertySlot): Deleted.
        * runtime/SymbolConstructor.h:
        (JSC::SymbolConstructor::create):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        (JSC::SymbolPrototype::getOwnPropertySlot): Deleted.
        * runtime/SymbolPrototype.h:
        (JSC::SymbolPrototype::create):
            - remove getOwnPropertySlot, replace OverridesGetOwnPropertySlot flag with HasStaticPropertyTable.

2016-05-26  Commit Queue  <commit-queue@webkit.org>

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

        Caused 30% regression on Dromaeo DOM core tests (Requested by
        rniwa on #webkit).

        Reverted changeset:

        "REGRESSION: JSBench spends a lot of time transitioning
        to/from dictionary"
        https://bugs.webkit.org/show_bug.cgi?id=158045
        http://trac.webkit.org/changeset/201436

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

        REGRESSION: JSBench spends a lot of time transitioning to/from dictionary
        https://bugs.webkit.org/show_bug.cgi?id=158045

        Reviewed by Saam Barati.

        15% speedup on jsbench-amazon-firefox, possibly 5% speedup overall on jsbench.

        This regression seems to have two parts:

        (1) Transitioning the window object to/from dictionary is more expensive
        than it used to be to because the window object has lots more properties.
        The window object has more properties because, for WebIDL compatibility,
        we reify DOM APIs as properties when you delete.

        (2) DOM prototypes transition to/from dictionary upon creation
        because, once again for WebIDL compatibility, we reify their static
        APIs eagerly.

        The solution is to chill out a bit on dictionary transitions.

        * bytecode/ObjectPropertyConditionSet.cpp: Don't flatten a dictionary
        if we've already done so before. This avoids pathological churn, and it
        is our idiom in other places.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute): Do flatten the global object unconditionally
        if it is an uncacheable dictionary because the global object is super
        important.

        * runtime/BatchedTransitionOptimizer.h:
        (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer):
        (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): Deleted.
        Don't transition away from dictionary after a batched set of property
        puts because normal dictionaries are cacheable and that's a perfectly
        fine state to be in -- and the transition is expensive.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Do start the global object out as a cacheable
        dictionary because it will inevitably have enough properties to become
        a dictionary.

        * runtime/Operations.h:
        (JSC::normalizePrototypeChain): Same as ObjectPropertyConditionSet.cpp.

2016-05-25  Geoffrey Garen  <ggaren@apple.com>

        replaceable own properties seem to ignore replacement after property caching
        https://bugs.webkit.org/show_bug.cgi?id=158091

        Reviewed by Darin Adler.

        * runtime/Lookup.h:
        (JSC::replaceStaticPropertySlot): New helper function for replacing a
        static property with a direct property. We need to do an attribute changed
        transition because client code might have cached our static property.

2016-05-25  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] RegExp with deeply nested subexpressions overflow the stack in Yarr
        https://bugs.webkit.org/show_bug.cgi?id=158011
        rdar://problem/25946592

        Reviewed by Saam Barati.

        When generating the meta-data required for compilation,
        Yarr uses a recursive function over the various expression in the pattern.

        If you have many nested expressions, you can run out of stack
        and crash the WebProcess.
        This patch changes that into a soft failure. The expression is just
        considered invalid.

        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::setupOffsets):
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse):
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::YarrPattern::YarrPattern):
        (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): Deleted.
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): Deleted.
        * yarr/YarrPattern.h:

2016-05-25  Alex Christensen  <achristensen@webkit.org>

        Fix Win64 build after r201335
        https://bugs.webkit.org/show_bug.cgi?id=158078

        Reviewed by Mark Lam.

        * offlineasm/x86.rb:
        Add intel implementations for loadbs and loadhs

2016-05-25  Carlos Garcia Campos  <cgarcia@igalia.com>

        REGRESSION(r201066): [GTK] Several intl tests started to fail in GTK+ bot after r201066
        https://bugs.webkit.org/show_bug.cgi?id=158066

        Reviewed by Darin Adler.

        run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment
        variables at all when using jsc binary. We are using setlocale() with a nullptr locale to get the current one, but
        the current one is always "C", because to set the locale according to the environment variables we need to call
        setlocale with an empty string as locale. That's done by gtk_init(), which is called by all our binaries (web
        process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has
        always worked for EFL is because they call ecore_init() in jsc that calls setlocale.

        * jsc.cpp:
        (main): Call setlocale(LC_ALL, "") on GTK+.

2016-05-25  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Fix the Wcast-align warning in LinkBuffer.cpp
        https://bugs.webkit.org/show_bug.cgi?id=157889

        Reviewed by Darin Adler.

        * assembler/LinkBuffer.cpp:
        (JSC::recordLinkOffsets):

2016-05-24  Keith Miller  <keith_miller@apple.com>

        TypedArray.prototype.slice should not throw if no arguments are provided
        https://bugs.webkit.org/show_bug.cgi?id=158044
        <rdar://problem/26433280>

        Reviewed by Geoffrey Garen.

        We were throwing an exception if the TypedArray.prototype.slice function
        was not provided arguments. This was wrong. Instead we should just assume
        the first argument was 0.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSlice): Deleted.
        * tests/stress/typedarray-slice.js:

2016-05-24  Keith Miller  <keith_miller@apple.com>

        LLInt should be able to cache prototype loads for values in GetById
        https://bugs.webkit.org/show_bug.cgi?id=158032

        Reviewed by Filip Pizlo.

        This patch adds prototype value caching to the LLInt for op_get_by_id.
        Two previously unused words in the op_get_by_id bytecode have been
        repurposed to hold extra information for the cache. The first is a
        counter that records the number of get_by_ids that hit a cacheable value
        on a prototype. When the counter is decremented from one to zero we
        attempt to cache the prototype load, which will be discussed further
        below. The second word is used to hold the prototype object when we have
        started caching.

        When the counter is decremented to zero we first attempt to generate and
        watch the property conditions needed to ensure the validity of prototype
        load. If the watchpoints are successfully created and installed we
        replace the op_get_by_id opcode with the new op_get_by_id_proto_load
        opcode, which tells the LLInt to use the cache prototype object for the
        load rather than the base value.

        Prior to this patch there was not LLInt specific data onCodeBlocks.
        Since the CodeBlock needs to own the Watchpoints for the cache, a weak
        map from each base structure to a bag of Watchpoints created for that
        structure by some op_get_by_id has been added to the CodeBlock. During
        GC, if we find that the a structure in the map has not been marked we
        free the associated bag on the CodeBlock.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::llintGetByIdWatchpointMap):
        (JSC::clearLLIntGetByIdCache):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: Added.
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::install):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: Added.
        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::ObjectPropertyConditionSet::isValidAndWatchable):
        * bytecode/ObjectPropertyConditionSet.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetById):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/Options.h:
        * tests/stress/llint-get-by-id-cache-prototype-load-from-dictionary.js: Added.
        (test):

2016-05-24  Keith Miller  <keith_miller@apple.com>

        We should be able to use the sampling profiler with DRT/WTR.
        https://bugs.webkit.org/show_bug.cgi?id=158041

        Reviewed by Saam Barati.

        This patch makes the sampling profiler use a new option, samplingProfilerPath, which
        specifies the path to a directory to output sampling profiler data when the program
        terminates or the VM is destroyed. Additionally, it fixes some other issues with the
        bytecode profiler that would cause crashes on debug builds.

        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::ensureBytecodesFor):
        (JSC::Profiler::Database::performAtExitSave):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::registerForReportAtExit):
        (JSC::SamplingProfiler::reportDataToOptionFile):
        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):

2016-05-24  Saam barati  <sbarati@apple.com>

        We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation
        https://bugs.webkit.org/show_bug.cgi?id=158036

        Reviewed by Geoffrey Garen.

        This patch implements a 1 item cache for JSScope::abstractResolve. I also tried
        implementing the cache as a HashMap, but it seemed either less profitable on some
        benchmarks or just as profitable on others. Therefore, it's cleaner to just
        use a 1 item cache.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::AbstractResolveKey::AbstractResolveKey):
        (JSC::AbstractResolveKey::operator==):
        (JSC::AbstractResolveKey::isEmptyValue):
        (JSC::CodeBlock::finishCreation):
        * runtime/GetPutInfo.h:
        (JSC::needsVarInjectionChecks):
        (JSC::ResolveOp::ResolveOp):

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

        Unreviwed, add a comment to describe the test's failure mode. Suggested by mlam.

        * tests/stress/override-map-constructor.js:
        (Map):

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

        Map should not be in JSGlobalObject's static hashtable because it's initialized eagerly via FOR_EACH_SIMPLE_BUILTIN_TYPE_WITH_CONSTRUCTOR
        https://bugs.webkit.org/show_bug.cgi?id=158031
        rdar://problem/26353661

        Reviewed by Geoffrey Garen.
        
        We were listing Map as being a lazy class structure. It's not. m_mapStructure is a WriteBarrier<>
        not a LazyClassStructure<> and there is nothing lazy about it.

        * runtime/JSGlobalObject.cpp: The fix is to remove Map here.
        * runtime/Lookup.cpp: Add some dumping on the assert path.
        (JSC::setUpStaticFunctionSlot):
        * tests/stress/override-map-constructor.js: Added. This test used to crash.
        (Map):

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

        LLInt64 should have typed array fast paths for get_by_val
        https://bugs.webkit.org/show_bug.cgi?id=157931

        Reviewed by Keith Miller.

        I think that the LLInt should be able to access typed arrays more quickly than it does now.
        Ideally we would have fast paths for every major typed array operation and we would use
        inline cache optimizations. I don't want to do this all in one go, so my plan is to
        incrementally add support for this as time allows.
        
        This change just adds the easy typed array fast paths for get_by_val in the 64-bit version
        of LLInt.
        
        Another bug, https://bugs.webkit.org/show_bug.cgi?id=157922, tracks the overall task of
        adding all typed array fast paths to both versions of the LLInt.
        
        This is a 30% speed-up on typed array benchmarks in LLInt. This is not a speed-up when the
        JITs are enabled.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/backends.rb:
        * runtime/JSArrayBufferView.h:
        * runtime/JSType.h:

2016-05-24  Saam barati  <sbarati@apple.com> and Yusuke Suzuki <utatane.tea@gmail.com>

        ThisTDZMode is no longer needed
        https://bugs.webkit.org/show_bug.cgi?id=157209

        Reviewed by Saam Barati.

        ThisTDZMode is no longer needed because we have ConstructorKind
        and DerivedContextType. The value of ThisTDZMode is strictly less
        expressive than the combination of those two values. We were
        using those values anyways, and this patch just makes it official
        by removing ThisTDZMode.

        This patch also cleans up caching keys. We extract SourceCodeFlags
        from SourceCodeKey and use it in EvalCodeCache. It correctly
        contains needed cache attributes: EvalContextType, DerivedContextType,
        etc. Here, we still use specialized keys for EvalCodeCache instead
        of SourceCodeKey for performance; it does not include name String and
        does not allocate SourceCode.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        (JSC::EvalCodeCache::CacheKey::operator==):
        (JSC::EvalCodeCache::CacheKey::Hash::equal):
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode): Deleted.
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createThisExpr):
        * parser/NodeConstructors.h:
        (JSC::ThisNode::ThisNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        (JSC::parse):
        * parser/ParserModes.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeFlags::SourceCodeFlags):
        (JSC::SourceCodeFlags::operator==):
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::Hash::hash):
        (JSC::SourceCodeKey::Hash::equal):
        (JSC::SourceCodeKey::HashTraits::isEmptyValue):
        (JSC::SourceCodeKeyHash::hash): Deleted.
        (JSC::SourceCodeKeyHash::equal): Deleted.
        (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createThisExpr):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::create):
        * runtime/Executable.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/stress/code-cache-incorrect-caching.js: Added.
        (shouldBe):
        (hello):
        (catch):
        (shouldBe.test.hello):
        (globalEval.ok):
        (global.hello.hello):

2016-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for Reflect.get with Proxy and primitive value as explicit receiver
        https://bugs.webkit.org/show_bug.cgi?id=157080

        Reviewed by Saam Barati.

        In custom accessor getter, the argument "thisValue" can be altered by using `Reflect.get`.
        In this patch, we add a new parameter, "slotBase". This represents the base value offering
        this custom getter. And use it in ProxyObject's performGet custom accessor getter.

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        In PolymorphicAccess case, the thisValue and the slotBase are always cells.
        This is because IC is enabled in the case that the base value is a cell.
        And slotBase is always on the prototype chain from this base value.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jsc.cpp:
        (WTF::CustomGetter::customGetter):
        (WTF::RuntimeArray::lengthGetter):
        * runtime/CustomGetterSetter.cpp:
        (JSC::callCustomSetter):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::boundSlotBaseFunctionCall):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::argumentsGetter):
        (JSC::JSFunction::callerGetter):
        * runtime/JSFunction.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::callbackGetter):
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::customGetter):
        * runtime/PropertySlot.h:
        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpConstructorDollar):
        (JSC::regExpConstructorInput):
        (JSC::regExpConstructorMultiline):
        (JSC::regExpConstructorLastMatch):
        (JSC::regExpConstructorLastParen):
        (JSC::regExpConstructorLeftContext):
        (JSC::regExpConstructorRightContext):
        (JSC::regExpConstructorDollar1): Deleted.
        (JSC::regExpConstructorDollar2): Deleted.
        (JSC::regExpConstructorDollar3): Deleted.
        (JSC::regExpConstructorDollar4): Deleted.
        (JSC::regExpConstructorDollar5): Deleted.
        (JSC::regExpConstructorDollar6): Deleted.
        (JSC::regExpConstructorDollar7): Deleted.
        (JSC::regExpConstructorDollar8): Deleted.
        (JSC::regExpConstructorDollar9): Deleted.
        * tests/stress/proxy-get-with-primitive-receiver.js: Added.
        (shouldBe):

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

        REGRESSION (196374): deleting a global property is expensive
        https://bugs.webkit.org/show_bug.cgi?id=158005

        Reviewed by Chris Dumez.

        * runtime/JSObject.cpp:
        (JSC::JSObject::deleteProperty): We only need to reify static properties
        if the name being deleted matches a static property. Otherwise, we can
        be sure that delete won't observe any static properties.

2016-05-23  Saam barati  <sbarati@apple.com>

        The baseline JIT crashes when compiling "(1,1)/1"
        https://bugs.webkit.org/show_bug.cgi?id=157933

        Reviewed by Benjamin Poulain.

        op_div in the baseline JIT needed to better handle when both the lhs
        and rhs are constants. It needs to make sure to load either the lhs or
        the rhs into a register since the div generator can't handle both
        the lhs and rhs being constants.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        * tests/stress/jit-gracefully-handle-double-constants-in-math-operators.js: Added.
        (assert):
        (test):

2016-05-23  Saam barati  <sbarati@apple.com>

        String template don't handle let initialization properly inside eval
        https://bugs.webkit.org/show_bug.cgi?id=157991

        Reviewed by Oliver Hunt.

        The fix is to make sure we emit TDZ checks. 

        * bytecompiler/NodesCodegen.cpp:
        (JSC::TaggedTemplateNode::emitBytecode):
        * tests/stress/tagged-template-tdz.js: Added.
        (shouldThrowTDZ):
        (test):

2016-05-22  Saam barati  <sbarati@apple.com>

        Unreviewed. Fixed debug assertion failures from r201235.

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

2016-05-22  Brady Eidson  <beidson@apple.com>

        Attempted Yosemite build fix after http://trac.webkit.org/changeset/201255

        Suggested by and reviewed by Anders Carlsson.

        * b3/B3CCallValue.h: Initialize the effects member more conventionally.

2016-05-22  Brady Eidson  <beidson@apple.com>

        Move to C++14.
        https://bugs.webkit.org/show_bug.cgi?id=157948

        Reviewed by Michael Catanzaro.

        * Configurations/Base.xcconfig:

2016-05-22  Saam barati  <sbarati@apple.com>

        REGRESSION(r199075): String.prototype.replace fails after being used many times with different replace values
        https://bugs.webkit.org/show_bug.cgi?id=157968
        <rdar://problem/26404735>

        Reviewed by Ryosuke Niwa and Filip Pizlo.

        There was a bug in the DFG where we were checking a condition
        on the wrong variable.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2016-05-22  Chris Dumez  <cdumez@apple.com>

        Remove uses of PassRefPtr in JS bindings code
        https://bugs.webkit.org/show_bug.cgi?id=157949

        Reviewed by Andreas Kling.

        Remove uses of PassRefPtr in JS bindings code.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::queueMicrotask):
        * runtime/JSGlobalObject.h:

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Mark Lam.

        JavaScriptCore now provides a sampling profiler and it is enabled
        by all ports. Web Inspector switched months ago to using the
        sampling profiler and displaying its data. Remove the legacy
        profiler, as it is no longer being used by anything other then
        console.profile and tests. We will update console.profile's
        behavior soon to have new behavior and use the sampling data.

        * API/JSProfilerPrivate.cpp: Removed.
        * API/JSProfilerPrivate.h: Removed.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister): Deleted.
        (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::CallArguments::CallArguments): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Deleted.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()): Deleted.
        (JSC::Interpreter::execute): Deleted.
        (JSC::Interpreter::executeCall): Deleted.
        (JSC::Interpreter::executeConstruct): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Removed.
        * profiler/LegacyProfiler.cpp: Removed.
        * profiler/LegacyProfiler.h: Removed.
        * profiler/Profile.cpp: Removed.
        * profiler/Profile.h: Removed.
        * profiler/ProfileGenerator.cpp: Removed.
        * profiler/ProfileGenerator.h: Removed.
        * profiler/ProfileNode.cpp: Removed.
        * profiler/ProfileNode.h: Removed.
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal): Deleted.
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
        (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
        (JSC::VM::setEnabledProfiler): Deleted.
        * runtime/VM.h:
        (JSC::VM::enabledProfiler): Deleted.
        (JSC::VM::enabledProfilerAddress): Deleted.

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Saam Barati.

        * inspector/protocol/Timeline.json:
        * jsc.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::hasLegacyProfiler):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.

2016-05-20  Saam barati  <sbarati@apple.com>

        JSScope::abstractAccess doesn't need to copy the SymbolTableEntry, it can use it by reference
        https://bugs.webkit.org/show_bug.cgi?id=157956

        Reviewed by Geoffrey Garen.

        A SymbolTableEntry may be a FatEntry. Copying a FatEntry is slow because we have to
        malloc memory for it, then free the malloced memory once the entry goes out of
        scope. abstractAccess uses a SymbolTableEntry temporarily when performing scope
        accesses during bytecode linking. It copies out the SymbolTableEntry every time
        it does a SymbolTable lookup. This is not cheap when the entry happens to be a
        FatEntry. We should really just be using a reference to the entry because
        there is no need to copy it in such a scenario.

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

2016-05-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: retained size for typed arrays does not count native backing store
        https://bugs.webkit.org/show_bug.cgi?id=157945
        <rdar://problem/26392238>

        Reviewed by Geoffrey Garen.

        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::estimatedSize):
        Include an estimatedSize implementation for JSArrayBuffer.
        ArrayBuffer has a unique path, different from other data
        stored in the Heap.

        * tests/heapProfiler/typed-array-sizes.js: Added.
        Test sizes of TypedArray with and without an ArrayBuffer.
        When the TypedArray is a view wrapping an ArrayBuffer, the
        ArrayBuffer has the size.

2016-05-20  Geoffrey Garen  <ggaren@apple.com>

        reifyAllStaticProperties makes two copies of every string
        https://bugs.webkit.org/show_bug.cgi?id=157953

        Reviewed by Mark Lam.

        Let's not do that.

        * runtime/JSObject.cpp:
        (JSC::JSObject::reifyAllStaticProperties): Pass our Identifier to
        reifyStaticProperty so it doesn't have to make its own.

        * runtime/Lookup.h:
        (JSC::reifyStaticProperty): No need to null check because callers never
        pass null anymore. No need to make an identifier because callers pass
        us one.

        (JSC::reifyStaticProperties): Honor new interface.

2016-05-20  Geoffrey Garen  <ggaren@apple.com>

        JSBench regression: CodeBlock linking always copies the symbol table
        https://bugs.webkit.org/show_bug.cgi?id=157951

        Reviewed by Saam Barati.

        We always put a SymbolTable into the constant pool, even in simple
        functions in which it won't be used -- i.e., there's on eval and there
        are no captured variables and so on.

        This is costly because linking must copy any provided symbol tables.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitProfileType): Only add the symbol table
        as a constant if we will use it at runtime.

2016-05-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Improve int->float conversion in FTL
        https://bugs.webkit.org/show_bug.cgi?id=157936

        Reviewed by Filip Pizlo.

        The integer -> floating point lowering was very barebone.

        For example, converting a constant integer to double
        was doing:
            mov #const, %eax
            xor %xmm0, %xmm0
            cvtsi2sd %eax, %xmm0

        Conversion from integer to float was also missing.
        We were always converting to double then rounding the double
        to float.

        This patch adds the basics:
        -Constant folding.
        -Integer to Float opcode.
        -Reducing int->double to int->float when used by DoubleToFloat.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
        (JSC::MacroAssemblerX86_64::convertInt64ToFloat):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::cvtsi2ss_rr):
        (JSC::X86Assembler::cvtsi2ssq_rr):
        (JSC::X86Assembler::cvtsi2sdq_mr):
        (JSC::X86Assembler::cvtsi2ssq_mr):
        (JSC::X86Assembler::cvtsi2ss_mr):
        * assembler/MacroAssemblerARM64.h:
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::iToDConstant):
        (JSC::B3::Const32Value::iToFConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::iToDConstant):
        (JSC::B3::Const64Value::iToFConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceDoubleToFloat.cpp:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::iToDConstant):
        (JSC::B3::Value::iToFConstant):
        (JSC::B3::Value::isRounded):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::materialize):
        * b3/air/AirFixPartialRegisterStalls.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::int64Operands):
        (JSC::B3::testIToD64Arg):
        (JSC::B3::testIToF64Arg):
        (JSC::B3::testIToD32Arg):
        (JSC::B3::testIToF32Arg):
        (JSC::B3::testIToD64Mem):
        (JSC::B3::testIToF64Mem):
        (JSC::B3::testIToD32Mem):
        (JSC::B3::testIToF32Mem):
        (JSC::B3::testIToD64Imm):
        (JSC::B3::testIToF64Imm):
        (JSC::B3::testIToD32Imm):
        (JSC::B3::testIToF32Imm):
        (JSC::B3::testIToDReducedToIToF64Arg):
        (JSC::B3::testIToDReducedToIToF32Arg):
        (JSC::B3::run):

2016-05-19  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FTL can crash on stack overflow
        https://bugs.webkit.org/show_bug.cgi?id=157881
        rdar://problem/24665964

        Reviewed by Michael Saboff.

        The VM's m_largestFTLStackSize was never set anywhere (updateFTLLargestStackSize()
        was never called). We forgot to change that when implementing B3.

        Even when it is set, we still have a problem on OSR Exit.
        If the last frame is a FTL frame and it OSR Exits, the space required for
        that frame becomes significantly larger. What happens is we crash in the OSR Exit
        instead of the FTL frame (this is what happens in rdar://problem/24665964).

        This patch changes the stack boundary checks in FTL to be the same as DFG:
        we verify that we have enough space for the current optimized function but
        also for the baseline version (including inlining) in case of exit.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::VM::updateStackLimit): Deleted.
        (JSC::VM::updateFTLLargestStackSize): Deleted.
        * runtime/VM.h:
        (JSC::VM::addressOfFTLStackLimit): Deleted.

2016-05-18  Filip Pizlo  <fpizlo@apple.com>

        DFG::LICMPhase shouldn't hoist type checks unless it knows that the check will succeed at the loop pre-header
        https://bugs.webkit.org/show_bug.cgi?id=144527

        Reviewed by Saam Barati.
        
        This adds a control flow equivalence analysis (called ControlEquivalenceAnalysis) based on
        dominator analysis over the backwards CFG. Two basic blocks are control flow equivalent if
        the execution of one implies that the other one must also execute. It means that the two
        blocks' forward and backward dominance are reciprocated: (A dom B and B backdom A) or (B dom
        A and A backdom B). LICM now uses it to become more conservative about hoisting checks, if
        this has caused problems in the past. If we hoist something that may exit from a block that
        was not control equivalent to the pre-header then it's possible that the node's speculation
        will fail even though it wouldn't have if it wasn't hoisted. So, we flag these nodes'
        origins as being "wasHoisted" and we track all of their exits as "HoistingFailed". LICM will
        turn off such speculative hoisting if the CodeBlock from which we are hoisting had the
        HoistingFailed exit kind.
        
        Note that this deliberately still allows us to hoist things that may exit even if they are
        not control equivalent to the pre-header. This is necessary because the profitability of
        hoisting is so huge in all of the cases that we're aware of that it's worth giving it a
        shot.
        
        This is neutral on macrobenchmarks since none of the benchmarks we track have a hoistable
        operation that would exit only if hoisted. I added microbenchmarks to illustrate the problem
        and two of them speed up by ~40% while one of them is neutral (Int52 saves us from having
        problems on that program even though LICM previously did the wrong thing).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * dfg/DFGAtTailAbstractState.h:
        (JSC::DFG::AtTailAbstractState::operator bool):
        (JSC::DFG::AtTailAbstractState::initializeTo):
        * dfg/DFGBackwardsCFG.h: Added.
        (JSC::DFG::BackwardsCFG::BackwardsCFG):
        * dfg/DFGBackwardsDominators.h: Added.
        (JSC::DFG::BackwardsDominators::BackwardsDominators):
        * dfg/DFGCommon.h:
        (JSC::DFG::checkAndSet): Deleted.
        * dfg/DFGControlEquivalenceAnalysis.h: Added.
        (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis):
        (JSC::DFG::ControlEquivalenceAnalysis::dominatesEquivalently):
        (JSC::DFG::ControlEquivalenceAnalysis::areEquivalent):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::invalidateCFG):
        (JSC::DFG::Graph::substituteGetLocal):
        (JSC::DFG::Graph::handleAssertionFailure):
        (JSC::DFG::Graph::ensureDominators):
        (JSC::DFG::Graph::ensurePrePostNumbering):
        (JSC::DFG::Graph::ensureNaturalLoops):
        (JSC::DFG::Graph::ensureBackwardsCFG):
        (JSC::DFG::Graph::ensureBackwardsDominators):
        (JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasDebuggerEnabled):
        * dfg/DFGInPlaceAbstractState.h:
        (JSC::DFG::InPlaceAbstractState::operator bool):
        (JSC::DFG::InPlaceAbstractState::createValueForNode):
        (JSC::DFG::InPlaceAbstractState::forNode):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMayExit.h:
        * dfg/DFGNode.h:
        * dfg/DFGNodeOrigin.cpp:
        (JSC::DFG::NodeOrigin::dump):
        * dfg/DFGNodeOrigin.h:
        (JSC::DFG::NodeOrigin::takeValidExit):
        (JSC::DFG::NodeOrigin::withWasHoisted):
        (JSC::DFG::NodeOrigin::forInsertingAfter):
        * dfg/DFGNullAbstractState.h: Added.
        (JSC::DFG::NullAbstractState::NullAbstractState):
        (JSC::DFG::NullAbstractState::operator bool):
        (JSC::DFG::NullAbstractState::forNode):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExitBase.cpp:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        * ftl/FTLOSRExit.h:

2016-05-19  Mark Lam  <mark.lam@apple.com>

        Code that null checks the VM pointer before any use should ref the VM.
        https://bugs.webkit.org/show_bug.cgi?id=157864

        Reviewed by Filip Pizlo and Keith Miller.

        JSLock::willReleaseLock() and HeapTimer::timerDidFire() need to reference the VM
        through a RefPtr.  Otherwise, there's no guarantee that the VM won't be deleted
        after their null checks.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::vm):
        (JSC::CodeBlock::setVM): Deleted.
        - Not used, and suggests that it can be changed during the lifetime of the
          CodeBlock (which should not be).

        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::timerDidFire):
        * runtime/JSLock.cpp:
        (JSC::JSLock::willReleaseLock):
        - Store the VM pointer in a RefPtr first, and null check the RefPtr instead of
          the raw VM pointer.  This makes the null check a strong guarantee that the
          VM pointer is valid while these functions are using it.

2016-05-19  Saam barati  <sbarati@apple.com>

        arrow function lexical environment should reuse the same environment as the function's lexical environment where possible
        https://bugs.webkit.org/show_bug.cgi?id=157908

        Reviewed by Filip Pizlo.

        We can safely combine these two environment when we have
        a simple parameter list (no default parameters, no destructring parameters).

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        * bytecompiler/BytecodeGenerator.h:

2016-05-19  Michael Saboff  <msaboff@apple.com>

        Unreviewed build fix.

        Skipping this new test as it times out on the bots.

        Issue tracked in https://bugs.webkit.org/show_bug.cgi?id=157903

        * tests/stress/regress-157595.js:
        (MyRegExp):

2016-05-19  Guillaume Emont  <guijemont@igalia.com>

        JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis
        https://bugs.webkit.org/show_bug.cgi?id=157741

        Reviewed by Saam Barati.

        The PutByValWithThis case needs a special case for MIPS because we
        don't have enough registers. The special case needs to be different
        from the x86 one because we have a different ABI.

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

2016-05-19  Brian Burg  <bburg@apple.com>

        Web Inspector: use a consistent prefix for injected scripts
        https://bugs.webkit.org/show_bug.cgi?id=157715
        <rdar://problem/26287188>

        Reviewed by Timothy Hatcher.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/InjectedScriptSource.js:

2016-05-19  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Remove redefined macro after r200606
        https://bugs.webkit.org/show_bug.cgi?id=157890

        Reviewed by Michael Saboff.

        * bytecode/PolymorphicAccess.cpp:
        * jit/CCallHelpers.h:

2016-05-18  Saam barati  <sbarati@apple.com>

        Function with default parameter values that are arrow functions that capture this isn't working
        https://bugs.webkit.org/show_bug.cgi?id=157786
        <rdar://problem/26327329>

        Reviewed by Geoffrey Garen.

        To make the scopes ordered properly, I needed to initialize the arrow 
        function lexical environment before initializing default parameter values.
        I also made the code easier to reason about by never reusing the function's
        var lexical environment for the arrow function lexical environment. The
        reason for this is that that code was wrong, and we just didn't have code to
        that properly tested it. It was easy for that code to be wrong because
        sometimes the function's lexical environment isn't the top-most scope
        (namely, when a function's parameter list is non-simple) and sometimes
        it is (when the function's parameter list is simple).

        Also, because a function's default parameter values may capture the
        'arguments' variable inside an arrow function, I needed to take care
        to initialize the 'arguments' variable as part of whichever scope
        is the top-most scope. It's either the function's var environment
        if the parameter list is simple, or it's the function's parameter
        environment if the parameter list is non-simple.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::initializeParameters):
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        (JSC::BytecodeGenerator::visibleNameForParameter):
        * bytecompiler/BytecodeGenerator.h:
        * tests/stress/arrow-functions-as-default-parameter-values.js: Added.
        (assert):
        (test):
        (test.foo):
        * tests/stress/op-push-name-scope-crashes-profiler.js:
        (test):

2016-05-18  Michael Saboff  <msaboff@apple.com>

        r199812 broke test262
        https://bugs.webkit.org/show_bug.cgi?id=157595

        Reviewed by Filip Pizlo.

        Added a reasonable limit to the size of the match result array to catch possible
        infinite loops when matching.
        Added a new tests that creates an infinite loop in RegExp.prototype.[Symbol.match]
        by creating a subclass of RegExp where the base RegExp's global flag is false and
        the subclass overrides .global with a getter that always returns true.

        * builtins/RegExpPrototype.js:
        (match):
        * tests/stress/regress-157595.js: Added.
        (MyRegExp):
        (MyRegExp.prototype.get global):
        (test):
        (catch):

2016-05-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Namespace object re-export should be handled as local export
        https://bugs.webkit.org/show_bug.cgi?id=157806

        Reviewed by Mark Lam.

        We align the implementation of ExportEntry to the spec; remove Type::Namespace.
        This Type::Namespace is used for re-exported namespace object binding. For example,

            import * as namespace from "namespace.js"
            export { namespace }

        In the above case, we used ExportEntry(Type::Namespace). In this patch, we drop this
        and use normal local export (Type::Local) instead because namespace object actually has
        the local binding in the above module environment. And this handling strictly meets the
        spec (Sec 15.2.1.16.1 step 11-a-ii-2-b).

        And we also clean up the ExportEntry implementation; dropping unnecessary information.
        This change fixes the test262/test/language/module-code/instn-star-equality.js crash.

        * parser/ModuleAnalyzer.cpp:
        (JSC::ModuleAnalyzer::exportVariable):
        * runtime/JSModuleRecord.cpp:
        (JSC::getExportedNames):
        (JSC::JSModuleRecord::dump): Deleted.
        * runtime/JSModuleRecord.h:
        * tests/modules/namespace-re-export.js: Added.
        * tests/modules/namespace-re-export/namespace-re-export-fixture.js: Added.
        * tests/modules/namespace-re-export/namespace-re-export.js: Added.
        * tests/modules/resources/assert.js:
        (export.shouldNotBe):

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

        JSC should detect the right default locale even when it's not embedded in WebCore
        https://bugs.webkit.org/show_bug.cgi?id=157755
        rdar://problem/24665424

        Reviewed by Keith Miller.
        
        This makes JSC try to use WTF's platform user preferred language detection if the DOM did
        not register a defaultLanguage callback. The result is that when JSC runs standalone it
        will detect the platform user preferred language almost the same way as when it's embedded
        in WebCore. The only difference is that WebCore may have its own additional overrides via
        the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls
        back to.
        
        We first found this bug because on iOS, the intl tests would fail because ICU would report
        a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall
        back to ICU's locale detection. It turns out that the ICU default locale is also bogus on
        OS X, just less so. For example, setting things to Poland did not result in the jsc shell
        printing dates Polish-style. Now it will print them Polish-style if your system preferences
        say so. Also, the tests don't fail on iOS anymore.
        
        * runtime/IntlObject.cpp:
        (JSC::defaultLocale):

2016-05-17  Dean Jackson  <dino@apple.com>

        Remove ES6_GENERATORS flag
        https://bugs.webkit.org/show_bug.cgi?id=157815
        <rdar://problem/26332894>

        Reviewed by Geoffrey Garen.

        This flag isn't needed. Generators are enabled everywhere and
        part of a stable specification.

        * Configurations/FeatureDefines.xcconfig:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionDeclaration): Deleted.
        (JSC::Parser<LexerType>::parseClass): Deleted.
        (JSC::Parser<LexerType>::parseExportDeclaration): Deleted.
        (JSC::Parser<LexerType>::parseAssignmentExpression): Deleted.
        (JSC::Parser<LexerType>::parseProperty): Deleted.
        (JSC::Parser<LexerType>::parseFunctionExpression): Deleted.

2016-05-17  Keith Miller  <keith_miller@apple.com>

        Rollout r200426 since it causes PLT regressions.
        https://bugs.webkit.org/show_bug.cgi?id=157812

        Unreviewed rollout of r200426 since the bots see a ~.6% PLT regression from the patch.

2016-05-17  Keith Miller  <keith_miller@apple.com>

        Add test262 harness support code
        https://bugs.webkit.org/show_bug.cgi?id=157797

        Reviewed by Filip Pizlo.

        This patch adds some new tooling needed to run Test262 with the jsc
        CLI. There were three options that needed to be added for Test262:

        1) "--test262-async" This option overrides the print function in the test runner to look for
        'Test262:AsyncTestComplete' instead of printing the passed text. If test262-async mode is on
        and that string is not passed then the test is marked as failing.

        2) "--strict-file=<file>" This option appends `"use strict";\n` to the beginning of the
        passed file before passing the source code to the VM. This option can, in theory, be passed
        multiple times.

        3) "--exception=<name>" This option asserts that at the end of the last script file passed
        the VM has an uncaught exception with its name property equal to the passed name.

        * jsc.cpp:
        (Script::Script):
        (fillBufferWithContentsOfFile):
        (functionPrint):
        (checkUncaughtException):
        (runWithScripts):
        (printUsageStatement):
        (CommandLine::parseArguments):
        (runJSC):

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

        WTF should know about Language
        https://bugs.webkit.org/show_bug.cgi?id=157756

        Reviewed by Geoffrey Garen.

        Teach our scripts that a ObjC class beginning with WTF is totally cool.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2016-05-17  Joseph Pecoraro  <pecoraro@apple.com>

        console namespace breaks putting properties on console.__proto__
        https://bugs.webkit.org/show_bug.cgi?id=157782
        <rdar://problem/26250526>

        Reviewed by Geoffrey Garen.

        Some websites currently depend on console.__proto__ existing and being
        a separate object from Object.prototype. This patch adds back a basic
        console.__proto__ object, but all the console functions are left on
        the ConsoleObject itself.

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

2016-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, dump more information when math-pow-stable-results.js failed
        https://bugs.webkit.org/show_bug.cgi?id=157168

        * tests/stress/math-pow-stable-results.js:

2016-05-16  Saam barati  <sbarati@apple.com>

        ShadowChicken crashes when reading a scope from the frame during a stack overflow exception
        https://bugs.webkit.org/show_bug.cgi?id=157770

        Reviewed by Filip Pizlo.

        ShadowChicken was reading the scope from a half formed
        frame as it threw a stack overflow exception. The frame had
        a valid CodeBlock pointer, but it did not have a valid scope.
        The code in ShadowChicken's throw packet logging mechanism didn't
        account for this. The fix is to respect whether genericUnwind wants
        to unwind from the current frame or the caller's frame. For stack
        overflow errors, we always unwind the caller's frame.

        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):

2016-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r200208): It made 2 JSC stress tests fail on x86
        https://bugs.webkit.org/show_bug.cgi?id=157168

        Reviewed by Benjamin Poulain.

        The fast path in operationMathPow produces different results between x87 and the other environments.
        This is because x87 calculates the double value in 80bit precision.
        The situation is the following: in x86 32bit environment, floating point operations are compiled to
        x87 operations by default even if we can use SSE2. But in DFG environment, we aggressively use SSE2
        if the cpuid reports SSE2 is available. As a result, the implementations differ between C runtime
        and DFG JIT code. The C runtime uses x87 while DFG JIT code uses SSE2. This causes a precision
        problem since x87 has 80bit precision while SSE2 has 64bit precision.

        In this patch, in x86 32bit environment, we use `volatile double` if the `-mfpmath=sse and -msse2 (or later)`
        is not specified. This will round the x87 value into 64bit per multiplying. Note that this problem does not
        occur in OS X clang 32bit environment. This is because `-mfpmath=sse` is enabled by default in OS X clang 32bit.

        * b3/B3MathExtras.cpp:
        (JSC::B3::powDoubleInt32):
        * runtime/MathCommon.cpp:
        (JSC::operationMathPow):

2016-05-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] "return this" in a constructor does not need a branch on isObject(this)
        https://bugs.webkit.org/show_bug.cgi?id=157775

        Reviewed by Saam Barati and Ryosuke Niwa.

        When returning "this" in a constructor, the bytecode generator was generating:
            is_object         locX, this
            jtrue             locX, 5(->second ret)
            ret               this
            ret               this

        That code is eliminated in DFG but it is pretty costly lower tiers.

        This patch changes bytecode generation to avoid the is_object test
        when possible and not generate two ret if they encode the same thing.

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

2016-05-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove the index check from op_get_by_val/op_put_by_val when the index is constant
        https://bugs.webkit.org/show_bug.cgi?id=157766

        Reviewed by Geoffrey Garen.

        If the index is an integer constant, do not generate the index check.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitSlow_op_put_by_val):

2016-05-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][DFG] Fill spilled Int32 as Int32 instead of JSInt32
        https://bugs.webkit.org/show_bug.cgi?id=157700

        Reviewed by Michael Saboff.

        In general, fillSpeculateInt32() originate from SpeculateInt32
        and the user does not care about the tag.

        This is particularily obvious on Sunspider's math-spectral-norm.js.
        In that test, registers are frequently spilled because of x86's DIV.

        When they are re-filled, they were always tagged.
        Since the loops are small, all the tagging adds up.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):

2016-05-16  Saam barati  <sbarati@apple.com>

        Unreviewed Cloop build fix.

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

2016-05-16  Saam barati  <sbarati@apple.com>

        Hook up ShadowChicken to the debugger to show tail deleted frames
        https://bugs.webkit.org/show_bug.cgi?id=156685
        <rdar://problem/25770521>

        Reviewed by Filip Pizlo and Mark Lam and Joseph Pecoraro.

        The heart of this patch hooks up ShadowChicken to DebuggerCallFrame to
        allow the Web Inspector to display the ShadowChicken's shadow stack.
        This means the Web Inspector can now display tail deleted frames.
        To make this work, I made the necessary changes to ShadowChicken and
        DebuggerCallFrame to allow DebuggerCallFrame to keep the same API
        when representing both machine frames and tail deleted frames.

        - ShadowChicken prologue packets now log the current scope. Tail packets
          log the current scope, the 'this' value, the CodeBlock, and the
          CallSiteIndex. This allows the inspector to not only show the
          tail deleted frame, but also show exactly where the tail call happened (line and column numbers),
          with which scope it executed, and with which 'this' value. This
          patch also allows DebuggerCallFrame to execute console statements
          in a tail deleted frame.

        - I changed ShadowChicken's stack resizing algorithm. ShadowChicken
          now only keeps a maximum number of tail deleted frames in its shadow stack.
          It will happily represent all machine frames without limit. Right now, the
          maximum number of tail deleted frames I chose to keep alive is 128.
          We will keep frames alive starting from the top of the stack. This
          allows us to have a strong defense against runaway memory usage. We will only
          keep around at most 128 "shadow" frames that wouldn't have naturally been kept
          alive by the executing program. We can play around with this number
          if we find that 128 is either too many or too few frames.

        - DebuggerCallFrame is no longer a cheap class to create. When it is created,
          we will eagerly create the entire virtual debugger stack. So I modified the
          existing code to lazily create DebuggerCallFrames only when necessary. We
          used to eagerly create them at each op_debug statement even though we would
          just throw them away if we didn't hit a breakpoint.

        - A valid DebuggerCallFrame will always have a valid CallFrame* pointer
          into the stack. This pointer won't always refer to the logical frame
          that the DebuggerCallFrame represents because a DebuggerCallFrame can
          now represent a tail deleted frame. To do this, DebuggerCallFrame now
          has a ShadowChicken::Frame member variable. This allows DebuggerCallFrame
          to know when it represents a tail deleted frame and gives DebuggerCallFrame
          a mechanism to ask the tail deleted frame for interesting information
          (like its 'this' value, scope, CodeBlock, etc). A tail deleted frame's
          machine frame pointer will be the machine caller of the tail deleted frame
          (or the machine caller of the first of a series of consecutive tail calls).

        - I added a new flag to UnlinkedCodeBlock to indicate when it is compiled
          with debugging opcodes. I did this because ShadowChicken may read a JSScope
          from the machine stack. This is only safe if the machine CodeBlock was
          compiled with debugging opcodes. This is safer than asking if the
          CodeBlock's global object has an interactive debugger enabled because
          it's theoretically possible for the debugger to be enabled while code
          compiled without a debugger is still live on the stack. This field is
          also now used to indicate to the DFGGraph that the interactive debugger
          is enabled.

        - Finally, this patch adds a new field to the Inspector's CallFrame protocol
          object called 'isTailDeleted' to allow the Inspector to know when a
          CallFrame represents a tail deleted frame.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::findPC):
        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearDebuggerRequests):
        (JSC::CodeBlock::wasCompiledWithDebuggingOpcodes):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes):
        (JSC::UnlinkedCodeBlock::finishCreation):
        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
        (JSC::BytecodeGenerator::emitCallDefineProperty):
        * debugger/Debugger.cpp:
        (JSC::DebuggerPausedScope::DebuggerPausedScope):
        (JSC::DebuggerPausedScope::~DebuggerPausedScope):
        (JSC::Debugger::didReachBreakpoint):
        (JSC::Debugger::currentDebuggerCallFrame):
        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::LineAndColumnFunctor::operator()):
        (JSC::DebuggerCallFrame::create):
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::callerFrame):
        (JSC::DebuggerCallFrame::globalExec):
        (JSC::DebuggerCallFrame::vmEntryGlobalObject):
        (JSC::DebuggerCallFrame::sourceID):
        (JSC::DebuggerCallFrame::functionName):
        (JSC::DebuggerCallFrame::scope):
        (JSC::DebuggerCallFrame::type):
        (JSC::DebuggerCallFrame::thisValue):
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        (JSC::DebuggerCallFrame::invalidate):
        (JSC::DebuggerCallFrame::currentPosition):
        (JSC::DebuggerCallFrame::positionForCallFrame):
        (JSC::DebuggerCallFrame::sourceIDForCallFrame):
        (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor): Deleted.
        (JSC::FindCallerMidStackFunctor::operator()): Deleted.
        (JSC::FindCallerMidStackFunctor::getCallerFrame): Deleted.
        (JSC::DebuggerCallFrame::thisValueForCallFrame): Deleted.
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::isValid):
        (JSC::DebuggerCallFrame::isTailDeleted):
        (JSC::DebuggerCallFrame::create): Deleted.
        (JSC::DebuggerCallFrame::exec): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::~Graph):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addCallSite):
        (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
        (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
        (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
        (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
        (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket): Deleted.
        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy):
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::thisObject):
        (Inspector::JSJavaScriptCallFrame::isTailDeleted):
        (Inspector::JSJavaScriptCallFrame::type):
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
        (Inspector::jsJavaScriptCallFrameAttributeType):
        (Inspector::jsJavaScriptCallFrameIsTailDeleted):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::type):
        (Inspector::JavaScriptCallFrame::scopeChain):
        (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
        (Inspector::JavaScriptCallFrame::isTailDeleted):
        (Inspector::JavaScriptCallFrame::thisValue):
        (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        * inspector/protocol/Debugger.json:
        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):
        (JSC::ShadowChicken::visitChildren):
        (JSC::ShadowChicken::reset):
        * interpreter/ShadowChicken.h:
        (JSC::ShadowChicken::Packet::throwMarker):
        (JSC::ShadowChicken::Packet::prologue):
        (JSC::ShadowChicken::Packet::tail):
        (JSC::ShadowChicken::Frame::Frame):
        (JSC::ShadowChicken::Frame::operator==):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::logShadowChickenProloguePacket):
        (JSC::CCallHelpers::logShadowChickenTailPacket):
        (JSC::CCallHelpers::ensureShadowChickenPacket):
        (JSC::CCallHelpers::setupShadowChickenPacket): Deleted.
        * jit/CCallHelpers.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        (JSC::JIT::emit_op_get_enumerable_length):
        (JSC::JIT::emit_op_resume):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
        (JSC::RegisterSet::argumentGPRS):
        (JSC::RegisterSet::registersToNotSaveForJSCall):
        * jit/RegisterSet.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/Options.h:
        * tests/stress/shadow-chicken-enabled.js:
        (test5a.foo):
        (test5a):
        (test5b.foo):
        (test5b):
        (test6.foo):
        (test6):

2016-05-16  Saam barati  <sbarati@apple.com>

        TypeSet/StructureShape have a flawed sense of JS prototype chains
        https://bugs.webkit.org/show_bug.cgi?id=157760

        Reviewed by Joseph Pecoraro.

        There was an assumption that we would bottom out in "Object". This is
        not true for many reasons. JS objects may not end in Object.prototype.
        Also, our mechanism of grabbing an Object's class name may also not
        bottom out in "Object". We were seeing this in the JS objects we use
        in the InjectedScriptSource.js inspector script.

        * runtime/TypeSet.cpp:
        (JSC::StructureShape::leastCommonAncestor):
        * tests/typeProfiler/weird-prototype-chain.js: Added.
        (wrapper.foo):
        (wrapper.let.o2):
        (wrapper):

2016-05-16  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed rollout r200924. Caused js/regress/string-replace-generic.html to fail.

        * API/JSProfilerPrivate.cpp: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
        (JSStartProfiling):
        (JSEndProfiling):
        * API/JSProfilerPrivate.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister):
        (JSC::BytecodeGenerator::shouldEmitProfileHooks):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * inspector/protocol/Timeline.json:
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call):
        (JSC::JIT::emit_op_profile_did_call):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call):
        (JSC::JIT::emit_op_profile_did_call):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Added.
        (JSC::CallIdentifier::CallIdentifier):
        (JSC::CallIdentifier::functionName):
        (JSC::CallIdentifier::url):
        (JSC::CallIdentifier::lineNumber):
        (JSC::CallIdentifier::columnNumber):
        (JSC::CallIdentifier::operator==):
        (JSC::CallIdentifier::operator!=):
        (JSC::CallIdentifier::Hash::hash):
        (JSC::CallIdentifier::Hash::equal):
        (JSC::CallIdentifier::hash):
        (JSC::CallIdentifier::operator const char*):
        (JSC::CallIdentifier::c_str):
        (WTF::HashTraits<JSC::CallIdentifier>::constructDeletedValue):
        (WTF::HashTraits<JSC::CallIdentifier>::isDeletedValue):
        * profiler/LegacyProfiler.cpp: Added.
        (JSC::LegacyProfiler::profiler):
        (JSC::LegacyProfiler::startProfiling):
        (JSC::LegacyProfiler::stopProfiling):
        (JSC::callFunctionForProfilesWithGroup):
        (JSC::LegacyProfiler::suspendProfiling):
        (JSC::LegacyProfiler::unsuspendProfiling):
        (JSC::LegacyProfiler::willExecute):
        (JSC::LegacyProfiler::didExecute):
        (JSC::LegacyProfiler::exceptionUnwind):
        (JSC::LegacyProfiler::createCallIdentifier):
        (JSC::createCallIdentifierFromFunctionImp):
        * profiler/LegacyProfiler.h: Added.
        (JSC::LegacyProfiler::currentProfiles):
        * profiler/Profile.cpp: Added.
        (JSC::Profile::create):
        (JSC::Profile::Profile):
        (JSC::Profile::~Profile):
        (JSC::Profile::debugPrint):
        (JSC::functionNameCountPairComparator):
        (JSC::Profile::debugPrintSampleStyle):
        * profiler/Profile.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h.
        * profiler/ProfileGenerator.cpp: Added.
        (JSC::ProfileGenerator::create):
        (JSC::ProfileGenerator::ProfileGenerator):
        (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor):
        (JSC::AddParentForConsoleStartFunctor::foundParent):
        (JSC::AddParentForConsoleStartFunctor::operator()):
        (JSC::ProfileGenerator::addParentForConsoleStart):
        (JSC::ProfileGenerator::title):
        (JSC::ProfileGenerator::beginCallEntry):
        (JSC::ProfileGenerator::endCallEntry):
        (JSC::ProfileGenerator::willExecute):
        (JSC::ProfileGenerator::didExecute):
        (JSC::ProfileGenerator::exceptionUnwind):
        (JSC::ProfileGenerator::stopProfiling):
        (JSC::ProfileGenerator::removeProfileStart):
        (JSC::ProfileGenerator::removeProfileEnd):
        * profiler/ProfileGenerator.h: Added.
        (JSC::ProfileGenerator::profile):
        (JSC::ProfileGenerator::origin):
        (JSC::ProfileGenerator::profileGroup):
        (JSC::ProfileGenerator::setIsSuspended):
        * profiler/ProfileNode.cpp: Added.
        (JSC::ProfileNode::ProfileNode):
        (JSC::ProfileNode::addChild):
        (JSC::ProfileNode::removeChild):
        (JSC::ProfileNode::spliceNode):
        (JSC::ProfileNode::traverseNextNodePostOrder):
        (JSC::ProfileNode::debugPrint):
        (JSC::ProfileNode::debugPrintSampleStyle):
        (JSC::ProfileNode::debugPrintRecursively):
        (JSC::ProfileNode::debugPrintSampleStyleRecursively):
        * profiler/ProfileNode.h: Added.
        (JSC::ProfileNode::create):
        (JSC::ProfileNode::Call::Call):
        (JSC::ProfileNode::Call::startTime):
        (JSC::ProfileNode::Call::setStartTime):
        (JSC::ProfileNode::Call::elapsedTime):
        (JSC::ProfileNode::Call::setElapsedTime):
        (JSC::ProfileNode::operator==):
        (JSC::ProfileNode::callerCallFrame):
        (JSC::ProfileNode::callIdentifier):
        (JSC::ProfileNode::id):
        (JSC::ProfileNode::functionName):
        (JSC::ProfileNode::url):
        (JSC::ProfileNode::lineNumber):
        (JSC::ProfileNode::columnNumber):
        (JSC::ProfileNode::parent):
        (JSC::ProfileNode::setParent):
        (JSC::ProfileNode::calls):
        (JSC::ProfileNode::lastCall):
        (JSC::ProfileNode::appendCall):
        (JSC::ProfileNode::children):
        (JSC::ProfileNode::firstChild):
        (JSC::ProfileNode::lastChild):
        (JSC::ProfileNode::nextSibling):
        (JSC::ProfileNode::setNextSibling):
        (JSC::ProfileNode::forEachNodePostorder):
        (JSC::CalculateProfileSubtreeDataFunctor::operator()):
        (JSC::CalculateProfileSubtreeDataFunctor::returnValue):
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal):
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::~JSGlobalObject):
        (JSC::JSGlobalObject::hasLegacyProfiler):
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::SetEnabledProfilerFunctor::operator()):
        (JSC::VM::setEnabledProfiler):
        * runtime/VM.h:
        (JSC::VM::enabledProfiler):
        (JSC::VM::enabledProfilerAddress):

2016-05-16  Konstantin Tokarev  <annulen@yandex.ru>

        Unreviewed, fixed typo in a comment.

        * assembler/MacroAssembler.h: Replaced "onvenience" with
        "convenience".

2016-05-16  Filip Pizlo  <fpizlo@apple.com>

        FixupPhase should be more eager to demote bit math to untyped
        https://bugs.webkit.org/show_bug.cgi?id=157746

        Reviewed by Mark Lam.
        
        This just makes the logic for how we fixup bit math match the way we do it in other places.
        This doesn't affect performance on any major benchmark but it's a big win on new
        microbenchmarks added in this change.
        
        Details:

        object-and                                     11.1610+-0.7602     ^      4.8105+-0.1690        ^ definitely 2.3201x faster
        object-or                                      11.0845+-0.2487     ^      4.7146+-0.0374        ^ definitely 2.3511x faster
        object-xor                                     10.2946+-0.9946     ^      4.7278+-0.0814        ^ definitely 2.1775x faster
        object-lshift                                  10.4896+-1.0867     ^      4.7699+-0.0721        ^ definitely 2.1991x faster
        object-rshift                                  11.1239+-0.5010     ^      4.7194+-0.0445        ^ definitely 2.3570x faster
        object-urshift                                 10.9745+-0.1315     ^      4.7848+-0.0479        ^ definitely 2.2936x faster

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

2016-05-15  Michael Saboff  <msaboff@apple.com>

        RegExp /y flag incorrect handling of mixed-length alternation
        https://bugs.webkit.org/show_bug.cgi?id=157723

        Reviewed by Filip Pizlo.

        Previously for sticky patterns, we were bailing out and exiting when backtracking
        alternatives with dissimilar match lengths.  Deleted that code.  Instead, for
        sticky patterns we need to process the backtracking except for advancing to the
        next input index.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::backtrack):

2016-05-15  Filip Pizlo  <fpizlo@apple.com>

        DFG::Plan shouldn't read from its VM once it's been cancelled
        https://bugs.webkit.org/show_bug.cgi?id=157726

        Reviewed by Saam Barati.
        
        Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a
        cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling
        the plan.
        
        Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody
        would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard
        regression to spot because usually a cancelled plan will still refer to a valid VM.
        
        This change fixes the regression and makes it a lot easier to spot the regression in the
        future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this
        mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is
        cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to
        use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst.
        
        Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the
        plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the
        safepoint's VM to determine whether this is one of our safepoints *after* the plan is
        already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled
        when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's
        vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one
        loop and a cancel path for Safepoints in the loop after it).

        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::computeCompileTimes):
        (JSC::DFG::Plan::reportCompileTimes):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::notifyCompiling):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::cancel):
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::canTierUpAndOSREnter):
        * dfg/DFGSafepoint.cpp:
        (JSC::DFG::Safepoint::cancel):
        (JSC::DFG::Safepoint::vm):
        * dfg/DFGSafepoint.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::isActiveForVM):
        (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
        (JSC::DFG::Worklist::removeAllReadyPlansForVM):
        (JSC::DFG::Worklist::rememberCodeBlocks):
        (JSC::DFG::Worklist::visitWeakReferences):
        (JSC::DFG::Worklist::removeDeadPlans):
        (JSC::DFG::Worklist::runThread):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):

2016-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        Modernize Intl constructors; using InternalFunction::createSubclassStructure
        https://bugs.webkit.org/show_bug.cgi?id=157082

        Reviewed by Darin Adler.

        Previously, Intl constructors retrieve "prototype" to inherit the "new.target".
        At that time, this mis-assumed that getDirect() always returns meaningful JS value.
        Actually, it returns an empty value if a property does not exist.

        Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure
        in Intl constructors. It is modern and preferable way since it can cache the derived
        structures in InternalFunction.

        This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat.
        Those code are largely duplicate. This is now extracted into
        constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not
        have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat
        and LayoutTests/js/intl-numberformat.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/IntlCollator.cpp:
        (JSC::IntlCollator::create):
        * runtime/IntlCollator.h:
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::create):
        * runtime/IntlDateTimeFormat.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::create):
        * runtime/IntlNumberFormat.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObjectInlines.h: Added.
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * tests/stress/intl-constructors-with-proxy.js: Added.
        (shouldBe):
        (throw.new.Error.Empty):
        (throw.new.Error):
        (shouldBe.Empty):

2016-05-14  Joseph Pecoraro  <pecoraro@apple.com>

        Remove LegacyProfiler
        https://bugs.webkit.org/show_bug.cgi?id=153565

        Reviewed by Mark Lam.

        JavaScriptCore now provides a sampling profiler and it is enabled
        by all ports. Web Inspector switched months ago to using the
        sampling profiler and displaying its data. Remove the legacy
        profiler, as it is no longer being used by anything other then
        console.profile and tests. We will update console.profile's
        behavior soon to have new behavior and use the sampling data.

        * API/JSProfilerPrivate.cpp: Removed.
        * API/JSProfilerPrivate.h: Removed.
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Deleted.
        (JSC::computeDefsForBytecodeOffset): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::profileHookRegister): Deleted.
        (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::CallArguments::CallArguments): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): Deleted.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
        * inspector/protocol/Timeline.json:
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()): Deleted.
        (JSC::Interpreter::execute): Deleted.
        (JSC::Interpreter::executeCall): Deleted.
        (JSC::Interpreter::executeConstruct): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Deleted.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_will_call): Deleted.
        (JSC::JIT::emit_op_profile_did_call): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ParserModes.h:
        * profiler/CallIdentifier.h: Removed.
        * profiler/LegacyProfiler.cpp: Removed.
        * profiler/LegacyProfiler.h: Removed.
        * profiler/Profile.cpp: Removed.
        * profiler/Profile.h: Removed.
        * profiler/ProfileGenerator.cpp: Removed.
        * profiler/ProfileGenerator.h: Removed.
        * profiler/ProfileNode.cpp: Removed.
        * profiler/ProfileNode.h: Removed.
        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal): Deleted.
        * profiler/ProfilerJettisonReason.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):
        (JSC::JSGlobalObject::createModuleProgramCodeBlock):
        (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
        (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM): Deleted.
        (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
        (JSC::VM::setEnabledProfiler): Deleted.
        * runtime/VM.h:
        (JSC::VM::enabledProfiler): Deleted.
        (JSC::VM::enabledProfilerAddress): Deleted.

2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash
        https://bugs.webkit.org/show_bug.cgi?id=157704

        Reviewed by Saam Barati.

        * jsc.cpp:
        (functionStartSamplingProfiler):
        (functionSamplingProfilerStackTraces):
        Throw an exception instead of crashing if we haven't started sampling.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::startTracking):
        * runtime/VM.h:
        * runtime/VM.cpp:
        (JSC::VM::ensureSamplingProfiler):
        Switch ensure to returning a reference, like most other ensures.

2016-05-13  Saam barati  <sbarati@apple.com>

        DFG/FTL have a few bugs in their reasoning about the scope
        https://bugs.webkit.org/show_bug.cgi?id=157696

        Reviewed by Benjamin Poulain.

        1. When the debugger is enabled, it is easier for the DFG to reason
        about the scope register by simply claiming all nodes read the scope
        register. This prevents us from ever entering the runtime where we
        may take a stack trace but there isn't a scope on the stack.

        2. This patch fixes a bug where the FTL compilation wasn't properly
        setting the CodeBlock register. It was only doing this when there
        was inline data, but when the debugger is enabled, we never inline.
        So this code just needed to be removed from that loop. It was never
        right for it to be inside the loop.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2016-05-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] SetLocal without exit do not need phantoms
        https://bugs.webkit.org/show_bug.cgi?id=157653

        Reviewed by Filip Pizlo.

        I made a mistake in r200498.

        If a SetLocal cannot possibly exit, we were not clearing
        the source of the operand. As a result, we sometime kept
        a value alive up to the end of the block.

        That's uncommon because SetLocal typically appear
        toward the end of blocks. That's probably why there was
        no perf impact with that fix.

        * dfg/DFGPhantomInsertionPhase.cpp:

2016-05-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Move the CheckTierUp function calls out of the main path
        https://bugs.webkit.org/show_bug.cgi?id=157668

        Reviewed by Mark Lam.

        If you have a tiny tiny loop (for example, Sunspider's bits-in-byte),
        the size of CheckTierUp is a problem.

        On multi-issue CPUs, the node is so big that we do not
        get to run anything from the loop in the instruction fetch.

        On x86, having a bigger loop also pushes us out of the LSD.

        This is a 6% improvement on bits-in-byte. Other Sunspider tests
        only improves marginally.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentSpill):
        (JSC::DFG::SpeculativeJIT::silentFill):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2016-05-13  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used
        https://bugs.webkit.org/show_bug.cgi?id=157671

        Reviewed by Mark Lam.

        This improves the chances of having a value
        when issuing the TEST.

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

2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Inform augmenting client when inspector controller is destroyed
        https://bugs.webkit.org/show_bug.cgi?id=157688
        <rdar://problem/25832724>

        Reviewed by Timothy Hatcher.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
        * inspector/augmentable/AugmentableInspectorControllerClient.h:
        There is a weak relationship between the InspectorController and the
        AugmentingClient. Let the augmenting client know when the controller
        is destroyed so it doesn't try to use us anymore.

2016-05-13  Geoffrey Garen  <ggaren@apple.com>

        Runaway malloc memory usage in this simple JSC program
        https://bugs.webkit.org/show_bug.cgi?id=157682

        Reviewed by Mark Lam.

        * heap/WeakSet.cpp:
        (JSC::WeakSet::sweep): Whenever we might add a block to
        m_logicallyEmptyWeakBlocks, be sure also to sweep a block in
        m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals
        even when all memory is freed.

        We do this whenever we *might* add a block and not just whenever we *do*
        add a block because we'd like to sweep the entries in
        m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this
        is a reasonably rate-limited opportunity to do so.

2016-05-13  Mark Lam  <mark.lam@apple.com>

        We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM.
        https://bugs.webkit.org/show_bug.cgi?id=157537
        <rdar://problem/24794845>

        Reviewed by Michael Saboff.

        The pre-existing code behaves this way:

        1. When JS code throws an exception, it saves callee save registers in
           the VM calleeSaveRegistersBuffer.  These values are meant to be restored
           to the callee save registers later either at the catch handler or at the
           uncaught exception handler.

        2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect
           the exception.  That C++ code can change the values of the callee save
           registers.

           The inspector code in turn re-enters the VM to execute JS inspector code.

           The JS inspector code can run hot enough that we do an enterOptimizationCheck
           on it.  The enterOptimizationCheck first saves all callee save registers
           into the VM calleeSaveRegistersBuffer.

           This effectively overwrites the values in the VM calleeSaveRegistersBuffer
           from (1).

        3. Eventually, execution returns to the catch handler or the uncaught exception
           handler which restores the overwritten values in the VM
           calleeSaveRegistersBuffer to the callee save registers.

           When execution returns to the C++ code that entered the VM before (1), the
           values in the callee registers are not what that code expects, and badness
           and/or crashes ensues.

        This patch applies the following fix:
        
        1. Allocate space in the VMEntryFrame for the calleeSaveRegistersBuffer.
           This ensures that each VM entry session has its own buffer to use, and will
           not corrupt the one from the previous VM entry session.

           Delete the VM calleeSaveRegistersBuffer.

        2. Change all locations that uses the VM calleeSaveRegistersBuffer to use the
           calleeSaveRegistersBuffer in the current VMEntryFrame.

        3. Renamed all uses of the term "VMCalleeSavesBuffer" to
           "VMEntryFrameCalleeSavesBuffer".

        This fix has been tested on the following configurations:
        1. JSC and layout tests on a debug ASan build for 64-bit x86_64.
        2. JSC tests on a release ASan build for 32-bit x86.
        3. JSC tests on a release normal (non-ASan) build for ARM64.
        4. JSC tests on a release normal (non-ASan) build for ARMv7 and ARMv7s.
        5. JSC tests on a release ASan CLOOP build for x86_64.

        These test runs did not produce any new crashes.  The ASan CLOOP has some
        pre-existing crashes which are not due to this patch.

        This bug can be tested by running the inspector/debugger/regress-133182.html test
        on an ASan build.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
        * interpreter/Interpreter.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        * interpreter/VMEntryRecord.h:
        (JSC::VMEntryRecord::calleeSaveRegistersBufferOffset):
        (JSC::VMEntryRecord::prevTopCallFrame):
        (JSC::VMEntryRecord::unsafePrevTopCallFrame):
        (JSC::VMEntryFrame::vmEntryRecordOffset):
        (JSC::VMEntryFrame::calleeSaveRegistersBufferOffset):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitRandomThunk):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::nativeForGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::vmEntryRecord):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::getCTIStub):
        (JSC::VM::calleeSaveRegistersBufferOffset): Deleted.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::endFunction):

2016-05-13  Beth Dakin  <bdakin@apple.com>

        Add dyldSPI.h for linked on or after checks, and add one for link preview
        https://bugs.webkit.org/show_bug.cgi?id=157401
        -and corresponding-
        rdar://problem/26253396

        Reviewed by Darin Adler.

        Import #import <wtf/spi/darwin/dyldSPI.h> which now declares all of the 
        needed dyld code.
        * API/JSWrapperMap.mm:

2016-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for direct eval in non-class method
        https://bugs.webkit.org/show_bug.cgi?id=157138

        Reviewed by Saam Barati.

        This assertion was incorrect. In method definitions in object literals,
        it can be sloppy mode, but its DerivedContextType may not be DerivedContextType::None.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::CacheKey::CacheKey):
        (JSC::EvalCodeCache::CacheKey::operator==):
        (JSC::EvalCodeCache::CacheKey::Hash::equal):
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * tests/stress/direct-eval-in-object-literal-methods.js: Added.
        (shouldBe):
        (throw.new.Error):
        (shouldBe.Parent.prototype.l):
        (shouldBe.Parent):
        (shouldBe.Derived.prototype.m):
        (shouldBe.Derived):

2016-05-13  Skachkov Oleksandr  <gskachkov@gmail.com>

        Assertion failure for super() call in arrow function default parameters
        https://bugs.webkit.org/show_bug.cgi?id=157079

        Reviewed by Saam Barati.

        Root of the issue that in arrow function we load bounded variables this/super/new.target just after 
        input parameters were initialized, and did not covered case of default values for 
        function parameters. 
        Current patch tried to fix issue and allow to load bounded variables earlier, before the input 
        parameters are assigned by default values.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * tests/stress/arrowfunction-lexical-bind-this-2.js:

2016-05-12  Mark Lam  <mark.lam@apple.com>

        Baseline and DFG's JSC_report...CompileTimes needs CodeBlock hashes.
        https://bugs.webkit.org/show_bug.cgi?id=157643

        Reviewed by Keith Miller.

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

2016-05-12  Csaba Osztrogonác  <ossy@webkit.org>

        Remove ENABLE(ES6_ARROWFUNCTION_SYNTAX) guards
        https://bugs.webkit.org/show_bug.cgi?id=157564

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:
        * parser/Parser.cpp:

2016-05-12  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CRASH getting internal properties of function with no bound arguments causes
        https://bugs.webkit.org/show_bug.cgi?id=157613
        <rdar://problem/26238754>

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Gracefully handle a JSBoundFunction with no bound arguments.
        In this case boundArgs is JSValue() which we don't want to
        expose as the value of the internal property.

2016-05-11  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Make sure StringRange is passed to Vector by register
        https://bugs.webkit.org/show_bug.cgi?id=157603

        Reviewed by Darin Adler.

        This is bizarre, but on my SDK, Vector::append(StringRange)
        is passing the values on the stack.
        The two integers are written to the stack, the address given
        to append(), then append() reads it back and store it.

        This patch changes the code to use constructAndAppend(), ensuring
        the values are used directly.

        On my machine, this helps Sunspider and Octane.
        This might be something wrong with my SDK but the fix is so easy
        that we might as well do this.

        * runtime/StringPrototype.cpp:
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):

2016-05-11  Zan Dobersek  <zdobersek@igalia.com>

        ARMv7Assembler: suppress a -Wnarrowing warning when compiling with GCC
        https://bugs.webkit.org/show_bug.cgi?id=157576

        Reviewed by Csaba Osztrogonác.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): Explicitly cast the
        `OP_CMP_reg_T2 | left` value to uint16_t, avoiding a narrowing conversion
        warning that's being reported when compiling with GCC. The warning is sprung
        due to RegisterID (which is the type of `left`) being an enum based on int,
        even when the enum itself only declares 23 values.

2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: `this` in Scope Chain Sidebar does not have preview, looks poor
        https://bugs.webkit.org/show_bug.cgi?id=157602

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.CallFrameProxy):
        Include a preview when creating the RemoteObject for `this`.

2016-05-11  Keith Miller  <keith_miller@apple.com>

        Unreviewed, correct the title of the ChangeLog for r200667.

2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>

        JSC test stress/reflect-set.js failing after 200694
        https://bugs.webkit.org/show_bug.cgi?id=157586

        Unreviewed test rebaseline.

        * tests/stress/reflect-set.js:
        Update the expected error message. We are in strict mode, so the
        improved error message makes sense.

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

        Beef up JSC profiler event log
        https://bugs.webkit.org/show_bug.cgi?id=157584

        Reviewed by Saam Barati.
        
        Also log more about compilation.

        * bytecode/ExecutionCounter.cpp: Changed the meaning of codeBlock to be the codeBlock that is doing the profiling. This will now get the baseline version if it needs it. This is needed for logging the threshold checking event.
        (JSC::applyMemoryUsageHeuristics):
        (JSC::ExecutionCounter<countingVariant>::hasCrossedThreshold):
        * dfg/DFGJITCode.cpp: Pass the right codeBlock.
        (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
        (JSC::DFG::JITCode::optimizeNextInvocation):
        (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
        (JSC::DFG::JITCode::optimizeSoon):
        (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
        * dfg/DFGPlan.cpp: Log things about compile times and whether the compiler succeeded or failed.
        (JSC::DFG::Plan::computeCompileTimes):
        (JSC::DFG::Plan::reportCompileTimes):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        * jit/ExecutableAllocatorFixedVMPool.cpp: Make it possible to look at memory usage, though separately from the log, for now.
        (JSC::ExecutableAllocator::allocate):
        * runtime/Options.h:

2016-05-11  Saam barati  <sbarati@apple.com>

        Air may decide to put the result register of an arithmetic snippet in the tag register
        https://bugs.webkit.org/show_bug.cgi?id=157548

        Reviewed by Filip Pizlo.

        This patch adds a new ValueRep to B3 called LateRegister. The semantics
        are similar to Register in that it can be used to pin an argument to
        a particular register. It differs from ValueRep::Register in that the semantics of
        LateRegister are that it is used after the result of the node its an argument to
        is computed. This means that a LateRegister argument will interfere with the result
        of a node. LateRegister is not a valid result ValueRep.

        This was needed because there was a bug where B3/Air would assign the
        result of a patchpoint to the TagTypeNumber register. This broke our
        code when we would box a double into a JSValue in a snippet when the
        result is the same as the TagTypeNumber register. To fix the issue,
        we pass TagMaskRegister and TagTypeNumberRegister as ValueRep::LateRegister
        arguments to various patchpoints.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo):
        (JSC::B3::ValueRep::dump):
        (JSC::B3::ValueRep::emitRestore):
        (JSC::B3::ValueRep::recoveryForJSValue):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::lateReg):
        (JSC::B3::ValueRep::stack):
        (JSC::B3::ValueRep::operator==):
        (JSC::B3::ValueRep::isSomeRegister):
        (JSC::B3::ValueRep::isReg):
        * b3/testb3.cpp:
        (JSC::B3::testSpillUseLargerThanDef):
        (JSC::B3::testLateRegister):
        (JSC::B3::zero):
        (JSC::B3::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::lower):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
        (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):

2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>

        Improve error messages for accessing arguments.callee and similar getters in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=157545

        Reviewed by Mark Lam.

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        Provide better error GetterSetter in strict mode.

        * runtime/JSFunction.cpp:
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::defineOwnProperty):
        Provide better error GetterSetter in strict mode.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncThrowTypeErrorCalleeAndCaller):
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode):
        (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext):
        (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): Deleted.
        * runtime/JSGlobalObjectFunctions.h:
        Rename and expose new handles for new error getter setter native functions.

2016-05-11  Commit Queue  <commit-queue@webkit.org>

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

        it's bad news for asm.js (Requested by pizlo on #webkit).

        Reverted changeset:

        "Reduce maximum JIT pool size on X86_64."
        http://trac.webkit.org/changeset/200481

2016-05-10  Keith Miller  <keith_miller@apple.com>

        TypedArray.prototype.slice should not use the byteLength of the passed array for memmove
        https://bugs.webkit.org/show_bug.cgi?id=157551
        <rdar://problem/26179914>

        Reviewed by Michael Saboff.

        The TypedArray.prototype.slice function would use the byteLength of the passed array
        to determine the amount of data to copy. It should have been using the passed length
        times the size of each element. This fixes a crash on JavaPoly.com

        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        * tests/stress/typedarray-slice.js:

2016-05-10  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r200447): Unable to build C_LOOP with clang version 800.0.12 or higher
        https://bugs.webkit.org/show_bug.cgi?id=157549

        Reviewed by Keith Miller.

        Disable debug annotations for C_LOOP builds.  They are inline assembly directives,
        unnecessary and they cause syntax errors.

        * offlineasm/asm.rb:

2016-05-10  Filip Pizlo  <fpizlo@apple.com>

        Internal JSC profiler should have a timestamped log of events for each code block
        https://bugs.webkit.org/show_bug.cgi?id=157538

        Reviewed by Benjamin Poulain.
        
        For example, in 3d-cube, I can query the events for MMulti and I get:

        1462917476.17083  MMulti#DTZ7qc                          installCode        
        1462917476.179663 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
        1462917476.179664 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline osrEntry           at bc#49
        1462917476.185651 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1011.214233/1717.000000, -707
        1462917476.187913 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      installCode        
        1462917476.187917 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      osrEntry           at bc#49
        1462917476.205365 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      jettison           due to OSRExit, counting = true, detail = (null)
        1462917476.205368 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#65: BadCache/FromDFG
        1462917476.205369 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
        1462917476.205482 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/3434.000000, -1000
        1462917476.211547 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/3434.000000, -1000
        1462917476.213721 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      installCode        
        1462917476.213726 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      osrEntry           at bc#49
        1462917476.223976 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      jettison           due to OSRExit, counting = true, detail = (null)
        1462917476.223981 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#77: BadCache/FromDFG
        1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#94: BadCache/FromDFG
        1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
        1462917476.224064 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/6868.000000, -1000
        1462917476.224151 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/6868.000000, -1000
        1462917476.224258 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 3013.000000/6868.000000, -1000
        1462917476.224337 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 4023.000000/6868.000000, -1000
        1462917476.224425 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 5023.000000/6868.000000, -1000
        1462917476.224785 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 6023.396484/6868.000000, -862
        1462917476.227669 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      installCode        
        1462917476.227675 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      osrEntry           at bc#0
        
        The output is ugly but useful. We can make it less ugly later.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlock.h:
        (JSC::ScriptExecutable::forEachCodeBlock):
        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::ExitProfile::add):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGOperations.cpp:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::Compilation):
        (JSC::Profiler::Compilation::setJettisonReason):
        (JSC::Profiler::Compilation::dump):
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerCompilation.h:
        (JSC::Profiler::Compilation::uid):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::ensureBytecodesFor):
        (JSC::Profiler::Database::notifyDestruction):
        (JSC::Profiler::Database::addCompilation):
        (JSC::Profiler::Database::toJS):
        (JSC::Profiler::Database::registerToSaveAtExit):
        (JSC::Profiler::Database::logEvent):
        (JSC::Profiler::Database::addDatabaseToAtExit):
        * profiler/ProfilerDatabase.h:
        * profiler/ProfilerEvent.cpp: Added.
        (JSC::Profiler::Event::dump):
        (JSC::Profiler::Event::toJS):
        * profiler/ProfilerEvent.h: Added.
        (JSC::Profiler::Event::Event):
        (JSC::Profiler::Event::operator bool):
        (JSC::Profiler::Event::time):
        (JSC::Profiler::Event::bytecodes):
        (JSC::Profiler::Event::compilation):
        (JSC::Profiler::Event::summary):
        (JSC::Profiler::Event::detail):
        * profiler/ProfilerUID.cpp: Added.
        (JSC::Profiler::UID::create):
        (JSC::Profiler::UID::dump):
        (JSC::Profiler::UID::toJS):
        * profiler/ProfilerUID.h: Added.
        (JSC::Profiler::UID::UID):
        (JSC::Profiler::UID::fromInt):
        (JSC::Profiler::UID::toInt):
        (JSC::Profiler::UID::operator==):
        (JSC::Profiler::UID::operator!=):
        (JSC::Profiler::UID::operator bool):
        (JSC::Profiler::UID::isHashTableDeletedValue):
        (JSC::Profiler::UID::hash):
        (JSC::Profiler::UIDHash::hash):
        (JSC::Profiler::UIDHash::equal):
        * runtime/CommonIdentifiers.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        * runtime/VM.h:
        (JSC::VM::bytecodeIntrinsicRegistry):
        (JSC::VM::shadowChicken):
        * runtime/VMInlines.h:
        (JSC::VM::shouldTriggerTermination):
        (JSC::VM::logEvent):

2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Backend should initiate timeline recordings on page navigations to ensure nothing is missed
        https://bugs.webkit.org/show_bug.cgi?id=157504
        <rdar://problem/26188642>

        Reviewed by Brian Burg.

        * inspector/protocol/Timeline.json:
        Add protocol commands to enable/disable auto capture and list the
        instruments that should be enabled when auto capture starts.
        Add protocol event for when the backend starts an auto capture.

2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>

        Make the different evaluateWithScopeExtension implementations more consistent
        https://bugs.webkit.org/show_bug.cgi?id=157536

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        Throw the exception consistent with JSJavaScriptCallFrame.

        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        Better error message consistent with InjectedScriptHost.

        * runtime/Completion.h:
        * runtime/Completion.cpp:
        (JSC::evaluateWithScopeExtension):
        Give this an Exception out parameter like other evaluations
        so the caller can decide what to do with it.

2016-05-10  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FTL can produce GetByVal nodes without proper bounds checking
        https://bugs.webkit.org/show_bug.cgi?id=157502
        rdar://problem/26027027

        Reviewed by Filip Pizlo.

        It was possible for FTL to generates GetByVal on arbitrary offsets
        without any bounds checking.

        The bug is caused by the order of optimization phases:
        -First, the Integer Range Optimization proves that a CheckInBounds
         test can never fail.
         This proof is based on control flow or preceeding instructions
         inside a loop.
        -The Loop Invariant Code Motion phase finds that the GetByVal does not
         depend on anything in the loop and hoist it out of the loop.
        -> As a result, the conditions that were necessary to eliminate
           the CheckInBounds are no longer met before the GetByVal.

        This patch just moves the Integer Range Optimization phase after
        Loop Invariant Code Motion to make sure no code is moved after
        its integer ranges bounds proofs have been used.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * tests/stress/bounds-check-not-eliminated-by-licm.js: Added.
        (testInLoopTests):

2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Eliminate the crazy code for evaluateOnCallFrame
        https://bugs.webkit.org/show_bug.cgi?id=157510
        <rdar://problem/26191332>

        Reviewed by Timothy Hatcher.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        Set and clear an optional scope extension object.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.evaluate):
        (InjectedScript.prototype._evaluateOn):
        (InjectedScript.prototype.evaluateOnCallFrame):
        Unify the code to use the passed in evaluate function and object.
        When evaluating on a call frame the evaluate function ends up being
        DebuggerCallFrame::evaluateWithScopeExtension. When evaluating globally
        this ends up being JSInjectedScriptHost::evaluateWithScopeExtension.
        In both cases "object" is the preferred this object to use.

        * debugger/DebuggerCallFrame.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
        (Inspector::JSJavaScriptCallFrame::evaluate): Deleted.
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
        * inspector/JavaScriptCallFrame.h:
        (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
        (Inspector::JavaScriptCallFrame::evaluate): Deleted.
        Pass through to DebuggerCallFrame with the proper arguments.

        * debugger/Debugger.cpp:
        (JSC::Debugger::hasBreakpoint):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction):
        Use the new evaluate on call frame method name and no scope extension object.

2016-05-10  Saam barati  <sbarati@apple.com>

        Make super-property-access.js test run for less time because it was timing out in debug builds.

        Rubber stamped by Filip Pizlo.

        * tests/stress/super-property-access.js:
        (test):
        (test.value):
        (test.foo):
        (test.B.prototype.bar):
        (test.B):

2016-05-10  Csaba Osztrogonác  <ossy@webkit.org>

        [JSC] Fix the !ENABLE(DFG_JIT) build
        https://bugs.webkit.org/show_bug.cgi?id=157512

        Reviewed by Mark Lam.

        * jit/Repatch.cpp:

2016-05-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CRASH under JSC::DebuggerCallFrame::thisValue when hitting breakpoint
        https://bugs.webkit.org/show_bug.cgi?id=157442
        <rdar://problem/24172015>

        Reviewed by Saam Barati.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::thisValueForCallFrame):
        When the thisValue is JSValue() return undefined and avoid calling
        toThisValue which would lead to a crash. Having `this` be an empty
        JSValue could happen inside an ES6 class constructor, before
        calling super.

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

        Unreviewed, fix cloop.

        * bytecode/ValueProfile.cpp:
        (JSC::ResultProfile::emitDetectNumericness):
        (JSC::ResultProfile::emitSetNonNumber):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::addressOfFlags):
        (JSC::ResultProfile::addressOfSpecialFastPathCount):
        (JSC::ResultProfile::detectNumericness):
        (JSC::ResultProfile::hasBits):

2016-05-09  Michael Saboff  <msaboff@apple.com>

        Crash beneath ObjCCallbackFunctionImpl::call
        https://bugs.webkit.org/show_bug.cgi?id=157491

        Reviewed by Saam Barati.

        Clear any exceptions after the micro task runs.

        Tried creating a test case, but I don't have source for the app.
        I can't seem to find the right combination of Promises and ObjC code.

        * runtime/JSJob.cpp:
        (JSC::JSJobMicrotask::run):

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

        Polymorphic operands in operators coerces downstream values to double.
        https://bugs.webkit.org/show_bug.cgi?id=151793

        Reviewed by Mark Lam.
        
        Previously if an object flowed into arithmetic, the prediction propagation phase would either
        assume that the output of the arithmetic had to be double or sometimes it would assume that it
        couldn't be double. We want it to only assume that the output is double if it actually had been.
        
        The first part of this patch is to roll out http://trac.webkit.org/changeset/200502. That removed
        some of the machinery that we had in place to detect whether the output of an operation is int or
        double. That changeset claimed that the machinery was "fundamentally broken". It actually wasn't.
        The reason why it didn't work was that ByteCodeParser was ignoring it if likelyToTakeSlowCase was
        false. I think this was a complete goof-up: the code in ByteCodeParser::makeSafe was structured
        in a way that made it non-obvious that the method is a no-op if !likelyToTakeSlowCase. So, this
        change rolls out r200502 and makes ResultProfile do its job by reshaping how makeSafe processes
        it.
        
        This also makes two other changes to shore up ResultProfile:
        - OSR exit can now refine a ResultProfile the same way that it refines ValueProfile.
        - Baseline JIT slow paths now set bits in ResultProfile.
        
        Based on this stuff, the DFG now predicts int/double/string in op_add/op_sub/op_mul based on
        ResultProfiles. To be conservative, we still only use the ResultProfiles if the incoming
        prediction is not number-or-boolean. This ensures that we exactly retain our old behavior in
        those cases for which it was tuned. But I hope to remove this soon. I believe that ResultProfile
        is already strictly better than what prediction propagation was doing before.
        
        This can be an enormous win. This patch adds some simple microbenchmarks that demonstrate the
        problem of assuming that arithmetic on objects returns double. The most extreme of these speeds
        up 8x with this change (object-int-add-array).
        
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addFrequentExitSite):
        (JSC::CodeBlock::hasExitSite):
        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::FrequentExitSite::dump):
        (JSC::DFG::ExitProfile::ExitProfile):
        (JSC::DFG::ExitProfile::~ExitProfile):
        (JSC::DFG::ExitProfile::add):
        * bytecode/DFGExitProfile.h:
        (JSC::DFG::FrequentExitSite::isHashTableDeletedValue):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::fromLazyOperand):
        (JSC::MethodOfGettingAValueProfile::emitReportValue):
        (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): Deleted.
        * bytecode/MethodOfGettingAValueProfile.h:
        (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
        (JSC::MethodOfGettingAValueProfile::operator bool):
        (JSC::MethodOfGettingAValueProfile::operator!): Deleted.
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/ValueProfile.cpp:
        (JSC::ResultProfile::emitDetectBitsLight):
        (JSC::ResultProfile::emitSetDouble):
        (JSC::ResultProfile::emitSetNonNumber):
        (WTF::printInternal):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::ResultProfile):
        (JSC::ResultProfile::bytecodeOffset):
        (JSC::ResultProfile::specialFastPathCount):
        (JSC::ResultProfile::didObserveNonInt32):
        (JSC::ResultProfile::didObserveDouble):
        (JSC::ResultProfile::didObserveNonNegZeroDouble):
        (JSC::ResultProfile::didObserveNegZeroDouble):
        (JSC::ResultProfile::didObserveNonNumber):
        (JSC::ResultProfile::didObserveInt32Overflow):
        (JSC::ResultProfile::didObserveInt52Overflow):
        (JSC::ResultProfile::setObservedNonNegZeroDouble):
        (JSC::ResultProfile::setObservedNegZeroDouble):
        (JSC::ResultProfile::setObservedNonNumber):
        (JSC::ResultProfile::setObservedInt32Overflow):
        (JSC::ResultProfile::addressOfFlags):
        (JSC::ResultProfile::addressOfSpecialFastPathCount):
        (JSC::ResultProfile::detectBitsLight):
        (JSC::ResultProfile::hasBits):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::ensureNaturalLoops):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        (JSC::DFG::Graph::valueProfileFor): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasExitSite):
        (JSC::DFG::Graph::numBlocks):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        (JSC::DFG::Node::mayHaveNonIntResult):
        (JSC::DFG::Node::mayHaveDoubleResult):
        (JSC::DFG::Node::mayHaveNonNumberResult):
        (JSC::DFG::Node::hasConstantBuffer):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfEqual):
        (JSC::AssemblyHelpers::branchIfNotCell):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32):
        (JSC::AssemblyHelpers::branchIfBoolean):
        (JSC::AssemblyHelpers::branchIfEmpty):
        (JSC::AssemblyHelpers::branchStructure):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::CCallHelpers):
        (JSC::CCallHelpers::setupArguments):
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/IntrinsicEmitter.cpp:
        (JSC::AccessCase::emitIntrinsicGetter):
        * jit/JIT.h:
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        (JSC::JIT::callOperationNoExceptionCheck):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        * jit/TagRegistersMode.cpp: Added.
        (WTF::printInternal):
        * jit/TagRegistersMode.h: Added.
        * runtime/CommonSlowPaths.cpp:
        (JSC::updateResultProfileForBinaryArithOp):

2016-05-09  Keith Miller  <keith_miller@apple.com>

        CallObjectConstructor should not call operationToThis in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=157492
        <rdar://problem/26149904>

        Reviewed by Mark Lam.

        At some point when I was working on intrinsifying the Object
        constructor, I realized that the Object constructor was different
        from the ToObject operation. I fixed the DFG but I guess I didn't
        fix the FTL.

        This patch fixes an issue with www.wunderground.com not loading
        the 10-day forecast and local map.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
        * tests/stress/call-object-constructor.js: Added.
        (test):
        (assert):

2016-05-09  Saam barati  <sbarati@apple.com>

        Getter and setter on super are called with wrong "this" object
        https://bugs.webkit.org/show_bug.cgi?id=147064
        <rdar://problem/21885916>

        Reviewed by Filip Pizlo.

        This patch implements calls to 'super' getters and setters.
        The problem before is we were passing the 'super' (i.e, the prototype
        object) as the this value to these getters/setters, which is wrong. 
        We should be passing the caller's this value.

        To implement this behavior, I've introduced four new opcodes and their corresponding DFG nodes:
        - op_get_by_id_with_this | GetByIdWithThis
        - op_put_by_id_with_this | PutByIdWithThis
        - op_get_by_val_with_this | GetByValWithThis
        - op_put_by_val_with_this | PutByValWithThis

        These are implemented with no optimizations. The future plan is 
        to unite them with the *by_id and *by_val opcodes and nodes:
        https://bugs.webkit.org/show_bug.cgi?id=157215

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitPutByVal):
        (JSC::BytecodeGenerator::emitDirectPutByVal):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::ensureThis):
        (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::emitHomeObjectForCallee):
        (JSC::emitSuperBaseForCallee):
        (JSC::emitGetSuperFunctionForConstruct):
        (JSC::SuperNode::emitBytecode):
        (JSC::NewTargetNode::emitBytecode):
        (JSC::TaggedTemplateNode::emitBytecode):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::PostfixNode::emitBracket):
        (JSC::PostfixNode::emitDot):
        (JSC::PrefixNode::emitBracket):
        (JSC::PrefixNode::emitDot):
        (JSC::AssignDotNode::emitBytecode):
        (JSC::ReadModifyDotNode::emitBytecode):
        (JSC::AssignBracketNode::emitBytecode):
        (JSC::ReadModifyBracketNode::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::AssignmentElementNode::bindValue):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        (JSC::DFG::putWithThis):
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::setupShadowChickenPacket):
        (JSC::CCallHelpers::setupFourStubArgsGPR):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        (JSC::CCallHelpers::setupThreeStubArgsGPR):
        (JSC::CCallHelpers::setupTwoStubArgsFPR):
        (JSC::CCallHelpers::setupStubArguments134):
        * jit/GPRInfo.h:
        (JSC::argumentRegisterFor): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emit_op_put_by_val_with_this):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emit_op_get_by_val_with_this):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emit_op_put_by_id_with_this):
        (JSC::JIT::emitSlow_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emit_op_get_by_val_with_this):
        (JSC::JIT::emit_op_put_by_id_with_this):
        (JSC::JIT::emit_op_put_by_val_with_this):
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/stress/super-property-access-exceptions.js: Added.
        (assert):
        (test):
        (test.fooProp):
        (test.A.prototype.get foo):
        (test.A.prototype.get x):
        (test.A):
        (test.B):
        (test.B.prototype.bar):
        (test.B.prototype.baz):
        (test.foo):
        (test.func):
        (test.A.prototype.set foo):
        * tests/stress/super-property-access-tdz.js: Added.
        (assert):
        (test):
        (shouldThrowTDZ):
        (test.A.prototype.get foo):
        (test.A.prototype.set foo):
        (test.A):
        (test.fooProp):
        (test.B):
        (test.C):
        (test.D):
        (test.E):
        (test.F):
        * tests/stress/super-property-access.js: Added.
        (assert):
        (test):
        (func):
        (test.A):
        (test.A.prototype.set value):
        (test.A.prototype.get value):
        (test.B.prototype.set value):
        (test.B.prototype.get value):
        (test.B):
        (test.value):
        (test.A.prototype.get func):
        (test.B.prototype.inc):
        (test.B.prototype.dec):
        (test.B.prototype.preInc):
        (test.B.prototype.preDec):
        (test.B.prototype.plusEq):
        (test.B.prototype.minusEq):
        (test.B.prototype.timesEq):
        (test.B.prototype.divEq):
        (test.B.prototype.funcDot):
        (test.B.prototype.funcBracket):
        (test.foo):
        (test.B.prototype.baz):
        (test.B.prototype.jaz):
        (test.B.prototype.bar):
        (test.B.prototype.index):
        (test.):
        (test.prototype.bar):
        (test.A.prototype.set foo):
        (test.A.prototype.get array):
        (test.A.prototype.get foo):
        (test.obj):
        (test.A.prototype.get call):
        (test.A.prototype.get apply):
        (test.B.prototype.foo):
        (test.A.prototype.get i):

2016-05-08  Chris Dumez  <cdumez@apple.com>

        [COCOA] Disable HAVE_DTRACE at build time
        https://bugs.webkit.org/show_bug.cgi?id=157433
        <rdar://problem/26148841>

        Reviewed by Mark Lam.

        Drop DTRACE-related code from JSC since it is very old and seems
        unused.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformMac.cmake:
        * heap/Heap.cpp:
        (JSC::Heap::collectImpl): Deleted.
        (JSC::Heap::didFinishCollection): Deleted.
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::willExecute): Deleted.
        (JSC::ProfileGenerator::didExecute): Deleted.
        * runtime/Tracing.d: Removed.
        * runtime/Tracing.h: Removed.

2016-05-07  Mark Lam  <mark.lam@apple.com>

        Add JSC options bytecodeRangeToJITCompile and jitWhitelist.
        https://bugs.webkit.org/show_bug.cgi?id=157428

        Reviewed by Michael Saboff.

        1. Added Options::bytecodeRangeToJITCompile and Options::jitWhitelist options.

        2. Moved DFGFunctionWhitelist* to FunctionWhitelist* and made it generic so that
           it can be used for more than one whitelist instance.  In this case, we now have
           two: the dfgWhitelist and the jitWhitelist.

        3. Added "can compile" checks in LLInt::shouldJIT() to check
           Options::bytecodeRangeToJITCompile and Options::jitWhitelist.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::getNumCompilations):
        (JSC::DFG::ensureGlobalDFGWhitelist):
        (JSC::DFG::compileImpl):
        * dfg/DFGFunctionWhitelist.cpp: Removed.
        * dfg/DFGFunctionWhitelist.h: Removed.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::ensureGlobalJITWhitelist):
        (JSC::LLInt::shouldJIT):

        * runtime/Options.h:

        * tools/FunctionWhitelist.cpp: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.cpp.
        (JSC::FunctionWhitelist::FunctionWhitelist):
        (JSC::FunctionWhitelist::contains):
        (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist): Deleted.
        (JSC::DFG::FunctionWhitelist::FunctionWhitelist): Deleted.
        (JSC::DFG::FunctionWhitelist::parseFunctionNamesInFile): Deleted.
        (JSC::DFG::FunctionWhitelist::contains): Deleted.
        * tools/FunctionWhitelist.h: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.h.

2016-05-07  Benjamin Poulain  <bpoulain@apple.com>

        [JSC][32bit] stress/tagged-templates-template-object.js fails in debug
        https://bugs.webkit.org/show_bug.cgi?id=157436

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        The node OverridesHasInstance had a speculation after a jump.

2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Misc CommandLineAPI cleanup
        https://bugs.webkit.org/show_bug.cgi?id=157450

        Reviewed by Ryosuke Niwa.

        * inspector/InjectedScriptSource.js:
        (BasicCommandLineAPI):
        Fix mistake in r200533, and modernize related code.

2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve console.count()
        https://bugs.webkit.org/show_bug.cgi?id=157439
        <rdar://problem/26152654>

        Reviewed by Timothy Hatcher.

          - make console.count() increment an unnamed global counter.
          - make console.count(label) increment a counter with that label name.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::count):

2016-05-06  Simon Fraser  <simon.fraser@apple.com>

        Enable IOS_TEXT_AUTOSIZING on Mac and make it testable
        https://bugs.webkit.org/show_bug.cgi?id=157432
        rdar://problem/16406720

        Reviewed by Dean Jackson.

        Enable IOS_TEXT_AUTOSIZING on Mac so it can be tested.

        * Configurations/FeatureDefines.xcconfig:

2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Console: Variables defined with let/const aren't accessible outside of console's scope
        https://bugs.webkit.org/show_bug.cgi?id=150752
        <rdar://problem/23343385>

        Reviewed by Mark Lam.

        This approach allows Web Inspector to hang a "Scope Extension", a
        WithObjectScope, off the GlobalObject. When resolving identifiers
        in fails to resolve anything in the normal scope chain, consult
        the scope extension.

        This allows us to eliminate the `with (commandLineAPI) { ... }`
        block in global console evaluations, and instead makes it a full
        program evaluation, with the commandLineAPI available and safely
        shadowed by actual variables as expected.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._evaluateOn):
        Use the new evaluateWithScopeExtension and provide the CommandLineAPI
        object as the scope extension object.

        (BasicCommandLineAPI):
        (BasicCommandLineAPI.inScopeVariables): Deleted.
        Simplify now that we don't need to check for variable shadowing ourselves.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
        Provide a new InjectedScriptHost method to evaluate a program
        with a scope extension.

        * runtime/Completion.cpp:
        (JSC::evaluateWithScopeExtension):
        * runtime/Completion.h:
        General JSC::evaluate function to evaluate a program with a scope extension.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setGlobalScopeExtension):
        (JSC::JSGlobalObject::clearGlobalScopeExtension):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::globalScopeExtension):
        Hang a scope extension off the global object.

        * runtime/JSScope.cpp:
        (JSC::JSScope::resolve):
        Consult the scope extension when resolve fails to find anything normally.

2016-05-06  Mark Lam  <mark.lam@apple.com>

        Add JSC options reportBaselineCompileTimes and reportDFGCompileTimes.
        https://bugs.webkit.org/show_bug.cgi?id=157427

        Reviewed by Filip Pizlo and Keith Miller.

        The compile times reporting options are now:
            reportCompileTimes         -> report compile times in all tiers.
            reportBaselineCompileTimes -> report compile times in baseline JIT.
            reportDFGCompileTimes      -> report compile times in DFG and FTL.
            reportFTLCompileTimes      -> report compile times in FTL.

        Also updated reportTotalCompileTimes() to collect stats that include the baseline
        JIT.  compileTimeStats() is now moved into JIT.cpp (from DFGPlan.cpp). 

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::reportCompileTimes):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::cancel):
        (JSC::DFG::Plan::compileTimeStats): Deleted.
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::compileTimeStats): Deleted.
        * jit/JIT.cpp:
        (JSC::ctiPatchCallByReturnAddress):
        (JSC::JIT::privateCompile):
        (JSC::JIT::stackPointerOffsetFor):
        (JSC::JIT::reportCompileTimes):
        (JSC::JIT::computeCompileTimes):
        (JSC::JIT::compileTimeStats):
        * jit/JIT.h:
        (JSC::JIT::shouldEmitProfiling):
        * jsc.cpp:
        (runJSC):
        * runtime/Options.h:

2016-05-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Get rid of NonNegZeroDouble, it is broken
        https://bugs.webkit.org/show_bug.cgi?id=157399
        rdar://problem/25339647

        Reviewed by Mark Lam.

        The profile "NonNegZeroDouble" is fundamentally broken.

        It is used by DFG to predict the result of ArithMul as being a Double
        or Int32.
        The problem is you are likely to mispredict, and when you do, you are
        guaranteed to end up in a recompile loop.

        The compile loops usually happen like this:
        -We speculate you have Int32 despite producing doubles.
        -We OSR exit on another node (ValueToInt32 for example) from the result of this ArithMul.
        -When we compile this block again, ArithMul will do the same misprediction
         because it unconditionally predicts Int32.

        The flag NonNegZeroDouble was very unlikely to be set correctly
        in the first place.

        In LLINT, the flag is only set on the slow path.
        Since double*double is on the fast path, those cases are ignored.

        In Baseline, the flag is set for any case that falls back on double
        multiplication. BUT, the DFG flag was only set for nodes that spend
        many iteration in slow path, which obviously does not apply to double*double.

        Given the perf drawbacks and the recompile loops, I removed
        the whole flag for now.

        * bytecode/ValueProfile.cpp:
        (WTF::printInternal):
        * bytecode/ValueProfile.h:
        (JSC::ResultProfile::didObserveNonInt32): Deleted.
        (JSC::ResultProfile::didObserveDouble): Deleted.
        (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
        (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::mayHaveNonIntResult): Deleted.
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags): Deleted.
        * dfg/DFGNodeFlags.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath): Deleted.
        * runtime/CommonSlowPaths.cpp:
        (JSC::updateResultProfileForBinaryArithOp): Deleted.

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r200422): Web Inspector: Make new Array Iterator objects play nice with Web Inspector
        https://bugs.webkit.org/show_bug.cgi?id=157361
        <rdar://problem/26099793>

        Reviewed by Timothy Hatcher.

        * builtins/ArrayPrototype.js:
        (createArrayIterator):
        (values):
        (keys):
        (entries):
        * builtins/TypedArrayPrototype.js:
        (values):
        (keys):
        (entries):
        * runtime/CommonIdentifiers.h:
        Set the kind on the iterator object, that can be shown
        to the inspector if the object is shown in the console.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._describe):
        Get a better name for the new Array Iterator which is just an Object.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Detect and handle ArrayIterator object instances. Porting the code
        from the JSArrayIterator code path.

2016-05-05  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] In DFG, an OSR Exit on SetLocal can trash its child node
        https://bugs.webkit.org/show_bug.cgi?id=157358
        rdar://problem/25339647

        Reviewed by Filip Pizlo.

        When we OSR Exit on SetLocal, the child is never restored if its representation
        was changed since the MovHint.

        For example, say we have:
            @1 = SomethingProducingDouble()
            @2 = MovHint(@1)
            @3 = ValueRep(@1)
            @4 = SetLocal(@3, FlushedInt32)

        When we lower SetLocal(), we start by speculating that @3 is an Int32.
        Now this can fail if @1 was really a double.
        When that happens, we go over the VariableEventStream to find where values
        are, and @1 died at @3. Since the speculation failure happens before
        the SetLocal event, we don't do anything with @3.

        In this patch, I extend the PhantomInsertion phase to keep the MovHint
        alive past the SetLocal.

        * dfg/DFGPhantomInsertionPhase.cpp:
        * tests/stress/multiply-typed-double-and-object.js: Added.
        (otherObject.valueOf):
        (targetDFG.multiply):
        (targetFTL.multiply):

2016-05-05  Oliver Hunt  <oliver@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720

        Reviewed by Geoffrey Garen.

        We've fixed the xnu side of things, so we can reland this.

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

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Better CommandLineAPI in JSContext inspection
        https://bugs.webkit.org/show_bug.cgi?id=157387
        <rdar://problem/22630583>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._evaluateOn):
        (BasicCommandLineAPI.inScopeVariables):
        (BasicCommandLineAPI):
        When creating a BasicCommandLineAPI, pass the call frame so
        that we don't shadow variables in the callstack.

        (BasicCommandLineAPI.methods):
        (clear):
        (table):
        (profile):
        (profileEnd):
        (keys):
        (values):
        Some just pass through to console, others are tiny methods.
        Implement them, and give them the expected toString string.

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

        Reduce maximum JIT pool size on X86_64.

        Rubber stamped by Geoffrey Garen.
        
        This changes our maximum pool size to 100MB. The problem with letting a page allocate much
        more than this is that we will sometimes call deleteAllCode() or one of its friends. Deleting
        a huge amount of memory is expensive in our allocator.
        
        So long as we allow for such large-scale code death to happen, and so long as it's expensive,
        we should bound the amount of code we end up with in the first place.
        
        In the long run, we should fix our executable allocator so that it's not so expensive to kill
        all code.
        
        * jit/ExecutableAllocator.h:

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

        Reduce thresholds that control the maximum IC stub size.

        Rubber stamped by Chris Dumez and Benjamin Poulain.
        
        This reduces the thresholds to before the megamorphic load optimizations to see if that
        recovers a PLT regression.

        * runtime/Options.h:

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

        We shouldn't crash if DFG AI proved that something was unreachable on one run but then decided not to prove it on another run
        https://bugs.webkit.org/show_bug.cgi?id=157379

        Reviewed by Mark Lam.
        
        Any run of DFG AI is a fixpoint that loosens the proof until it can't find any more
        counterexamples to the proof.  It errs on the side of loosening proofs, i.e., on the side of
        proving fewer things.

        We run this fixpoint multiple times since there are multiple points in the DFG optimization
        pipeline when we run DFG AI.  Each of those runs completes a fixpoint and produces the
        tightest proof it can that did not result in counterexamples being found.

        It's possible that on run K of DFG AI, we prove some property, but on run K+1, we don't prove
        that property. The code could have changed between the two runs due to other phases. Other
        phases may modify the code in such a way that it's less amenable to AI's analysis. Our design
        allows this because DFG AI is not 100% precise. It defends itself from making unsound choices
        or running forever by sometimes punting on proving some property. It must be able to do this,
        and so therefore, it might sometimes prove fewer things on a later run.

        Currently in trunk if the property that AI proves on run K but fails to prove on run K+1 is
        the reachability of a piece of code, then run K+1 will crash on an assertion at the
        Unreachable node. It will complain that it reached an Unreachable. But it might be reaching
        that Unreachable because it failed to prove that something earlier was always exiting. That's
        OK, see above.

        So, we should remove the assertion that AI doesn't see Unreachable.
        
        No new tests because I don't know how to make this happen. I believe that this happens in the
        wild based on crash logs.

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

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        Crash if you type "debugger" in the console and continue
        https://bugs.webkit.org/show_bug.cgi?id=156924
        <rdar://problem/25884189>

        Reviewed by Mark Lam.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
        Bail with an error when we are not paused.

        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
        (Inspector::InspectorRuntimeAgent::getCollectionEntries):
        (Inspector::InspectorRuntimeAgent::saveResult):
        Update poor error message.

2016-05-05  Keith Miller  <keith_miller@apple.com>

        Add support for delete by value to the DFG
        https://bugs.webkit.org/show_bug.cgi?id=157372

        Reviewed by Filip Pizlo.

        This patch adds basic support for delete by value to the DFG. delete by value
        just calls out to a C++ operation on each execution. Additionally, this patch
        fixes an issue with delete by id where we would crash if the base was null
        or undefined.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDeleteById):
        (JSC::DFG::SpeculativeJIT::compileDeleteByVal):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_del_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_del_by_val):
        * tests/stress/delete-by-val.js: Added.
        (assert):
        (test):
        * tests/stress/delete-to-object-exception.js: Added.
        (assert):
        (test):

2016-05-05  Michael Saboff  <msaboff@apple.com>

        Unreviewed build fix after change set r200447.

        Made the detection of clang version XCode build specific.
        Now shouldEnableDebugAnnotations() should return false for all other build types.

        * offlineasm/config.rb:

2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>

        Create console object lazily
        https://bugs.webkit.org/show_bug.cgi?id=157328

        Reviewed by Geoffrey Garen.

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):
        (JSC::JSGlobalObject::init): Deleted.

2016-05-04  Michael Saboff  <msaboff@apple.com>

        Enable Dwarf2 debug information in offline assembler for clang compiler
        https://bugs.webkit.org/show_bug.cgi?id=157364.

        Reviewed by Mark Lam.

        Added a new function shouldEnableDebugAnnotations() that determines if
        we are using clang and a new enough version to support the debug annotations.

        * offlineasm/config.rb:
        (shouldEnableDebugAnnotations): Added.

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix test for new ArrayIteratorPrototype.next() error message.

        * tests/stress/array-iterators-next-with-call.js:

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

        Speed up JSGlobalObject initialization by making some properties lazy
        https://bugs.webkit.org/show_bug.cgi?id=157045

        Reviewed by Keith Miller.
        
        This makes about half of JSGlobalObject's state lazy. There are three categories of
        state in JSGlobalObject:
        
        1) C++ fields in JSGlobalObject.
        2) JS object properties in JSGlobalObject's JSObject superclass.
        3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
        
        State held in JS variables cannot yet be made lazy. That's why this patch only goes
        half-way.
        
        State in JS object properties can be made lazy if we move it to the static property
        hashtable. JSGlobalObject already had one of those. This patch makes static property
        hashtables a lot more powerful, by adding three new kinds of static properties. These
        new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
        
        State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
        lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
        JSGlobalObject and we are adding more all the time. We don't want to require that each
        of these has a getter with an initialization check and a corresponding out-of-line slow
        path that does the initialization. We want this kind of boilerplate to be handled by
        some abstractions.
        
        The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
        only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
        You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
        so it's almost a drop-in replacement.
        
        The key to LazyProperty<Type>'s power is that you can do this:
        
            class Bar {
                ...
                LazyProperty<Foo> m_foo;
            };
            ...
            m_foo.initLater(
                [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
                    init.set(Foo::create(init.vm, init.owner));
                });
        
        This initLater() call requires that you pass a stateless lambda (see WTF changelog for
        the definition). Miraculously, this initLater() call is guaranteed to compile to a store
        of a pointer constant to m_foo, as in:
        
            movabsq 0xBLAH, %rax
            movq %rax, &m_foo
        
        This magical pointer constant points to a callback that was generated by the template
        instantiation of initLater(). That callback knows to call your stateless lambda, but
        also does some other bookkeeping: it makes sure that you indeed initialized the property
        inside the callback and it manages recursive initializations. It's totally legal to call
        m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
        m_foo.get() will return null. This is an excellent escape hatch if we ever find
        ourselves in a dependency cycle. I added this feature because I already had to create a
        dependency cycle.
        
        Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
        to get this right. The DFG thread cannot initialize those fields, so it has to make sure
        that it does conservative things. But for some nodes this could mean adding a lot of new
        logic, like NewTypedArray, which currently is written in such a way that it assumes that
        we always have the typed array structure. Currently we take a two-fold approach: for
        typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
        initialized, and for everything else we don't make the properties lazy if the DFG needs
        them. As we optimize this further we might need to teach the DFG to handle more lazy
        properties. I tried to do this for RegExp but found it to be very confusing. With typed
        arrays I got lucky.
        
        There is also a somewhat more powerful construct called LazyClassStructure. We often
        need to keep around the structure of some standard JS class, like Date. We also need to
        make sure that the constructor ends up in the global object's property table. And we
        often need to keep the original value of the constructor for ourselves. In this case, we
        want to make sure that the creation of the structure-prototype-constructor constellation
        is atomic. We don't want code to start looking at the structure if it points to a
        prototype that doesn't have its "constructor" property set yet, for example.
        LazyClassStructure solves this by abstracting that whole initialization. You provide the
        callback that allocates everything, since we are super inconsistent about the way we
        initialize things, but LazyClassStructure establishes the workflow and helps you not
        mess up.
        
        Finally, the new static hashtable attributes allow for all of this to work with the JS
        property table:
        
        PropertyCallback: if you use this attribute, the second column in the table should be
        the name of a function to call to initialize this property. This is useful for things
        like the Math property. The Math object turns out to be very expensive to allocate.
        Delaying its allocation is super easy with the PropertyCallback attribute.
        
        CellProperty: with this attribute the second column should be a C++ field name like
        JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
        this property, and when it needs to be initialized, Lookup will assume you have a
        LazyProperty<JSCell> and call its get() method. It will initialize the property to
        whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
        LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
        call whatever callback function pointer is encoded in the property and it does not need
        to know anything about what type that callback will instantiate.
        
        ClassStructure: with this attribute the second column should be a C++ field name. The
        static hashtable will initialize the property by treating the field as a
        LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
        initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
        the property in question will already be set. By convention, we have LazyClassStructure
        initialize the property with a pointer to the constructor, since that's how all of our
        classes work: "globalObject.Date" points to the DateConstructor.
        
        This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
        calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
        
        Rolling this back in after fixing the function pointer alignment issue. The last version
        relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this,
        especially since ARMv7 uses the low bit of function pointers as a tag to indicate the
        instruction set. This version adds an extra indirection, so that
        LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to
        a pointer is guaranteed to be at least 4-byte aligned.

        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::create):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::impl):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * create_hash_table:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::create):
        (JSC::DebuggerScope::DebuggerScope):
        * debugger/DebuggerScope.h:
        (JSC::DebuggerScope::jsScope):
        (JSC::DebuggerScope::create): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::originalArrayStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::visitChildren):
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::calculatedDisplayName):
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSBoundSlotBaseFunction.cpp:
        (JSC::JSBoundSlotBaseFunction::create):
        * runtime/JSFunction.cpp:
        (JSC::retrieveCallerFunction):
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGlobalObject.cpp:
        (JSC::createProxyProperty):
        (JSC::createJSONProperty):
        (JSC::createMathProperty):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::toThis):
        (JSC::JSGlobalObject::getOwnPropertySlot):
        (JSC::JSGlobalObject::createThrowTypeError): Deleted.
        (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectConstructor):
        (JSC::JSGlobalObject::promiseConstructor):
        (JSC::JSGlobalObject::internalPromiseConstructor):
        (JSC::JSGlobalObject::evalErrorConstructor):
        (JSC::JSGlobalObject::rangeErrorConstructor):
        (JSC::JSGlobalObject::referenceErrorConstructor):
        (JSC::JSGlobalObject::syntaxErrorConstructor):
        (JSC::JSGlobalObject::typeErrorConstructor):
        (JSC::JSGlobalObject::URIErrorConstructor):
        (JSC::JSGlobalObject::nullGetterFunction):
        (JSC::JSGlobalObject::nullSetterFunction):
        (JSC::JSGlobalObject::callFunction):
        (JSC::JSGlobalObject::applyFunction):
        (JSC::JSGlobalObject::definePropertyFunction):
        (JSC::JSGlobalObject::arrayProtoValuesFunction):
        (JSC::JSGlobalObject::initializePromiseFunction):
        (JSC::JSGlobalObject::newPromiseCapabilityFunction):
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        (JSC::JSGlobalObject::regExpProtoExecFunction):
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::objectPrototype):
        (JSC::JSGlobalObject::functionPrototype):
        (JSC::JSGlobalObject::arrayPrototype):
        (JSC::JSGlobalObject::booleanPrototype):
        (JSC::JSGlobalObject::stringPrototype):
        (JSC::JSGlobalObject::symbolPrototype):
        (JSC::JSGlobalObject::numberPrototype):
        (JSC::JSGlobalObject::datePrototype):
        (JSC::JSGlobalObject::regExpPrototype):
        (JSC::JSGlobalObject::errorPrototype):
        (JSC::JSGlobalObject::iteratorPrototype):
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::debuggerScopeStructure):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::moduleEnvironmentStructure):
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::clonedArgumentsStructure):
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        (JSC::JSGlobalObject::booleanObjectStructure):
        (JSC::JSGlobalObject::callbackConstructorStructure):
        (JSC::JSGlobalObject::callbackFunctionStructure):
        (JSC::JSGlobalObject::callbackObjectStructure):
        (JSC::JSGlobalObject::propertyNameIteratorStructure):
        (JSC::JSGlobalObject::objcCallbackFunctionStructure):
        (JSC::JSGlobalObject::objcWrapperObjectStructure):
        (JSC::JSGlobalObject::dateStructure):
        (JSC::JSGlobalObject::nullPrototypeObjectStructure):
        (JSC::JSGlobalObject::errorStructure):
        (JSC::JSGlobalObject::calleeStructure):
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        (JSC::JSGlobalObject::numberObjectStructure):
        (JSC::JSGlobalObject::privateNameStructure):
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpStructure):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        (JSC::JSGlobalObject::setStructure):
        (JSC::JSGlobalObject::stringObjectStructure):
        (JSC::JSGlobalObject::symbolObjectStructure):
        (JSC::JSGlobalObject::iteratorResultObjectStructure):
        (JSC::JSGlobalObject::lazyTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructureConcurrently):
        (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayConstructor):
        (JSC::JSGlobalObject::actualPointerFor):
        (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::visitChildren):
        (JSC::JSWithScope::createStructure):
        (JSC::JSWithScope::JSWithScope):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::object):
        (JSC::JSWithScope::create): Deleted.
        (JSC::JSWithScope::createStructure): Deleted.
        (JSC::JSWithScope::JSWithScope): Deleted.
        * runtime/LazyClassStructure.cpp: Added.
        (JSC::LazyClassStructure::Initializer::Initializer):
        (JSC::LazyClassStructure::Initializer::setPrototype):
        (JSC::LazyClassStructure::Initializer::setStructure):
        (JSC::LazyClassStructure::Initializer::setConstructor):
        (JSC::LazyClassStructure::visit):
        (JSC::LazyClassStructure::dump):
        * runtime/LazyClassStructure.h: Added.
        (JSC::LazyClassStructure::LazyClassStructure):
        (JSC::LazyClassStructure::get):
        (JSC::LazyClassStructure::prototype):
        (JSC::LazyClassStructure::constructor):
        (JSC::LazyClassStructure::getConcurrently):
        (JSC::LazyClassStructure::prototypeConcurrently):
        (JSC::LazyClassStructure::constructorConcurrently):
        * runtime/LazyClassStructureInlines.h: Added.
        (JSC::LazyClassStructure::initLater):
        * runtime/LazyProperty.h: Added.
        (JSC::LazyProperty::Initializer::Initializer):
        (JSC::LazyProperty::LazyProperty):
        (JSC::LazyProperty::get):
        (JSC::LazyProperty::getConcurrently):
        * runtime/LazyPropertyInlines.h: Added.
        (JSC::ElementType>::Initializer::set):
        (JSC::ElementType>::initLater):
        (JSC::ElementType>::setMayBeNull):
        (JSC::ElementType>::set):
        (JSC::ElementType>::visit):
        (JSC::ElementType>::dump):
        (JSC::ElementType>::callFunc):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::function):
        (JSC::HashTableValue::functionLength):
        (JSC::HashTableValue::propertyGetter):
        (JSC::HashTableValue::propertyPutter):
        (JSC::HashTableValue::accessorGetter):
        (JSC::HashTableValue::accessorSetter):
        (JSC::HashTableValue::constantInteger):
        (JSC::HashTableValue::lexerValue):
        (JSC::HashTableValue::lazyCellPropertyOffset):
        (JSC::HashTableValue::lazyClassStructureOffset):
        (JSC::HashTableValue::lazyPropertyCallback):
        (JSC::getStaticPropertySlot):
        (JSC::getStaticValueSlot):
        (JSC::putEntry):
        (JSC::reifyStaticProperty):
        * runtime/PropertySlot.h:
        * runtime/TypedArrayType.h:

2016-05-04  Joseph Pecoraro  <pecoraro@apple.com>

        Improve the grammar of some error messages 'a argument list' => 'an argument list'
        https://bugs.webkit.org/show_bug.cgi?id=157350
        <rdar://problem/26082108>

        Reviewed by Mark Lam.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseIfStatement):
        (JSC::Parser<LexerType>::parseImportDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseObjectLiteral):
        (JSC::Parser<LexerType>::parseStrictObjectLiteral):
        (JSC::Parser<LexerType>::parseArguments):
        Use the alternate error message formatter macro which outputs 'an'
        instead of 'a' preceding the last argument.

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Corrections to r200422
        https://bugs.webkit.org/show_bug.cgi?id=157351

        Reviewed by Joseph Pecoraro.

        Fix some typos in various files. Also, make separate error messages
        for the this value being undefined vs null in the ArrayIteratorprototype
        next function and add test.

        * Scripts/builtins/builtins_model.py:
        * builtins/ArrayIteratorPrototype.js:
        (next):
        (arrayIteratorValueNext):
        (arrayIteratorKeyNext):
        (arrayIteratorKeyValueNext):
        * builtins/ArrayPrototype.js:
        (keys):
        (entries):
        * builtins/TypedArrayPrototype.js:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Deleted.
        * tests/stress/array-iterators-next-error-messages.js: Added.
        (assert):
        (catch):

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Unreviewed, reland r200149 since the rollout had inconclusive PLT AB testing results.

2016-05-04  Mark Lam  <mark.lam@apple.com>

        ES6 Function.name inferred from property names of literal objects can break some websites.
        https://bugs.webkit.org/show_bug.cgi?id=157246

        Reviewed by Geoffrey Garen.

        Specifically, the library mathjs (see http://mathjs.org and https://github.com/josdejong/mathjs)
        uses an idiom where it created literal objects with property names that look like
        this: 'number | BigNumber | Unit'.  Later, this name is used in a string to create
        function source code that gets eval'ed.  Since 'number | BigNumber | Unit' is not
        a valid function name, we get a syntax error.

        Here are the details:

        1. mathjs uses object literals with the funky property names for its function members.
           For example, 

              // helper function to type check the middle value of the array
              var middle = typed({
                'number | BigNumber | Unit': function (value) {
                  return value;
                }
              });

        2. mathjs' getName() uses Function.name to get the name of functions (hence, picks
           up the property name as inferred value of Function.name as specified by ES6):

                /**
                 * Retrieve the function name from a set of functions, and check
                 * whether the name of all functions match (if given)
                 ...
                 */
                function getName (fns) {
                  var name = '';

                  for (var i = 0; i < fns.length; i++) {
                    var fn = fns[i];
                    ...
                        name = fn.name;
                    ...
                  return name;
                }

        3. mathjs uses that name to assembler new function source code that gets eval'ed:

                /**
                 * Compose a function from sub-functions each handling a single type signature.
                 ...
                 */
                function _typed(name, signatures) {
                  ...
                  // generate code for the typed function
                  var code = [];
                  var _name = name || '';
                  ...
                  code.push('function ' + _name + '(' + _args.join(', ') + ') {');
                  code.push('  "use strict";');
                  code.push('  var name = \'' + _name + '\';');
                  code.push(node.toCode(refs, '  '));
                  code.push('}');

                  // generate body for the factory function
                  var body = [
                    refs.toCode(),
                    'return ' + code.join('\n')
                  ].join('\n');

                  // evaluate the JavaScript code and attach function references
                  var factory = (new Function(refs.name, 'createError', body));  // <== Syntax Error here!
                  var fn = factory(refs, createError);
                  ...
                  return fn;
                }

        Until mathjs (and any other frameworks that does similar things) and sites that
        uses mathjs has been updated to work with ES6, we'll need a compatibility hack to
        work around it.

        Here's what we'll do:
        1. Introduce a needsSiteSpecificQuirks flag in JSGlobalObject.
        2. Have WebCore's JSDOMWindowBase set that flag if the browser's
           needsSiteSpecificQuirks is enabled in its settings.
        3. If needsSiteSpecificQuirks is enabled, have JSFunction::reifyName() check for
           ' ' or '|' in the name string it will use to reify the Function.name property.
           If those characters exists in the name, we'll replace the name string with a
           null string.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::reifyName):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::needsSiteSpecificQuirks):
        (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
        (JSC::JSGlobalObject::setNeedsSiteSpecificQuirks):

2016-05-04  Keith Miller  <keith_miller@apple.com>

        Speedup array iterators
        https://bugs.webkit.org/show_bug.cgi?id=157315

        Reviewed by Michael Saboff.

        This patch improves the performance of Array iterators in ES6. There are two main changes
        that make things faster. The first is that the value, keys and entries functions have been
        moved to JS. This enables us to inline the construction of the iterator. Thus, when we get
        to the FTL we are able to sink the allocation of the iterator object. This significantly
        improves the performance of any for-of loop since we are now able to have both the iteration
        counter and the iterated object in local variables rather than in the heap.

        Secondly, instead of using a number to store the iteratation kind we now use a virtual
        method on the iteration object to indicate which next function to use. This ends up being
        helpful because it means we can eliminate the branches in the old next function that decide
        what value to return. With those branches gone the various next functions are now small
        enough to inline. Once the next functions are inlined then the FTL is able to sink the
        allocation of next() result object. There is still room for optimization in the loop since
        we currently don't recognize that the array access in the next function is in bounds or that
        the increment to the loop counter cannot overflow.

        The overall performance changes appear to be a ~4-6x speedup in a simple microbenchmark that
        computes the sum of an array with some extra arithmetic. The variance depends on the exact
        body of the loop. Additionally, on a new regress test that changes all the loops in
        deltablue into for-of loops this patch is a 1.8x progression. Overall, it still looks like
        for-of loops are significantly slower than an indexed for loop. In the first test it's ~2-4x
        slower with the difference depending on the body of the loop. If the loop is just the sum
        then we see a much larger regression than if the loop does even simple arithmetic. It looks
        like the indexed for loop without extra arithmetic is small enough to fit into the x86
        replay buffer on my machine, which would explain why there is such a big difference between
        the for of loop in that case. On the deltablue benchmark it's 1.4x slower. It's clear from
        these numbers that there is still a lot of work we can do to make for of loops faster.

        This patch also makes some changes to the way that we decorate our builtin js
        functions. Instead of the old syntax (putting the decorated values in [] before the function
        declaration i.e. [intrinsic=foo]) this patch changes the syntax to be closer to the way that
        decorators are proposed in a future ECMAScript proposal (using @ followed by the entry on a
        new line before the function declaration i.e. @intrinsic=foo).

        Finally, in the builtin scripts regular expressions re.S has been changed to re.DOTALL since
        DOTALL is easier to understand without going to the reference page for python regular
        expressions.

        * Scripts/builtins/builtins_model.py:
        * builtins/ArrayIteratorPrototype.js:
        (next):
        (arrayIteratorValueNext):
        (arrayIteratorKeyNext):
        (arrayIteratorKeyValueNext):
        * builtins/ArrayPrototype.js:
        (createArrayIterator):
        (values):
        (keys):
        (entries):
        * builtins/RegExpPrototype.js:
        (intrinsic.RegExpTestIntrinsic.test):
        * builtins/StringPrototype.js:
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        * builtins/TypedArrayPrototype.js:
        (values):
        (keys):
        (entries):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::cloneArrayIteratorObject):
        (Inspector::JSInjectedScriptHost::iteratorEntries):
        * jit/ThunkGenerators.cpp:
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncValues): Deleted.
        (JSC::arrayProtoFuncEntries): Deleted.
        (JSC::arrayProtoFuncKeys): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::clone): Deleted.
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncEntries): Deleted.
        (JSC::genericTypedArrayViewProtoFuncKeys): Deleted.
        (JSC::typedArrayViewProtoFuncValues): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::typedArrayViewProtoFuncEntries): Deleted.
        (JSC::typedArrayViewProtoFuncKeys): Deleted.
        (JSC::typedArrayViewProtoFuncValues): Deleted.
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):

2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Object constructor need to be aware of new.target
        https://bugs.webkit.org/show_bug.cgi?id=157196

        Reviewed by Darin Adler.

        Object constructor should be aware of new.target.
        When the new.target is specified, we should store it.prototype to the newly created
        object's [[Prototype]].

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        Take the design that caches the structure used for empty object.
        This structure is also used in constructEmptyObject frequently.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectStructureForObjectConstructor):
        * runtime/ObjectConstructor.cpp:
        (JSC::constructObject):
        (JSC::constructWithObjectConstructor):
        (JSC::callObjectConstructor):
        * runtime/ObjectConstructor.h:
        (JSC::constructEmptyObject):
        Construct the object by using the plain structure that is also used in the ObjectConstructor.

        * tests/stress/object-constructor-should-be-new-target-aware.js: Added.
        (shouldBe):
        (Hello):

2016-05-04  Chris Dumez  <cdumez@apple.com>

        Unreviewed, rolling out r200383 and r200406.

        Seems to have caused crashes on iOS / ARMv7s

        Reverted changesets:

        "Speed up JSGlobalObject initialization by making some
        properties lazy"
        https://bugs.webkit.org/show_bug.cgi?id=157045
        http://trac.webkit.org/changeset/200383

        "REGRESSION(r200383): Setting lazily initialized properties
        across frame boundaries crashes"
        https://bugs.webkit.org/show_bug.cgi?id=157333
        http://trac.webkit.org/changeset/200406

2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        Assertion failure for super() call in direct eval in method function
        https://bugs.webkit.org/show_bug.cgi?id=157091

        Reviewed by Darin Adler.

        While we ensure that direct super is under the correct context,
        we don't check it for the eval code. This patch moves the check from the end of parsing the function
        to the places where we found the direct super or the super bindings. This covers the direct eval that
        contains the direct super calls.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Scope::hasDirectSuper):
        (JSC::Scope::setHasDirectSuper):
        (JSC::Scope::needsSuperBinding):
        (JSC::Scope::setNeedsSuperBinding):
        (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
        * tests/stress/eval-and-super.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.m):
        (prototype.n):
        * tests/stress/generator-and-super.js: Added.
        (testSyntaxError):
        (testSyntaxError.Base.prototype.hello):
        (testSyntaxError.Base.prototype.ok):
        (testSyntaxError.Base):
        (Hello.prototype.gen):
        (Hello):
        (testSyntaxError.hello):

2016-05-03  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes
        https://bugs.webkit.org/show_bug.cgi?id=157333

        Reviewed by Benjamin Poulain.
        
        I forgot to add logic for lazy properties in putEntry(). It turns out that it's easy to
        add.

        * runtime/Lookup.h:
        (JSC::putEntry):
        * runtime/PropertySlot.h:

2016-05-03  Filip Pizlo  <fpizlo@apple.com>

        References from code to Structures should be stronger than weak
        https://bugs.webkit.org/show_bug.cgi?id=157324

        Reviewed by Mark Lam.
        
        If code refers to a Structure and the Structure dies, then previously we'd kill the code. 
        This makes sense because the Structure could be the only thing left referring to some global
        object or prototype.

        But this also causes unnecessary churn. Sometimes there will be a structure that we just
        haven't really done anything with recently and so it appears dead. The approach we use
        elsewhere in our type inference is that the type that the code uses is general enough to
        handle every past execution. Having the GC clear code when some Structure it uses dies means
        that we forget that the code used that Structure. We'll either assume that the code is more
        monomorphic than it really is (because after GC we patch in some other structure but not the
        deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's
        crazier than it really is (because we'll remember that there had been some structure that
        caused deletion, so we'll assume that deletions might happen in the future, so we'll use a
        fully dynamic IC).

        This change introduces a more nuanced policy: if it's cheap to mark a dead Structure then we
        should mark it just so that all of the code that refers to it remembers that there had been
        this exact Structure in the past. If the code often goes through different Structures then
        we already have great mechanisms to realize that the code is nutty (namely, the
        PolymorphicAccess size limit). But if the code just does this a handful of times then
        remembering this old Structure is probably net good:

        - It obeys the "handle all past executions" law.
        - It preserves the history of the property access, allowing a precise measure of its past
          polymorphism.
        - It makes the code ready to run fast if the user decides to use that Structure again.
          Marking the Structure means it will stay in whatever property transition tables it was in,
          so if the program does the same thing it did in the past, it will get this old Structure.

        It looks like this is a progression in gbemu and it makes gbemu perform more
        deterministically. Also, it seems that this makes JetStream run faster.
        
        Over five in-browser runs of JetStream, here's what we see before and after:
        
        Geometric Mean:
            Before              After
            229.23 +- 8.2523    230.70 +- 12.888
            232.91 +- 15.638    239.04 +- 13.766
            234.79 +- 12.760    236.32 +- 15.562
            236.20 +- 23.125    242.02 +- 3.3865
            237.22 +- 2.1929    237.23 +- 17.664
        
        Just gbemu:
            Before              After
            541.0 +- 135.8      481.7 +- 143.4
            518.9 +- 15.65      508.1 +- 136.3
            362.5 +- 0.8884     489.7 +- 101.4
            470.7 +- 313.3      530.7 +- 11.49
            418.7 +- 180.6      537.2 +- 6.514
        
        Notice that there is plenty of noise before and after, but the noise is now far less severe.
        After this change I did not see any runs like "470.7 +- 313.3" where the size of the 
        confidence interval (313.3 * 2) is greater than the score (470.7). Also, notice that the
        least noisy run before the change also got a lower score than we ever observed after the
        change (36.5 +- 0.8884). The noise, and these occasional very low scores, are due to a
        pathology where the GC would reset some stubs at an unfortunate time during profiling,
        causing the optimizing compiler to make many poor decisions. That pathology doesn't exist
        anymore.
        
        On the other hand, prior to this change it was possible for gbemu to sometimes run sooooper
        fast because the GC would cause the profiler to forget gbemu's behavior on the first tick
        and focus only on its behavior in subsequent ticks. So, in steady state, we'd optimize gbemu
        for its later behavior rather than a combination of its early behavior and later behavior.
        We rarely got lucky this way, so it's not fair to view this quirk as a feature.
        
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::propagateTransitions):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::propagateTransitions):
        (JSC::AccessCase::generateWithGuard):
        (JSC::PolymorphicAccess::visitWeak):
        (JSC::PolymorphicAccess::propagateTransitions):
        (JSC::PolymorphicAccess::dump):
        * bytecode/PolymorphicAccess.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::visitWeakReferences):
        (JSC::StructureStubInfo::propagateTransitions):
        (JSC::StructureStubInfo::containsPC):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        * runtime/Structure.cpp:
        (JSC::Structure::visitChildren):
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::markIfCheap):
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        * runtime/Structure.h:

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Simplify console.clear
        https://bugs.webkit.org/show_bug.cgi?id=157316

        Reviewed by Timothy Hatcher.

        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::createEmpty):
        (Inspector::ScriptArguments::ScriptArguments):
        * inspector/ScriptArguments.h:
        Provide a way to create an empty list.

        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::clear):
        * runtime/ConsoleClient.h:
        Drop unnecessary parameter.

        * runtime/ConsoleObject.cpp:
        (JSC::consoleProtoFuncClear):
        No need to parse arguments.

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

        Improve Symbol() to string coercion error message
        https://bugs.webkit.org/show_bug.cgi?id=157317

        Reviewed by Geoffrey Garen.

        Improve error messages related to Symbols.

        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toStringSlowCase):
        * runtime/Symbol.cpp:
        (JSC::Symbol::toNumber):
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):
        * runtime/SymbolPrototype.cpp:
        (JSC::symbolProtoFuncToString):
        (JSC::symbolProtoFuncValueOf):
        * tests/stress/dfg-to-primitive-pass-symbol.js:
        * tests/stress/floating-point-div-to-mul.js:
        (i.catch):
        * tests/stress/string-from-code-point.js:
        (shouldThrow):
        (string_appeared_here.shouldThrow):
        * tests/stress/symbol-error-messages.js: Added.
        (shouldThrow):
        * tests/stress/symbol-registry.js:

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Give console.time/timeEnd a default label and warnings
        https://bugs.webkit.org/show_bug.cgi?id=157325
        <rdar://problem/26073290>

        Reviewed by Timothy Hatcher.

        Provide more user friendly console.time/timeEnd. The timer name
        is now optional, and is "default" if not provided. Also provide
        warnings when attempting to start an already started timer,
        or stop a timer that does not exist.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::startTiming):
        (Inspector::InspectorConsoleAgent::stopTiming):
        Warnings for bad cases.

        * runtime/ConsoleObject.cpp:
        (JSC::defaultLabelString):
        (JSC::consoleProtoFuncTime):
        (JSC::consoleProtoFuncTimeEnd):
        Optional label becomes "default".

2016-05-03  Xan Lopez  <xlopez@igalia.com>

        Fix the ENABLE(WEBASSEMBLY) build
        https://bugs.webkit.org/show_bug.cgi?id=157312

        Reviewed by Darin Adler.

        * runtime/Executable.cpp:
        (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::convertValueToDouble):

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused parameter of ScriptArguments::getFirstArgumentAsString
        https://bugs.webkit.org/show_bug.cgi?id=157301

        Reviewed by Timothy Hatcher.

        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::getFirstArgumentAsString):
        * inspector/ScriptArguments.h:
        Remove unused argument and related code.

        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::printConsoleMessageWithArguments):
        Drive by remove unnecessary cast.

2016-05-03  Michael Saboff  <msaboff@apple.com>

        Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
        https://bugs.webkit.org/show_bug.cgi?id=157322

        Reviewed by Filip Pizlo.

        Check to see if the source array has changed length before calling fastSlice().
        If it has, take the slow path.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSlice):
        (JSC::arrayProtoFuncSplice):
        * tests/stress/regress-157322.js: New test.

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Eliminate PassRefPtr conversion from ConsoleObject
        https://bugs.webkit.org/show_bug.cgi?id=157300

        Reviewed by Timothy Hatcher.

        * runtime/ConsoleObject.cpp:
        (JSC::consoleLogWithLevel):
        (JSC::consoleProtoFuncClear):
        (JSC::consoleProtoFuncDir):
        (JSC::consoleProtoFuncDirXML):
        (JSC::consoleProtoFuncTable):
        (JSC::consoleProtoFuncTrace):
        (JSC::consoleProtoFuncAssert):
        (JSC::consoleProtoFuncCount):
        (JSC::consoleProtoFuncTimeStamp):
        (JSC::consoleProtoFuncGroup):
        (JSC::consoleProtoFuncGroupCollapsed):
        (JSC::consoleProtoFuncGroupEnd):
        No need to release to a PassRefPtr, we can just move into the RefPtr<>&&.

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

        Speed up JSGlobalObject initialization by making some properties lazy
        https://bugs.webkit.org/show_bug.cgi?id=157045

        Reviewed by Keith Miller.
        
        This makes about half of JSGlobalObject's state lazy. There are three categories of
        state in JSGlobalObject:
        
        1) C++ fields in JSGlobalObject.
        2) JS object properties in JSGlobalObject's JSObject superclass.
        3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
        
        State held in JS variables cannot yet be made lazy. That's why this patch only goes
        half-way.
        
        State in JS object properties can be made lazy if we move it to the static property
        hashtable. JSGlobalObject already had one of those. This patch makes static property
        hashtables a lot more powerful, by adding three new kinds of static properties. These
        new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
        
        State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
        lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
        JSGlobalObject and we are adding more all the time. We don't want to require that each
        of these has a getter with an initialization check and a corresponding out-of-line slow
        path that does the initialization. We want this kind of boilerplate to be handled by
        some abstractions.
        
        The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
        only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
        You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
        so it's almost a drop-in replacement.
        
        The key to LazyProperty<Type>'s power is that you can do this:
        
            class Bar {
                ...
                LazyProperty<Foo> m_foo;
            };
            ...
            m_foo.initLater(
                [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
                    init.set(Foo::create(init.vm, init.owner));
                });
        
        This initLater() call requires that you pass a stateless lambda (see WTF changelog for
        the definition). Miraculously, this initLater() call is guaranteed to compile to a store
        of a pointer constant to m_foo, as in:
        
            movabsq 0xBLAH, %rax
            movq %rax, &m_foo
        
        This magical pointer constant points to a callback that was generated by the template
        instantiation of initLater(). That callback knows to call your stateless lambda, but
        also does some other bookkeeping: it makes sure that you indeed initialized the property
        inside the callback and it manages recursive initializations. It's totally legal to call
        m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
        m_foo.get() will return null. This is an excellent escape hatch if we ever find
        ourselves in a dependency cycle. I added this feature because I already had to create a
        dependency cycle.
        
        Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
        to get this right. The DFG thread cannot initialize those fields, so it has to make sure
        that it does conservative things. But for some nodes this could mean adding a lot of new
        logic, like NewTypedArray, which currently is written in such a way that it assumes that
        we always have the typed array structure. Currently we take a two-fold approach: for
        typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
        initialized, and for everything else we don't make the properties lazy if the DFG needs
        them. As we optimize this further we might need to teach the DFG to handle more lazy
        properties. I tried to do this for RegExp but found it to be very confusing. With typed
        arrays I got lucky.
        
        There is also a somewhat more powerful construct called LazyClassStructure. We often
        need to keep around the structure of some standard JS class, like Date. We also need to
        make sure that the constructor ends up in the global object's property table. And we
        often need to keep the original value of the constructor for ourselves. In this case, we
        want to make sure that the creation of the structure-prototype-constructor constellation
        is atomic. We don't want code to start looking at the structure if it points to a
        prototype that doesn't have its "constructor" property set yet, for example.
        LazyClassStructure solves this by abstracting that whole initialization. You provide the
        callback that allocates everything, since we are super inconsistent about the way we
        initialize things, but LazyClassStructure establishes the workflow and helps you not
        mess up.
        
        Finally, the new static hashtable attributes allow for all of this to work with the JS
        property table:
        
        PropertyCallback: if you use this attribute, the second column in the table should be
        the name of a function to call to initialize this property. This is useful for things
        like the Math property. The Math object turns out to be very expensive to allocate.
        Delaying its allocation is super easy with the PropertyCallback attribute.
        
        CellProperty: with this attribute the second column should be a C++ field name like
        JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
        this property, and when it needs to be initialized, Lookup will assume you have a
        LazyProperty<JSCell> and call its get() method. It will initialize the property to
        whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
        LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
        call whatever callback function pointer is encoded in the property and it does not need
        to know anything about what type that callback will instantiate.
        
        ClassStructure: with this attribute the second column should be a C++ field name. The
        static hashtable will initialize the property by treating the field as a
        LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
        initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
        the property in question will already be set. By convention, we have LazyClassStructure
        initialize the property with a pointer to the constructor, since that's how all of our
        classes work: "globalObject.Date" points to the DateConstructor.
        
        This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
        calls our C API. This is a 1% speed-up on SunSpider and JSRegress.

        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::create):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::impl):
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * create_hash_table:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::originalArrayStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::materializeSpecials):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::visitChildren):
        (JSC::InternalFunction::name):
        (JSC::InternalFunction::calculatedDisplayName):
        (JSC::InternalFunction::createSubclassStructure):
        * runtime/InternalFunction.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGlobalObject.cpp:
        (JSC::createProxyProperty):
        (JSC::createJSONProperty):
        (JSC::createMathProperty):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::toThis):
        (JSC::JSGlobalObject::getOwnPropertySlot):
        (JSC::JSGlobalObject::createThrowTypeError): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::objectConstructor):
        (JSC::JSGlobalObject::promiseConstructor):
        (JSC::JSGlobalObject::internalPromiseConstructor):
        (JSC::JSGlobalObject::evalErrorConstructor):
        (JSC::JSGlobalObject::rangeErrorConstructor):
        (JSC::JSGlobalObject::referenceErrorConstructor):
        (JSC::JSGlobalObject::syntaxErrorConstructor):
        (JSC::JSGlobalObject::typeErrorConstructor):
        (JSC::JSGlobalObject::URIErrorConstructor):
        (JSC::JSGlobalObject::nullGetterFunction):
        (JSC::JSGlobalObject::nullSetterFunction):
        (JSC::JSGlobalObject::callFunction):
        (JSC::JSGlobalObject::applyFunction):
        (JSC::JSGlobalObject::definePropertyFunction):
        (JSC::JSGlobalObject::arrayProtoValuesFunction):
        (JSC::JSGlobalObject::initializePromiseFunction):
        (JSC::JSGlobalObject::newPromiseCapabilityFunction):
        (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
        (JSC::JSGlobalObject::regExpProtoExecFunction):
        (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
        (JSC::JSGlobalObject::regExpProtoGlobalGetter):
        (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
        (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
        (JSC::JSGlobalObject::moduleLoader):
        (JSC::JSGlobalObject::objectPrototype):
        (JSC::JSGlobalObject::functionPrototype):
        (JSC::JSGlobalObject::arrayPrototype):
        (JSC::JSGlobalObject::booleanPrototype):
        (JSC::JSGlobalObject::stringPrototype):
        (JSC::JSGlobalObject::symbolPrototype):
        (JSC::JSGlobalObject::numberPrototype):
        (JSC::JSGlobalObject::datePrototype):
        (JSC::JSGlobalObject::regExpPrototype):
        (JSC::JSGlobalObject::errorPrototype):
        (JSC::JSGlobalObject::iteratorPrototype):
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::debuggerScopeStructure):
        (JSC::JSGlobalObject::withScopeStructure):
        (JSC::JSGlobalObject::strictEvalActivationStructure):
        (JSC::JSGlobalObject::activationStructure):
        (JSC::JSGlobalObject::moduleEnvironmentStructure):
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::clonedArgumentsStructure):
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        (JSC::JSGlobalObject::booleanObjectStructure):
        (JSC::JSGlobalObject::callbackConstructorStructure):
        (JSC::JSGlobalObject::callbackFunctionStructure):
        (JSC::JSGlobalObject::callbackObjectStructure):
        (JSC::JSGlobalObject::propertyNameIteratorStructure):
        (JSC::JSGlobalObject::objcCallbackFunctionStructure):
        (JSC::JSGlobalObject::objcWrapperObjectStructure):
        (JSC::JSGlobalObject::dateStructure):
        (JSC::JSGlobalObject::nullPrototypeObjectStructure):
        (JSC::JSGlobalObject::errorStructure):
        (JSC::JSGlobalObject::calleeStructure):
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        (JSC::JSGlobalObject::numberObjectStructure):
        (JSC::JSGlobalObject::privateNameStructure):
        (JSC::JSGlobalObject::mapStructure):
        (JSC::JSGlobalObject::regExpStructure):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        (JSC::JSGlobalObject::setStructure):
        (JSC::JSGlobalObject::stringObjectStructure):
        (JSC::JSGlobalObject::symbolObjectStructure):
        (JSC::JSGlobalObject::iteratorResultObjectStructure):
        (JSC::JSGlobalObject::lazyTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructure):
        (JSC::JSGlobalObject::typedArrayStructureConcurrently):
        (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
        (JSC::JSGlobalObject::typedArrayConstructor):
        (JSC::JSGlobalObject::actualPointerFor):
        (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
        * runtime/JSNativeStdFunction.cpp:
        (JSC::JSNativeStdFunction::create):
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::create):
        (JSC::JSWithScope::visitChildren):
        (JSC::JSWithScope::createStructure):
        (JSC::JSWithScope::JSWithScope):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::object):
        (JSC::JSWithScope::create): Deleted.
        (JSC::JSWithScope::createStructure): Deleted.
        (JSC::JSWithScope::JSWithScope): Deleted.
        * runtime/LazyClassStructure.cpp: Added.
        (JSC::LazyClassStructure::Initializer::Initializer):
        (JSC::LazyClassStructure::Initializer::setPrototype):
        (JSC::LazyClassStructure::Initializer::setStructure):
        (JSC::LazyClassStructure::Initializer::setConstructor):
        (JSC::LazyClassStructure::visit):
        (JSC::LazyClassStructure::dump):
        * runtime/LazyClassStructure.h: Added.
        (JSC::LazyClassStructure::LazyClassStructure):
        (JSC::LazyClassStructure::get):
        (JSC::LazyClassStructure::prototype):
        (JSC::LazyClassStructure::constructor):
        (JSC::LazyClassStructure::getConcurrently):
        (JSC::LazyClassStructure::prototypeConcurrently):
        (JSC::LazyClassStructure::constructorConcurrently):
        * runtime/LazyClassStructureInlines.h: Added.
        (JSC::LazyClassStructure::initLater):
        * runtime/LazyProperty.h: Added.
        (JSC::LazyProperty::Initializer::Initializer):
        (JSC::LazyProperty::LazyProperty):
        (JSC::LazyProperty::get):
        (JSC::LazyProperty::getConcurrently):
        * runtime/LazyPropertyInlines.h: Added.
        (JSC::LazyProperty<ElementType>::Initializer<OwnerType>::set):
        (JSC::LazyProperty<ElementType>::initLater):
        (JSC::LazyProperty<ElementType>::setMayBeNull):
        (JSC::LazyProperty<ElementType>::set):
        (JSC::LazyProperty<ElementType>::visit):
        (JSC::LazyProperty<ElementType>::dump):
        (JSC::LazyProperty<ElementType>::callFunc):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::HashTableValue::function):
        (JSC::HashTableValue::functionLength):
        (JSC::HashTableValue::propertyGetter):
        (JSC::HashTableValue::propertyPutter):
        (JSC::HashTableValue::accessorGetter):
        (JSC::HashTableValue::accessorSetter):
        (JSC::HashTableValue::constantInteger):
        (JSC::HashTableValue::lexerValue):
        (JSC::HashTableValue::lazyCellPropertyOffset):
        (JSC::HashTableValue::lazyClassStructureOffset):
        (JSC::HashTableValue::lazyPropertyCallback):
        (JSC::getStaticPropertySlot):
        (JSC::getStaticValueSlot):
        (JSC::reifyStaticProperty):
        * runtime/PropertySlot.h:
        * runtime/TypedArrayType.h:

2016-05-03  Per Arne Vollan  <peavo@outlook.com>

        [Win] Remove Windows XP Compatibility Requirements
        https://bugs.webkit.org/show_bug.cgi?id=152899

        Reviewed by Brent Fulgham.

        Windows XP is not supported anymore, we can remove workarounds.

        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
        (enableTerminationOnHeapCorruption):

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.assert should do far less work when the assertion is true
        https://bugs.webkit.org/show_bug.cgi?id=157297
        <rdar://problem/26056556>

        Reviewed by Timothy Hatcher.

        * runtime/ConsoleClient.h:
        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::assertion):
        (JSC::ConsoleClient::assertCondition): Deleted.
        Rename, now that this will only get called when the assertion failed.

        * runtime/ConsoleObject.cpp:
        (JSC::consoleProtoFuncAssert):
        Avoid doing any work if the assertion succeeded.

2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed follow-up testapi fix after r200355.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        Revert back to non-enumerable. This matches our older behavior,
        we can decide to make this Enumerable later if needed.

2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Reflect.toString() should be [object Object] not [object Reflect]
        https://bugs.webkit.org/show_bug.cgi?id=157288

        Reviewed by Darin Adler.

        * runtime/ReflectObject.cpp:
        * tests/stress/reflect.js: Added.

2016-05-02  Jon Davis  <jond@apple.com>

        Add Resource Timing entry to the Feature Status page.
        https://bugs.webkit.org/show_bug.cgi?id=157285

        Reviewed by Timothy Hatcher.

        * features.json:

2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>

        Make console a namespace object (like Math/JSON), allowing functions to be called unbound
        https://bugs.webkit.org/show_bug.cgi?id=157286
        <rdar://problem/26052830>

        Reviewed by Timothy Hatcher.

        This changes `console` to be a global namespace object, like `Math` and `JSON`.
        It just holds a bunch of functions, that can be used on their own, unbound.
        For example, `[1,2,3].forEach(console.log)` and `var log = console.log; log(1)`
        used to throw exceptions and now do not.

        Previously console was an Object/Prototype pair, so functions were on
        ConsolePrototype (console.__proto__.log) and they needed to be called
        Console objects as the `this` value. Now, `console` is just a standard
        object with a bunch of functions. Since there is no console prototype the
        functions can be passed around and called as expected and they will
        just do the right thing.

        For compatability with other browsers, `console` was made enumerable
        on the global object.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add new files and remove old files.

        * runtime/CommonIdentifiers.h:
        Add "console".

        * runtime/ConsoleObject.cpp: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.cpp.
        (JSC::ConsoleObject::ConsoleObject):
        (JSC::ConsoleObject::finishCreation):
        (JSC::valueToStringWithUndefinedOrNullCheck):
        (JSC::consoleLogWithLevel):
        (JSC::consoleProtoFuncDebug):
        (JSC::consoleProtoFuncError):
        (JSC::consoleProtoFuncLog):
        (JSC::consoleProtoFuncInfo):
        (JSC::consoleProtoFuncWarn):
        (JSC::consoleProtoFuncClear):
        (JSC::consoleProtoFuncDir):
        (JSC::consoleProtoFuncDirXML):
        (JSC::consoleProtoFuncTable):
        (JSC::consoleProtoFuncTrace):
        (JSC::consoleProtoFuncAssert):
        (JSC::consoleProtoFuncCount):
        (JSC::consoleProtoFuncProfile):
        (JSC::consoleProtoFuncProfileEnd):
        (JSC::consoleProtoFuncTakeHeapSnapshot):
        (JSC::consoleProtoFuncTime):
        (JSC::consoleProtoFuncTimeEnd):
        (JSC::consoleProtoFuncTimeStamp):
        (JSC::consoleProtoFuncGroup):
        (JSC::consoleProtoFuncGroupCollapsed):
        (JSC::consoleProtoFuncGroupEnd):
        Console functions no longer need to check if the this object is
        a Console object. They will always just work now.

        * runtime/MathObject.cpp:
        * runtime/MathObject.h:
        * runtime/ConsoleObject.h: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.h.
        (JSC::ConsoleObject::create):
        (JSC::ConsoleObject::createStructure):
        ConsoleObject is a basic object like MathObject.

        * runtime/JSConsole.cpp: Removed.
        * runtime/JSConsole.h: Removed.
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        Remove JSConsole / ConsolePrototype in favor of the single ConsoleObject.

2016-05-02  Per Arne Vollan  <peavo@outlook.com>

        [Win] Clean up annoying compiler warnings
        https://bugs.webkit.org/show_bug.cgi?id=149813

        Reviewed by Alex Christensen.

        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isWatchableWhenValid):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::sendPendingErrors):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createWithInlineFrame):
        * runtime/Error.cpp:
        (JSC::addErrorInfoAndGetBytecodeOffset):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::initializeNumberFormat):
        * runtime/JSObject.cpp:
        (JSC::JSObject::heapSnapshot):
        (JSC::callToPrimitiveFunction):
        * runtime/RegExpPrototype.cpp:
        (JSC::flagsString):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::functionStartColumn):

2016-05-02  Keith Miller  <keith_miller@apple.com>

        ToThis should be able to be eliminated in Constant Folding
        https://bugs.webkit.org/show_bug.cgi?id=157213

        Reviewed by Saam Barati.

        This patch enables eliminating the ToThis value when we have abstract interpreter
        indicates the node is not needed. Since there are Objects that override their
        ToThis behavior we first check if we can eliminate the node by looking at its
        speculated type. If the function is in strict mode then we can eliminate ToThis as
        long as the speculated type is not SpecObjectOther since that contains objects
        that may set OverridesToThis. If the function is not in strict mode then we can
        eliminate ToThis as long is the speculated type is an object that is not SpecObjectOther.

        If we can't eliminate with type information we can still eliminate the ToThis node with
        the proven structure set. When ToThis only sees structures that do not set OverridesToThis
        it can be eliminated. Additionally, if the function is in strict mode then we can eliminate
        ToThis as long as all only the object structures don't set OverridesToThis.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::isToThisAnIdentity):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupToThis):
        * tests/stress/to-this-global-object.js: Added.
        (test):
        (test2):
        (get for):

2016-05-01  Skachkov Oleksandr  <gskachkov@gmail.com>

        Class contructor and methods shouldn't have "arguments" and "caller"
        https://bugs.webkit.org/show_bug.cgi?id=144238

        Reviewed by Ryosuke Niwa.

        Added TypeError that is raised in case of access to properties 'arguments' or 'caller'
        of constructor or method of class. Actually TypeError already raised for most cases, except
        case with undeclared constructor e. g. 
        class A {}
        (new A).constructor.caller 
        (new A).constructor.arguments

        * runtime/JSFunction.cpp:
        (JSC::getThrowTypeErrorGetterSetter):
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncThrowTypeErrorArgumentsAndCaller):
        * runtime/JSGlobalObjectFunctions.h:

2016-05-02  Yoav Weiss  <yoav@yoav.ws>

        Move ResourceTiming behind a runtime flag
        https://bugs.webkit.org/show_bug.cgi?id=157133

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names.

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

        Assertion failure for bound function with custom prototype and Reflect.construct
        https://bugs.webkit.org/show_bug.cgi?id=157081

        Reviewed by Saam Barati.

        We ensured `newTarget != exec->callee()`. However, it does not mean `newTarget.get("prototype") != exec->callee()->get("prototype")`.
        When the given `prototype` is the same to `baseStructure->sotredPrototype()`, it is unnecessary to create a new structure from this
        baseStructure.

        * bytecode/InternalFunctionAllocationProfile.h:
        (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
        * tests/stress/custom-prototype-may-be-same-to-original-one.js: Added.
        (shouldBe):
        (boundFunction):

2016-04-30  Konstantin Tokarev  <annulen@yandex.ru>

        Guard ObjC-specific code in Heap.cpp with USE(FOUNDATION)
        https://bugs.webkit.org/show_bug.cgi?id=157236

        Reviewed by Darin Adler.

        This also fixes build with GCC 4.8 which does not provide
        __has_include.

        * heap/Heap.cpp:

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

        Assertion failure for destructuring assignment with new.target and unary operator
        https://bugs.webkit.org/show_bug.cgi?id=157149

        Reviewed by Saam Barati.

        The caller of parseDefaultValueForDestructuringPattern() should propagate errors.
        And this patch also cleans up createSavePoint and createSavePointForError; introducing SavePointWithError.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSourceElements):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        Add propagateErorr() for parseDefaultValueForDestructuringPattern.

        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Parser::restoreLexerState):
        (JSC::Parser::internalSaveState):
        (JSC::Parser::createSavePointForError):
        (JSC::Parser::createSavePoint):
        (JSC::Parser::internalRestoreState):
        (JSC::Parser::restoreSavePointWithError):
        (JSC::Parser::restoreSavePoint):
        * tests/stress/default-value-parsing-should-propagate-error.js: Added.
        (testSyntaxError):
        (testSyntaxError.f):

2016-04-28  Darin Adler  <darin@apple.com>

        First step in using "enum class" instead of "String" for enumerations in DOM
        https://bugs.webkit.org/show_bug.cgi?id=157163

        Reviewed by Chris Dumez.

        * runtime/JSString.h:
        (JSC::jsStringWithCache): Deleted unneeded overload for AtomicString.

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

        [JSC][ARMv7S] Arithmetic module results change when tiering up to DFG
        https://bugs.webkit.org/show_bug.cgi?id=157217
        rdar://problem/24733432

        Reviewed by Mark Lam.

        ARMv7's fmod() returns less accurate results than an integer division.
        Since we have integer div on ARMv7s, the results start changing when
        we reach DFG.

        In this patch, I change our fmod slow path to behave like the fast path
        on ARMv7s.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        (JSC::DFG::fmodAsDFGOperation): Deleted.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/MathCommon.cpp:
        (JSC::isStrictInt32):
        * runtime/MathCommon.h:

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

        Web Inspector: Issues inspecting the inspector, pausing on breakpoints causes content to not load
        https://bugs.webkit.org/show_bug.cgi?id=157198
        <rdar://problem/26011049>

        Reviewed by Timothy Hatcher.

        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::sendResponse):
        While auditing the code, add a WTFMove.

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

        Make RegExp.prototype.test spec compliant.
        https://bugs.webkit.org/show_bug.cgi?id=155862

        Reviewed by Saam Barati.

        * builtins/RegExpPrototype.js:
        (intrinsic.RegExpTestIntrinsic.test):

        * create_hash_table:
        - Delete obsoleted code.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        - We now have 2 intrinsics for RegExp.prototype.test:
          RegExpTestIntrinsic and RegExpTestFastIntrinsic.

          RegExpTestIntrinsic maps to the entry at the top of the builtin ES6
          RegExp.prototype.test.
          RegExpTestFastIntrinsic maps to the fast path in the builtin ES6
          RegExp.prototype.test.

          Both will end up using the RegExpTest DFG node to implement the fast path
          of RegExp.prototype.test.  RegExpTestIntrinsic will have some additional checks
          before the RegExpTest node.  Those checks are for speculating that it is ok for
          us to take the fast path.

        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Added the regExpTestFast function.
        - Also fixed the parameter length on 2 other functions that were erroneous.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncTest): Deleted.
        * runtime/RegExpPrototype.h:
        * tests/es6.yaml:

2016-04-29  Benjamin Poulain  <benjamin@webkit.org>

        Extend math-pow-stable-results.js to get more information about the failure

        * tests/stress/math-pow-stable-results.js:

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

        Assertion failure for exception in "prototype" property getter and Reflect.construct
        https://bugs.webkit.org/show_bug.cgi?id=157084

        Reviewed by Mark Lam.

        InternalFunction::createSubclassStrucuture may throw exceptions because it performs [[Get]] to
        look up the "prototype" object. The current assertion is invalid.
        We also found that Object constructor is not aware of new.target. This is filed[1].

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

        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::createSubclassStructure):
        * tests/stress/create-subclass-structure-may-throw-exception-when-getting-prototype.js: Added.
        (shouldThrow):
        (bf):

2016-04-29  Commit Queue  <commit-queue@webkit.org>

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

        This change broke the Mac CMake build and its LayoutTest is
        failing and/or flaky on all platforms (Requested by ryanhaddad
        on #webkit).

        Reverted changeset:

        "Move ResourceTiming behind a runtime flag"
        https://bugs.webkit.org/show_bug.cgi?id=157133
        http://trac.webkit.org/changeset/200232

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

        [ES6] RegExp.prototype.@@replace should use @isObject instead of `instanceof` for object guard
        https://bugs.webkit.org/show_bug.cgi?id=157124

        Reviewed by Keith Miller.

        Use @isObject instead of `instanceof @Object`.
        The `instanceof` check is not enough to check Object Type.
        This fix itself is the same to r199647, and this patch is for RegExp.prototype.@@replace.

        * builtins/RegExpPrototype.js:
        (replace):
        * tests/stress/regexp-replace-in-other-realm-should-work.js: Added.
        (shouldBe):
        * tests/stress/regexp-replace-should-work-with-objects-not-inheriting-object-prototype.js: Added.
        (shouldBe):
        (regexp.exec):

2016-04-29  Yoav Weiss  <yoav@yoav.ws>

        Move ResourceTiming behind a runtime flag
        https://bugs.webkit.org/show_bug.cgi?id=157133

        Reviewed by Alex Christensen.

        * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names.

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

        Remove unused bool parameter in CodeCache::getGlobalCodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=157156

        Reviewed by Mark Lam.

        The bool parameter appears to be isArrowFunctionContext, but the method's
        contents just get that property from the Executable, so the parameter is
        unnecessary and unused.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        * runtime/CodeCache.h:
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::create):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:

2016-04-28  Caitlin Potter  <caitp@igalia.com>

        [JSC] re-implement String#padStart and String#padEnd in JavaScript
        https://bugs.webkit.org/show_bug.cgi?id=157146

        Reviewed by Saam Barati.

        * builtins/StringPrototype.js:
        (repeatCharactersSlowPath):
        (padStart):
        (padEnd):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation): Deleted.
        (JSC::repeatStringPattern): Deleted.
        (JSC::padString): Deleted.
        (JSC::stringProtoFuncPadEnd): Deleted.
        (JSC::stringProtoFuncPadStart): Deleted.

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

        Web Inspector: Tweak auto attach initialization on some platforms
        https://bugs.webkit.org/show_bug.cgi?id=157150
        <rdar://problem/21222045>

        Reviewed by Timothy Hatcher.

        * inspector/EventLoop.cpp:
        (Inspector::EventLoop::cycle):
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):

2016-04-28  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Unify Math.pow() accross all tiers
        https://bugs.webkit.org/show_bug.cgi?id=157121

        Reviewed by Geoffrey Garen.

        My previous optimizations of DFG compile time have slowly
        regressed Sunspider's math-partial-sums.

        What is happenning is baseline used a thunk for Math.pow()
        that has a special case for an exponent of -0.5, while
        DFG/FTL have other special cases for other exponents.
        The faster we get to DFG, the less time we spend in that fast
        case for -0.5.

        While looking into this, I discovered some correctness issues. Baseline
        optimizes y=-0.5 by turning it into 1/sqrt(). DFG/FTL optimize constant
        y=0.5 by turning it into sqrt(). The problem is sqrt() behaves differently
        for -0 and -Infinity. With sqrt(), negative numbers are undefined,
        and the result is NaN. With pow(), they have a result.

        Something else that has bothered me for a while is that Math.pow()
        with the same arguments give you different results in LLINT, Baseline,
        and DFG/FTL. This seems a bit dangerous for numerical stability.

        With this patch, I unify the behaviors for all tiers while keeping
        the "special cases".

        We have pow() that is super slow, but most callers don't need the
        full power. We have:
        -pow() with an exponent between 0 and 1000 is a fast path implemented
         by multiplication only.
        -pow(x, 0.5) is sqrt with special checks for negative values.
        -pow(x, -0.5) is sqrt with special checks for negative values.

        The C++ implementation handles all those optimizations too. This ensure
        you get the same results from LLINT to FTL.

        The thunk is eliminated, it was producing incorrect results and only
        optimized Sunspider's partial-sums.

        DFG gets the optimized integer, 0.5 and -0.5 cases since those are important
        for somewhat-hot code. DFG falls back to the C++ code for any non-obvious case.

        FTL gets the full C++ implementation inlined in B3. B3 knows how to eliminate
        all the dead cases so you get the best if your code is hot enough to reach FTL.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToArithSqrt): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::compileArithPowIntegerFastPath):
        (JSC::DFG::SpeculativeJIT::compileArithPow):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
        * jit/ThunkGenerators.cpp:
        (JSC::powThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        * runtime/MathCommon.cpp:
        (JSC::operationMathPow):
        * runtime/MathCommon.h:
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic): Deleted.
        * tests/stress/math-pow-stable-results.js: Added.
        Getting consistent results when tiering up is new.
        This test verify that results always remains the same as LLINT.

        * tests/stress/math-pow-with-constants.js:
        (testPowUsedAsSqrt):
        (powUsedAsOneOverSqrt):
        (testPowUsedAsOneOverSqrt):
        (powUsedAsSquare):
        (testPowUsedAsSquare):

2016-04-28  Mark Lam  <mark.lam@apple.com>

        DebuggerScope::className() should not assert scope->isValid().
        https://bugs.webkit.org/show_bug.cgi?id=157143

        Reviewed by Keith Miller.

        DebuggerScope::className() should not assert scope->isValid() because the
        TypeProfiler logs objects it encounters, and may indirectly call
        JSObject::calculatedClassName() on those objects later, thereby calling
        DebuggerScope::className() on an invalidated DebuggerScope.

        The existing handling in DebuggerScope::className() for an invalidated scope
        (that returns a null string) is sufficient.

        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::className):

2016-04-28  Caitlin Potter  <caitp@igalia.com>

        [JSC] implement spec changes for String#padStart and String#padEnd
        https://bugs.webkit.org/show_bug.cgi?id=157139

        Reviewed by Keith Miller.

        Previously, if the fill string was the empty string, it was treated as a
        single U+0020 SPACE character. Now, if this occurs, the original string
        is returned instead.

        Change was discussed at TC39 in March [1], and is reflected in new
        test262 tests for the feature.

        [1] https://github.com/tc39/tc39-notes/blob/master/es7/2016-03/march-29.md#stringprototypepadstartpadend

        * runtime/StringPrototype.cpp:
        (JSC::padString):
        * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
        (TestFillerToString):
        (TestFillerEmptyString):
        * tests/es6/String.prototype_methods_String.prototype.padStart.js:
        (TestFillerToString):
        (TestFillerEmptyString):

2016-04-28  Skachkov Oleksandr  <gskachkov@gmail.com>

        Crash for non-static super property call in derived class constructor
        https://bugs.webkit.org/show_bug.cgi?id=157089

        Reviewed by Darin Adler.
       
        Added tdz check of the 'this' before access to the 'super' for FunctionCallBracketNode, 
        the same as it was done for FunctionCallDotNode.

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

2016-04-27  Mark Lam  <mark.lam@apple.com>

        The GetterSetter structure needs a globalObject.
        https://bugs.webkit.org/show_bug.cgi?id=157120

        Reviewed by Filip Pizlo.

        In r199170: <http://trac.webkit.org/r199170>, GetterSetter was promoted from
        being a JSCell to a JSObject.  JSObject methods expect their structure to have a
        globalObject.  For example, see JSObject::calculatedClassName().  GetterSetter
        was previously using a singleton getterSetterStructure owned by the VM.  That
        singleton getterSetterStructure is not associated with any globalObjects.  As a
        result, JSObject::calculatedClassName() will run into a null globalObject when it
        is called on a GetterSetter object.

        This patch removes the VM singleton getterSetterStructure, and instead, creates
        a getterSetterStructure for each JSGlobalObject.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * runtime/GetterSetter.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::functionStructure):
        (JSC::JSGlobalObject::boundFunctionStructure):
        (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
        (JSC::JSGlobalObject::getterSetterStructure):
        (JSC::JSGlobalObject::nativeStdFunctionStructure):
        (JSC::JSGlobalObject::namedFunctionStructure):
        (JSC::JSGlobalObject::functionNameOffset):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2016-04-27  Keith Miller  <keith_miller@apple.com>

        Unreviewed, Revert r199397 due to PLT regressions

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayPrototype.js:
        (concatSlowPath): Deleted.
        (concat): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted.
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
        (JSC::DFG::SpeculativeJIT::compileIsArrayObject): Deleted.
        (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): Deleted.
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
        * jit/JITOperations.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDataLogValue): Deleted.
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
        * runtime/ArrayConstructor.h:
        (JSC::isArrayConstructor): Deleted.
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncConcat):
        (JSC::arrayProtoPrivateFuncIsJSArray): Deleted.
        (JSC::moveElements): Deleted.
        (JSC::arrayProtoPrivateFuncConcatMemcpy): Deleted.
        (JSC::arrayProtoPrivateFuncAppendMemcpy): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::fastConcatWith):
        (JSC::JSArray::appendMemcpy): Deleted.
        * runtime/JSArray.h:
        (JSC::JSArray::fastConcatType):
        (JSC::JSArray::createStructure):
        (JSC::isJSArray):
        * runtime/JSArrayInlines.h: Removed.
        (JSC::JSArray::memCopyWithIndexingType): Deleted.
        (JSC::JSArray::canFastCopy): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSType.h:
        * runtime/ObjectConstructor.h:
        (JSC::constructObject): Deleted.
        * tests/es6.yaml:
        * tests/stress/array-concat-spread-object.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-concat-spread-proxy-exception-check.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-concat-spread-proxy.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-concat-with-slow-indexingtypes.js: Removed.
        (arrayEq): Deleted.
        * tests/stress/array-species-config-array-constructor.js:

2016-04-27  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r200117): Crash in lowerDFGToB3::compileStringReplace()
        https://bugs.webkit.org/show_bug.cgi?id=157099

        Reviewed by Saam Barati.

        Given that the DFGFixupPhase could mark the edge of child2 as StringUse,
        we need to lower that edge appropriately.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):

2016-04-27  Mark Lam  <mark.lam@apple.com>

        Address feedback from https://bugs.webkit.org/show_bug.cgi?id=157048#c5.
        https://bugs.webkit.org/show_bug.cgi?id=157096

        Reviewed by Geoffrey Garen.

        1. Check for USE(APPLE_INTERNAL_SDK) instead of __has_include(<mach-o/dyld_priv.h>).
        2. Rename webkitFirstSDKVersionWithInitConstructorSupport to
           firstSDKVersionWithInitConstructorSupport.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):

2016-04-27  Mark Lam  <mark.lam@apple.com>

        Restrict the availability of some JSC options to local debug builds only.
        https://bugs.webkit.org/show_bug.cgi?id=157058

        Reviewed by Geoffrey Garen.

        1. Each option will be given an availability flag.
        2. The functionOverrides and useDollarVM (along with its alias, enableDollarVM)
           will have "Restricted" availability.
        3. All other options will have “Normal” availability.
        4. Any options with "Restricted" availability will only be accessible if function
           allowRestrictedOptions() returns true.
        5. For now, allowRestrictedOptions() always returns false for release builds, and
           true for debug builds.

        If an option is "Restricted" and restricted options are not allowed, the VM will
        behave semantically as if that option does not exist at all:
        1. Option dumps will not show the option.
        2. Attempts to set the option will fail as if the option does not exist.

        Behind the scene, the option does exist, and is set to its default value
        (whatever that may be) once and only once on options initialization.

        * runtime/Options.cpp:
        (JSC::allowRestrictedOptions):
        (JSC::parse):
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::initialize):
        (JSC::Options::setOptionWithoutAlias):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        (JSC::Option::type):
        (JSC::Option::availability):
        (JSC::Option::isOverridden):

2016-04-27  Gavin Barraclough  <barraclough@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720
        <rdar://problem/25841790>

        Unreviewed rollout - caused memory regression.

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

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

        Follow up for r200113 on 32bit

        I forgot to do the 32bit counterpart of r200113.
        The test fails on the bots.

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

2016-04-27  Alberto Garcia  <berto@igalia.com>

        [GTK] Fails to build randomly when generating LLIntDesiredOffsets.h
        https://bugs.webkit.org/show_bug.cgi?id=155427

        Reviewed by Carlos Garcia Campos.

        If the build directory contains the -I string, the script that
        generates LLIntDesiredOffsets.h will confuse it with an option to
        declare an include directory.

        In order to avoid that we should only use the arguments that start
        with -I when extracting the list of include directories, instead
        of using the ones that simply contain that string.

        * offlineasm/parser.rb:

2016-04-27  Saam barati  <sbarati@apple.com>

        JSC should have an option to allow global const redeclarations
        https://bugs.webkit.org/show_bug.cgi?id=157006

        Reviewed by Geoffrey Garen.

        This patch implements an option that dictates whether
        const redeclarations at the program level will throw.
        This option defaults to true but allows users of JSC
        to set it to false. This option is per VM. This is needed
        for backwards compatibility with our old const implementation.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionShadowChickenFunctionsOnStack):
        (functionSetGlobalConstRedeclarationShouldNotThrow):
        (functionReadline):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::put):
        (JSC::JSGlobalLexicalEnvironment::isConstVariable):
        * runtime/JSGlobalLexicalEnvironment.h:
        (JSC::JSGlobalLexicalEnvironment::isEmpty):
        * runtime/VM.h:
        (JSC::VM::setGlobalConstRedeclarationShouldThrow):
        (JSC::VM::globalConstRedeclarationShouldThrow):
        * tests/stress/global-const-redeclaration-setting: Added.
        * tests/stress/global-const-redeclaration-setting-2.js: Added.
        (assert):
        * tests/stress/global-const-redeclaration-setting-3.js: Added.
        (assert):
        (catch):
        * tests/stress/global-const-redeclaration-setting-4.js: Added.
        (assert):
        (catch):
        * tests/stress/global-const-redeclaration-setting-5.js: Added.
        (assert):
        (catch):
        * tests/stress/global-const-redeclaration-setting.js: Added.
        (assert):
        * tests/stress/global-const-redeclaration-setting/first.js: Added.
        * tests/stress/global-const-redeclaration-setting/let.js: Added.
        * tests/stress/global-const-redeclaration-setting/second.js: Added.
        * tests/stress/global-const-redeclaration-setting/strict.js: Added.

2016-04-26  Michael Saboff  <msaboff@apple.com>

        [ES] Implement RegExp.prototype.@@replace and use it for String.prototype.replace
        https://bugs.webkit.org/show_bug.cgi?id=156562

        Reviewed by Filip Pizlo.

        Added builtins for String.prototype.replace as well as RegExp.prototype[Symbol.replace].

        The String.prototype.replace also has an intrinsic, StringPrototypeReplaceIntrinsic.
        This original intrinsic was copied to make StringPrototypeReplaceRegExpIntrinsic.
        The difference between the two intrinsics is that StringPrototypeReplaceIntrinsic has
        the same checks found in the new builtin hasObservableSideEffectsForStringReplace.
        We implement these primordial checks for StringPrototypeReplaceIntrinsic in two places.
        First, we do a trial check during ByteCode parsing time to see if the current
        RegExp.prototype properties have changed from the original.  If they have, we don't
        inline the intrinsic.  Later, in the fixup phase, we add nodes to the IR to emit the
        checks at runtime.

        The new intrinsic StringPrototypeReplaceRegExpIntrinsic is only available via the
        private @replaceUsingRegExp, which is called in the String.prototype.replace builtin.
        It is only called after hasObservableSideEffectsForStringReplace has been called

        Both of these intrinsics are needed, because the JS code containing String.replace() calls
        runs initially in the LLint and then the baseline JIT.  Even after the function tiers up
        to the DFG JIT, the inlining budget may not allow StringPrototypeReplaceIntrinsic to be inlined.
        Having StringPrototypeReplaceRegExpIntrinsic allows for the String.prototype.replace builtin to
        get reasonable performance before the other intrinsic is inlined or when it can't.

        * builtins/RegExpPrototype.js:
        (match):
        (getSubstitution):
        (replace):
        (search):
        (split):
        * builtins/StringPrototype.js:
        (repeat):
        (hasObservableSideEffectsForStringReplace):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (localeCompare):
        New builtins for String.prototype.replace and RegExp.prototype[Symbol.replace].

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
        (JSC::DFG::FixupPhase::tryAddStringReplacePrimordialChecks):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::getRegExpPrototypeProperty):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::getRegExpPrototypeProperty):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingRegExp):
        (JSC::stringProtoFuncReplaceUsingStringSearch):
        (JSC::operationStringProtoFuncReplaceGeneric):
        (JSC::stringProtoFuncReplace): Deleted.
        Added StringReplaceRegExp intrinsic.  Added checks for RegExp profiled arguments to StringReplace
        that mirror what is in hasObservableSideEffectsForStringReplace().  If we aren't able to add the
        checks, we OSR exit.  Add Graph::getPrimordialRegExpPrototypeProperty() as a helper to get the
        primordial values from RegExp.prototype.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Added @regExpPrototypeSymbolReplace and
        @hasObservableSideEffectsForStringReplace here instead og String.prototype so that we reduce the
        number of objects we have to traverse.

        * tests/es6.yaml: Changed expectations for the various replace related tests to passing.

        * tests/stress/regexp-replace-proxy.js:
        (assert):
        (let.getProxyNullExec.new.Proxy):
        (let.getSetProxyNullExec.new.Proxy):
        (get resetTracking):
        (let.getSetProxyMatches_comma.new.Proxy):
        (set get getSetProxyNullExec):
        (let.getSetProxyReplace_phoneNumber.new.Proxy):
        (set get getSetProxyMatches_comma):
        (let.getSetProxyReplaceUnicode_digit_nonGreedy.new.Proxy):
        (set get resetTracking):
        * tests/stress/string-replace-proxy.js:
        (assert):
        (let.getSetProxyReplace.new.Proxy.replace):
        New tests.

2016-04-26  Mark Lam  <mark.lam@apple.com>

        Gardening: speculative build fix.

        Not reviewed.

        * API/JSWrapperMap.mm:

2016-04-26  Mark Lam  <mark.lam@apple.com>

        Update the compatibility version check for the ObjC API's InitConstructorSupport to use dyld_get_program_sdk_version().
        https://bugs.webkit.org/show_bug.cgi?id=157048

        Reviewed by Geoffrey Garen.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):
        (getJSExportProtocol):

2016-04-26  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] GetByVal on Undecided use its children before its OSR Exit
        https://bugs.webkit.org/show_bug.cgi?id=157046

        Reviewed by Mark Lam.

        Very silly bug: GetByVal on Undecided uses its children before
        the speculationCheck(). If we fail the speculation, we have already
        lost how to recover the values.

        The existing tests did not catch this because we tier up to B3
        before such Exits happen. B3 has explicit liveness and did not suffer
        from this bug.
        The new test has a smaller warmup to exercise the OSR Exit in DFG
        instead of FTL.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * tests/stress/get-by-val-on-undecided-out-of-bounds.js: Added.
        (string_appeared_here.opaqueGetByValKnownArray):

2016-04-26  Skachkov Oleksandr  <gskachkov@gmail.com>

        calling super() a second time in a constructor should throw
        https://bugs.webkit.org/show_bug.cgi?id=151113

        Reviewed by Saam Barati.

        Currently, our implementation checks if 'super()' was called in a constructor more
        than once and raises a RuntimeError before the second call. According to the spec
        we need to raise an error just after the second super() is finished and before
        the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour.
        To implement this behavior this patch adds a new op code, op_is_empty, that is used
        to check if 'this' is empty.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsEmpty):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_empty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_empty):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/class-syntax-double-constructor.js: Added.

2016-04-26  Mark Lam  <mark.lam@apple.com>

        Changed jsc options title to be more descriptive.
        https://bugs.webkit.org/show_bug.cgi?id=157036

        Reviewed by Joseph Pecoraro.

        Let the title for --dumpOptions be "Modified JSC runtime options:" since it only
        dumps overridden options.  The title for --options will remain "All JSC runtime
        options:" since it dumps all all options with verbose detail.

        * jsc.cpp:
        (CommandLine::parseArguments):

2016-04-26  Oliver Hunt  <oliver@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720

        Unreviewed roll-in of this change. There is only one
        additional allocation involved in this logic, and that
        is a duplicate mapping.

        Either our tools are not report real memory usage
        or this revision is not responsible for the regression.

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

2016-04-26  Filip Pizlo  <fpizlo@apple.com>

        DFG backends shouldn't emit type checks at KnownBlah edges
        https://bugs.webkit.org/show_bug.cgi?id=157025

        Reviewed by Michael Saboff.
        
        This fixes a crash I found when browsing Bing maps with forceEagerCompilation. I include a
        100% repro test case.
        
        The issue is that our code still doesn't fully appreciate the devious implications of
        KnownBlah use kinds. Consider KnownCell for example. It means: "trust me, I know that this
        value will be a cell". You aren't required to provide a proof when you use KnownCell. Often,
        we use it as a result of a path-sensitive proof. The abstract interpreter is not
        path-sensitive, so AI will be absolutely sure that the KnownCell use might see a non-cell.
        This can lead to debug assertions (which this change removes) and it can lead to the backends
        emitting a type check. That type check can be pure evil if the node that has this edge does
        not have an exit origin. Such a node would have passed validation because the validater would
        have thought that the node cannot exit (after all, according to the IR semantics, there is no
        speculation at KnownCell).

        This comprehensively fixes the issue by recognizing that Foo(KnownCell:@x) means: I have
        already proved that by the time you start executing Foo, @x will already be a cell. I cannot
        tell you how I proved this but you can rely on it anyway. AI now takes advantage of this
        meaning and will always do filtering of KnownBlah edges regardless of whether the backend
        actually emits any type checks for those edges. Since the filtering runs before the backend,
        the backend will not emit any checks because it will know that the edge was already checked
        (by whatever mechanism we used when we made the edge KnownBlah).
        
        Note that it's good that we found this bug now. The DFG currently does very few
        sparse-conditional or path-sensitive optimizations, but it will probably do more in the
        future. The bug happens because GetByOffset and friends can achieve path-sensitive proofs via
        watchpoints on the inferred type. Normally, AI can follow along with this proof. But in the
        example program, and on Bing maps, we would GCSE one GetByOffset with another that had a
        weaker proven type. That turned out to be completely sound - between the two GetByOffset's
        there was a Branch to null check it. The inferred type of the second GetByOffset ended up
        knowing that it cannot be null because null only occurred in some structures but not others.
        If we added more sparse-conditional stuff to Branch, then AI would know how to follow along
        with the proof but it would also create more situations where we'd have a path-sensitive
        proof. So, it's good that we're now getting this right.

        * dfg/DFGAbstractInterpreter.h:
        (JSC::DFG::AbstractInterpreter::filterEdgeByUse):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEdges):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeKnownEdgeTypes):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        * tests/stress/path-sensitive-known-cell-crash.js: Added.
        (bar):
        (foo):

2016-04-26  Gavin Barraclough  <barraclough@apple.com>

        Enable separated heap by default on ios
        https://bugs.webkit.org/show_bug.cgi?id=156720

        Unreviewed rollout - caused memory regression.

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

2016-04-26  Joseph Pecoraro  <pecoraro@apple.com>

        Improve jsc --help and making sampling options
        https://bugs.webkit.org/show_bug.cgi?id=157015

        Reviewed by Saam Barati.

        Simplify sampling options to be easier to remember:

          * --reportSamplingProfilerData => --sample
          * --samplingProfilerTimingInterval => --sampleInterval

        Update the --help to mention --sample, and restore the behavior of
        --options outputing all possible options so you can discover which
        options are available.        

        * jsc.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        Improve help and modify option dumping.

        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        Rename the sampling interval option.

2016-04-26  Commit Queue  <commit-queue@webkit.org>

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

         It brokes the debug build (Requested by gskachkov on
        #webkit).

        Reverted changeset:

        "calling super() a second time in a constructor should throw"
        https://bugs.webkit.org/show_bug.cgi?id=151113
        http://trac.webkit.org/changeset/200083

2016-04-26  Skachkov Oleksandr  <gskachkov@gmail.com>

        calling super() a second time in a constructor should throw
        https://bugs.webkit.org/show_bug.cgi?id=151113

        Reviewed by Saam Barati.

        Currently, our implementation checks if 'super()' was called in a constructor more 
        than once and raises a RuntimeError before the second call. According to the spec 
        we need to raise an error just after the second super() is finished and before 
        the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
        To implement this behavior this patch adds a new op code, op_is_empty, that is used 
        to check if 'this' is empty.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsEmpty):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_empty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_empty):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/class-syntax-double-constructor.js: Added.

2016-04-25  Ryosuke Niwa  <rniwa@webkit.org>

        Remove the build flag for template elements
        https://bugs.webkit.org/show_bug.cgi?id=157022

        Reviewed by Daniel Bates.

        * Configurations/FeatureDefines.xcconfig:

2016-04-25  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Constant folding of UInt32ToNumber is incorrect
        https://bugs.webkit.org/show_bug.cgi?id=157011
        rdar://problem/25769641

        Reviewed by Geoffrey Garen.

        UInt32ToNumber should return the unsigned 32bit value of
        its child. The abstract interpreter fails to do that when handling
        Int52.

        None of the tests caught that because the bytecode generator already
        fold the operation if given a constant. If the constant is not visible
        from the bytecode generator (for example because it comes from an inlined call),
        then the abstract interpreter folding was producing invalid results.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * tests/stress/uint32-to-number-constant-folding.js: Added.
        (uint32ToNumberMinusOne):
        (uint32ToNumberMinusOnePlusInteger):
        (inlineMinusOne):
        (uint32ToNumberOnHiddenMinusOne):
        (uint32ToNumberOnHiddenMinusOnePlusInteger):
        (inlineLargeNegativeNumber1):
        (inlineLargeNegativeNumber2):
        (inlineLargeNegativeNumber3):
        (uint32ToNumberOnHiddenLargeNegativeNumber1):
        (uint32ToNumberOnHiddenLargeNegativeNumber2):
        (uint32ToNumberOnHiddenLargeNegativeNumber3):

2016-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>

        Heap corruption is detected when destructing JSGlobalObject
        https://bugs.webkit.org/show_bug.cgi?id=156831

        Reviewed by Mark Lam.

        WebKit uses CRT static library on Windows.  Each copy of the CRT
        library has its own heap manager, allocating memory in one CRT
        library and passing the pointer across a DLL boundary to be freed
        by a different copy of the CRT library is a potential cause for
        heap corruption.

          Potential Errors Passing CRT Objects Across DLL Boundaries
          <https://msdn.microsoft.com/en-us/library/ms235460(v=vs.140).aspx>

        JSGlobalObject::createRareDataIfNeeded is inlined but
        JSGlobalObject::~JSGlobalObject is not.  Then, the heap of
        allocating JSGlobalObjectRareData is WebKit.dll, but deallocating
        JavaScriptCore.dll.  Adding WTF_MAKE_FAST_ALLOCATED to
        JSGlobalObjectRareData ensures heap consistency of it.  WTF::Lock
        also needs WTF_MAKE_FAST_ALLOCATED because it is allocated from
        the inlined constructor of JSGlobalObjectRareData.

        Test: fast/dom/insertedIntoDocument-iframe.html

        * runtime/JSGlobalObject.h:
        Add WTF_MAKE_FAST_ALLOCATED to JSGlobalObjectRareData.

2016-04-25  Michael Saboff  <msaboff@apple.com>

        Crash using @tryGetById in DFG
        https://bugs.webkit.org/show_bug.cgi?id=156992

        Reviewed by Filip Pizlo.

        We need to spill live registers when compiling TryGetById in DFG.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileTryGetById):
        * tests/stress/regress-156992.js: New test.
        (tryMultipleGetByIds):
        (test):

2016-04-25  Saam barati  <sbarati@apple.com>

        We don't have to parse a function's parameters every time if the function is in the source provider cache
        https://bugs.webkit.org/show_bug.cgi?id=156943

        Reviewed by Filip Pizlo.

        This patch makes a few changes to make parsing inner functions
        faster.

        First, we were always parsing an inner function's parameter
        list using the templatized TreeBuiler. This means if our parent scope
        was building an AST, we ended up building AST nodes for the inner
        function's parameter list even though these nodes would go unused.
        This patch fixes that to *always* build an inner function's parameter
        list using the SyntaxChecker. (Note that this is consistent now with
        always building an inner function's body with a SyntaxChecker.)

        Second, we were always parsing an inner function's parameter list
        even if we had that function saved in the source provider cache.
        I've fixed that bug and made it so that we skip over the parsing 
        of a function's parameter list when it's in the source provider
        cache. We could probably enhance this in the future to skip
        over the entirety of a function starting at the "function"
        keyword or any other start of the function (depending on
        the function type: arrow function, method, etc).

        This patch also renames a few fields. First, I fixed a typo
        from "tocken" => "token" for a few field names. Secondly,
        I renamed a field that was called 'bodyStartColumn' to 
        'parametersStartColumn' because the field really held the
        parameter list's start column.

        I'm benchmarking this as a 1.5-2% octane/jquery speedup
        on a 15" MBP.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createMethodDefinition):
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        (JSC::Lexer::currentPosition):
        (JSC::Lexer::positionBeforeLastNewline):
        (JSC::Lexer::lastTokenLocation):
        (JSC::Lexer::setLastLineNumber):
        (JSC::Lexer::lastLineNumber):
        (JSC::Lexer::prevTerminator):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/Parser.h:
        (JSC::Scope::usedVariablesContains):
        (JSC::Scope::forEachUsedVariable):
        (JSC::Scope::useVariable):
        (JSC::Scope::copyCapturedVariablesToVector):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        * parser/ParserFunctionInfo.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::endFunctionToken):
        (JSC::SourceProviderCacheItem::usedVariables):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):

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

        Renaming SpecInt32, SpecInt52, MachineInt to SpecInt32Only, SpecInt52Only, AnyInt.
        https://bugs.webkit.org/show_bug.cgi?id=156941

        Reviewed by Filip Pizlo.

        While looking at https://bugs.webkit.org/show_bug.cgi?id=153431, it was decided
        that SpecInt32Only, SpecInt52Only, and AnyInt would be better names for
        SpecInt32, SpecInt52, and MachineInt.  Let's do a bulk rename.

        This is only a renaming patch, and deletion of a piece of unused code.  There are
        no semantic changes.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromValue):
        (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
        (JSC::typeOfDoubleNegation):
        (JSC::typeOfDoubleRounding):
        * bytecode/SpeculatedType.h:
        (JSC::isInt32Speculation):
        (JSC::isInt32OrBooleanSpeculation):
        (JSC::isInt32SpeculationForArithmetic):
        (JSC::isInt32OrBooleanSpeculationForArithmetic):
        (JSC::isInt32OrBooleanSpeculationExpectingDefined):
        (JSC::isInt52Speculation):
        (JSC::isAnyIntSpeculation):
        (JSC::isAnyIntAsDoubleSpeculation):
        (JSC::isDoubleRealSpeculation):
        (JSC::isMachineIntSpeculation): Deleted.
        (JSC::isInt52AsDoubleSpeculation): Deleted.
        (JSC::isIntegerSpeculation): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::fixTypeForRepresentation):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::resultType):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::validateType):
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToThis):
        (JSC::DFG::FixupPhase::observeUseKindOnNode):
        (JSC::DFG::FixupPhase::fixIntConvertingEdge):
        (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
        (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
        (JSC::DFG::FixupPhase::truncateConstantToInt32):
        (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
        (JSC::DFG::FixupPhase::prependGetArrayLength):
        (JSC::DFG::FixupPhase::fixupChecksInBlock):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateInt32):
        (JSC::DFG::Graph::addShouldSpeculateAnyInt):
        (JSC::DFG::Graph::binaryArithShouldSpeculateInt32):
        (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt):
        (JSC::DFG::Graph::unaryArithShouldSpeculateInt32):
        (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt):
        (JSC::DFG::Graph::addShouldSpeculateMachineInt): Deleted.
        (JSC::DFG::Graph::binaryArithShouldSpeculateMachineInt): Deleted.
        (JSC::DFG::Graph::unaryArithShouldSpeculateMachineInt): Deleted.
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToIdentityOn):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::asNumber):
        (JSC::DFG::Node::isAnyIntConstant):
        (JSC::DFG::Node::asAnyInt):
        (JSC::DFG::Node::isBooleanConstant):
        (JSC::DFG::Node::shouldSpeculateInt32OrBooleanExpectingDefined):
        (JSC::DFG::Node::shouldSpeculateAnyInt):
        (JSC::DFG::Node::shouldSpeculateDouble):
        (JSC::DFG::Node::shouldSpeculateNumber):
        (JSC::DFG::Node::isMachineIntConstant): Deleted.
        (JSC::DFG::Node::asMachineInt): Deleted.
        (JSC::DFG::Node::shouldSpeculateMachineInt): Deleted.
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::OSREntryData::dumpInContext):
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSREntry.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::SSALoweringPhase::handleNode):
        (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        (JSC::DFG::SpeculativeJIT::speculateInt32):
        (JSC::DFG::SpeculativeJIT::speculateNumber):
        (JSC::DFG::SpeculativeJIT::speculateMisc):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::isKnownInteger):
        (JSC::DFG::SpeculativeJIT::isKnownCell):
        (JSC::DFG::SpeculativeJIT::isKnownNotInteger):
        (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
        (JSC::DFG::SpeculativeJIT::isKnownNotCell):
        (JSC::DFG::SpeculativeJIT::isKnownNotOther):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::blessBoolean):
        (JSC::DFG::SpeculativeJIT::convertAnyInt):
        (JSC::DFG::SpeculativeJIT::speculateAnyInt):
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepAnyInt):
        (JSC::DFG::SpeculativeJIT::convertMachineInt): Deleted.
        (JSC::DFG::SpeculativeJIT::speculateMachineInt): Deleted.
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepMachineInt): Deleted.
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isNumerical):
        (JSC::DFG::isDouble):
        * dfg/DFGValidate.cpp:
        * dfg/DFGVariableAccessData.cpp:
        (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
        (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
        (JSC::DFG::VariableAccessData::flushFormat):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
        (JSC::FTL::DFG::LowerDFGToB3::compileInt52Rep):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToB3::lowInt32):
        (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isInt32):
        (JSC::FTL::DFG::LowerDFGToB3::isNotInt32):
        (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToB3::speculate):
        (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
        (JSC::FTL::DFG::LowerDFGToB3::speculateAnyInt):
        (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepReal):
        (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepAnyInt):
        (JSC::FTL::DFG::LowerDFGToB3::speculateMachineInt): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepMachineInt): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_type):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_type):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::isInt52):
        (JSC::JSValue::isAnyInt):
        (JSC::JSValue::asAnyInt):
        (JSC::JSValue::isMachineInt): Deleted.
        (JSC::JSValue::asMachineInt): Deleted.
        * runtime/RuntimeType.cpp:
        (JSC::runtimeTypeForValue):
        (JSC::runtimeTypeAsString):
        * runtime/RuntimeType.h:
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::dumpTypes):
        (JSC::TypeSet::displayName):
        (JSC::TypeSet::inspectorTypeSet):
        (JSC::TypeSet::toJSONString):

2016-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Optimize JSON.parse string fast path
        https://bugs.webkit.org/show_bug.cgi?id=156953

        Reviewed by Mark Lam.

        This patch further optimizes the string parsing fast path.
        Previously, we generated the WTF::String to hold the ownership of the token's string.
        And always copied the token in LiteralParser side.
        Instead, we hold the ownership of the token String by the StringBuilder in LiteralParser::Lexer,
        and remove the processing in the string parsing fast path.
        This patch gives us stable 1 - 2.5% improvement in Kraken json-parse-financial.

                                       Baseline                  Modified

        json-parse-financial        41.383+-0.248      ^      40.894+-0.189         ^ definitely 1.0120x faster

        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::tryJSONPParse):
        (JSC::LiteralParser<CharType>::Lexer::lex):
        (JSC::LiteralParser<CharType>::Lexer::lexStringSlow):
        (JSC::LiteralParser<CharType>::parse):
        (JSC::LiteralParser<CharType>::Lexer::lexString): Deleted.
        * runtime/LiteralParser.h:
        (JSC::LiteralParser::tryLiteralParse):
        (JSC::LiteralParser::Lexer::currentToken):
        (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::LiteralParserTokenPtr):
        (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::operator->):

2016-04-24  Filip Pizlo <fpizlo@apple.com> and Andy VanWagoner <thetalecrafter@gmail.com>

        [INTL] Implement String.prototype.localeCompare in ECMA-402
        https://bugs.webkit.org/show_bug.cgi?id=147607

        Reviewed by Darin Adler.
        
        Part of this change is just rolling 194394 back in.
        
        The other part is making that not a regression on CDjs. Other than the fact that it uses
        bound functions, the problem with this new localeCompare implementation is that it uses
        the arguments object. It uses it in a way that *seems* like ArgumentsEliminationPhase
        ought to handle, but to my surprise it didn't:
        
        - If we have a ForceExit GetByVal on the arguments object, we would previously assume that
          it escaped. That's false since we just exit at ForceExit. On the other hand we probably
          should be pruning unreachable paths before we get here, but that's a separate issue. I
          don't want to play with phase order right now.
        
        - If we have a OutOfBounds GetByVal on the arguments object, then the best that would
          previously happen is that we'd compile it into an in-bounds arguments access. That's quite
          bad, as Andy's localeCompare illustrates: it uses out-of-bounds access on the arguments
          object to detect if an argument was passed. This change introduces an OutOfBounds version
          of GetMyArgumentByVal for this purpose.
        
        This change required registering sane chain watchpoints. In the process, I noticed that the
        old way of doing it had a race condition: we might register watchpoints for the structure
        that had become insane. This change introduces a double-checking idiom that I believe works
        because once the structure becomes insane it can't go back to sane and watchpoints
        registration already involves executing the hardest possible fences.

        * builtins/StringPrototype.js:
        (repeat):
        (localeCompare):
        (search):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        * ftl/FTLTypedPointer.h:
        (JSC::FTL::TypedPointer::TypedPointer):
        (JSC::FTL::TypedPointer::operator bool):
        (JSC::FTL::TypedPointer::heap):
        (JSC::FTL::TypedPointer::operator!): Deleted.
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

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

        Unreviewed, unbreak cloop.

        * runtime/VM.cpp:
        (JSC::VM::getHostFunction):

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

        Speed up bound functions a bit
        https://bugs.webkit.org/show_bug.cgi?id=156889

        Reviewed by Saam Barati.
        
        Bound functions are hard to optimize because JSC doesn't have a good notion of non-JS code
        that does JS-ey things like make JS calls. What I mean by "non-JS code" is code that did not
        originate from JS source. A bound function does a highly polymorphic call to the target
        stored in the JSBoundFunction. Prior to this change, we represented it as native code that
        used the generic native->JS call API. That's not cheap.
        
        We could model bound functions using a builtin, but it's not clear that this would be easy
        to grok, since so much of the code would have to access special parts of the JSBoundFunction
        type. Doing it that way might solve the performance problems but it would mean extra work to
        arrange for the builtin to have speedy access to the call target, the bound this, and the
        bound arguments. Also, optimizing bound functions that way would mean that bound function
        performance would be gated on the performance of a bunch of other things in our system. For
        example, we'd want this polymorphic call to be handled like the funnel that it is: if we're
        compiling the bound function's outgoing call with no context then we should compile it as
        fully polymorphic but we can let it assume basic sanity like that the callee is a real
        function; but if we're compiling the call with any amount of calling context then we want to
        use normal call IC's.
        
        Since the builtin path wouldn't lead to a simpler patch and since I think that the VM will
        benefit in the long run from using custom handling for bound functions, I kept the native
        code and just added Intrinsic/thunk support.
        
        This just adds an Intrinsic for bound function calls where the JSBoundFunction targets a
        JSFunction instance and has no bound arguments (only bound this). This intrinsic is
        currently only implemented as a thunk and not yet recognized by the DFG bytecode parser.

        I needed to loosen some restrictions to do this. For one, I was really tired of our bad use
        of ENABLE(JIT) conditionals, which made it so that any serious client of Intrinsics would
        have to have #ifdefs. Really what should happen is that if the JIT is not enabled then we
        just ignore intrinsics. Also, the code was previously assuming that having a native
        constructor and knowing the Intrinsic for your native call were mutually exclusive. This
        change makes it possible to have a native executable that has a custom function, custom
        constructor, and an Intrinsic.
        
        This is a >4x speed-up on bound function calls with no bound arguments.

        In the future, we should teach the DFG Intrinsic handling to deal with bound functions and
        we should teach the inliner (and ByteCodeParser::handleCall() in general) how to deal with
        the function call inside the bound function. That would be super awesome.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::timesPtr):
        (JSC::AbstractMacroAssembler::Address::withOffset):
        (JSC::AbstractMacroAssembler::BaseIndex::BaseIndex):
        (JSC::MacroAssemblerType>::Address::indexedBy):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::storeCell):
        (JSC::AssemblyHelpers::loadCell):
        (JSC::AssemblyHelpers::storeValue):
        (JSC::AssemblyHelpers::emitSaveCalleeSaves):
        (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters):
        (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
        (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::ctiNativeTailCall):
        (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags):
        (JSC::JITThunks::ctiStub):
        (JSC::JITThunks::hostFunctionStub):
        (JSC::JITThunks::clearHostFunctionStubs):
        * jit/JITThunks.h:
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
        (JSC::SpecializedThunkJIT::tagReturnAsInt32):
        (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters): Deleted.
        (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters): Deleted.
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::nativeCallGenerator):
        (JSC::nativeTailCallGenerator):
        (JSC::nativeTailCallWithoutSavedTagsGenerator):
        (JSC::nativeConstructGenerator):
        (JSC::randomThunkGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * jit/ThunkGenerators.h:
        * runtime/Executable.cpp:
        (JSC::NativeExecutable::create):
        (JSC::NativeExecutable::destroy):
        (JSC::NativeExecutable::createStructure):
        (JSC::NativeExecutable::finishCreation):
        (JSC::NativeExecutable::NativeExecutable):
        (JSC::ScriptExecutable::ScriptExecutable):
        * runtime/Executable.h:
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeGetterCompare):
        * runtime/Intrinsic.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::boundThisNoArgsFunctionCall):
        (JSC::boundFunctionCall):
        (JSC::boundThisNoArgsFunctionConstruct):
        (JSC::boundFunctionConstruct):
        (JSC::getBoundFunctionStructure):
        (JSC::JSBoundFunction::create):
        (JSC::JSBoundFunction::customHasInstance):
        (JSC::JSBoundFunction::JSBoundFunction):
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::targetFunction):
        (JSC::JSBoundFunction::boundThis):
        (JSC::JSBoundFunction::boundArgs):
        (JSC::JSBoundFunction::createStructure):
        (JSC::JSBoundFunction::offsetOfTargetFunction):
        (JSC::JSBoundFunction::offsetOfBoundThis):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::lookUpOrCreateNativeExecutable):
        (JSC::JSFunction::create):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        (JSC::VM::getHostFunction):
        * runtime/VM.h:
        (JSC::VM::getCTIStub):
        (JSC::VM::exceptionOffset):

2016-04-22  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r199866
        https://bugs.webkit.org/show_bug.cgi?id=156892

        Reviewed by Darin Adler.

        * runtime/MathCommon.cpp: Follow up to r199913. Remove 'include cmath' in cpp file.

2016-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        [JSC] Optimize number parsing and string parsing in LiteralParser
        https://bugs.webkit.org/show_bug.cgi?id=156896

        Reviewed by Mark Lam.

        This patch aim to improve JSON.parse performance. Major 2 optimizations are included.

        1. Change `double result` to `int32_t result` in integer parsing case.
        We already have the optimized path for integer parsing, when it's digits are less than 10.
        At that case, the maximum number is 999999999, and the minimum number is -99999999.
        The both are in range of Int32. So We can use int32_t for accumulation instead of double.

        2. Add the string parsing fast / slow cases.
        We add the fast case for string parsing, which does not include any escape sequences.

        Both optimizations improve Kraken json-parse-financial, roughly 3.5 - 4.5%.

        json-parse-financial        49.128+-1.589             46.979+-0.912           might be 1.0457x faster

        * runtime/LiteralParser.cpp:
        (JSC::isJSONWhiteSpace):
        (JSC::isSafeStringCharacter):
        (JSC::LiteralParser<CharType>::Lexer::lexString):
        (JSC::LiteralParser<CharType>::Lexer::lexStringSlow):
        (JSC::LiteralParser<CharType>::Lexer::lexNumber):
        * runtime/LiteralParser.h:

2016-04-22  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Source directives lost when using Function constructor repeatedly
        https://bugs.webkit.org/show_bug.cgi?id=156863
        <rdar://problem/25861064>

        Reviewed by Geoffrey Garen.

        Source directives (sourceURL and sourceMappingURL) are normally accessed through
        the SourceProvider and normally set when the script is parsed. However, when a
        CodeCache lookup skips parsing, the new SourceProvider never gets the directives
        (sourceURL/sourceMappingURL). This patch stores the directives on the UnlinkedCodeBlock
        and UnlinkedFunctionExecutable when entering the cache, and copies to the new providers
        when the cache is used.

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::sourceURLDirective):
        (JSC::UnlinkedCodeBlock::sourceMappingURLDirective):
        (JSC::UnlinkedCodeBlock::setSourceURLDirective):
        (JSC::UnlinkedCodeBlock::setSourceMappingURLDirective):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceProvider.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        Store directives on the unlinked code block / executable when adding
        to the cache, so they can be used to update new providers when the
        cache gets used.

        * runtime/JSGlobalObject.cpp:
        Add needed header after CodeCache header cleanup.

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

        javascript jit bug affecting Google Maps.
        https://bugs.webkit.org/show_bug.cgi?id=153431

        Reviewed by Filip Pizlo.

        The issue was due to the abstract interpreter wrongly marking the type of the
        value read from the Uint3Array as SpecInt52, which precludes it from being an
        Int32.  This proves to be false, and the generated code failed to handle the case
        where the read value is actually an Int32.

        The fix is to have the abstract interpreter use SpecMachineInt instead of
        SpecInt52.

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

2016-04-22  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] PredictionPropagation should not be in the top 5 heaviest phases
        https://bugs.webkit.org/show_bug.cgi?id=156891

        Reviewed by Mark Lam.

        In DFG, PredictionPropagation is often way too high in profiles.
        It is a simple phase, it should not be that hot.

        Most of the time is spent accessing memory. This patch attempts
        to reduce that.

        First, propagate() is split in processInvariants() and propagates().
        The step processInvariants() sets all the types for nodes for which
        the type does not depends on other nodes.

        Adding processInvariants() lowers two hotspot inside PredictionPropagation:
        speculationFromValue() and setPrediction().

        Next, to avoid touching all the nodes at every operation, we keep
        track of the nodes that actually need propagate().
        The vector m_dependentNodes keeps the list of those nodes and propagate()
        only need to process them at each phase.

        This is a smaller gain because growing m_dependentNodes negates
        some of the gains.

        On 3d-cube, this moves PredictionPropagation from fifth position
        to ninth. A lot of the remaining overhead is caused by double-voting
        and cannot be fixed by moving stuff around.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagateToFixpoint): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagateForward): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagateBackward): Deleted.
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): Deleted.
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): Deleted.
        (JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions): Deleted.

2016-04-22  Geoffrey Garen  <ggaren@apple.com>

        super should be available in object literals
        https://bugs.webkit.org/show_bug.cgi?id=156933

        Reviewed by Saam Barati.

        When we originally implemented classes, super seemed to be a class-only
        feature. But the final spec says it's available in object literals too.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode): Having 'super' and being a class
        property are no longer synonymous, so we track two separate variables.

        (JSC::PropertyListNode::emitPutConstantProperty): Being inside the super
        branch no longer guarantees that you're a class property, so we decide
        our attributes and our function name dynamically.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArguments):
        (JSC::ASTBuilder::createArgumentsList):
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::createPropertyList): Pass through state to indicate
        whether we're a class property, since we can't infer it from 'super'
        anymore.

        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode): See ASTBuilder.h.

        * parser/Nodes.h:
        (JSC::PropertyNode::expressionName):
        (JSC::PropertyNode::name):
        (JSC::PropertyNode::type):
        (JSC::PropertyNode::needsSuperBinding):
        (JSC::PropertyNode::isClassProperty):
        (JSC::PropertyNode::putType): See ASTBuilder.h.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parseMemberExpression): I made these error
        messages generic because it is no longer practical to say concise things
        about the list of places you can use super.

        * parser/Parser.h:

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createArgumentsList):
        (JSC::SyntaxChecker::createProperty):
        (JSC::SyntaxChecker::appendExportSpecifier):
        (JSC::SyntaxChecker::appendConstDecl):
        (JSC::SyntaxChecker::createGetterOrSetterProperty): Updated for
        interface change.

        * tests/stress/generator-with-super.js:
        (test):
        * tests/stress/modules-syntax-error.js:
        * tests/stress/super-in-lexical-scope.js:
        (testSyntaxError):
        (testSyntaxError.test):
        * tests/stress/tagged-templates-syntax.js: Updated for error message
        changes. See Parser.cpp.

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

        ASSERT(m_stack.last().isTailDeleted) at ShadowChicken.cpp:127 inspecting the inspector
        https://bugs.webkit.org/show_bug.cgi?id=156930

        Reviewed by Joseph Pecoraro.
        
        The loop that prunes the stack from the top should preserve the invariant that the top frame
        cannot be tail-deleted.

        * interpreter/ShadowChicken.cpp:
        (JSC::ShadowChicken::update):

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

        Attempt to fix the CLoop after r199866

        * runtime/MathCommon.h:

2016-04-22  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Integer Multiply of a number by itself does not need negative zero support
        https://bugs.webkit.org/show_bug.cgi?id=156895

        Reviewed by Saam Barati.

        You cannot produce negative zero by squaring an integer.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        Minor codegen fixes:
        -Use the right form of multiply for ARM.
        -Use a sign-extended 32bit immediates, that's the one with fast forms
         in the MacroAssembler.

2016-04-21  Darin Adler  <darin@apple.com>

        Follow-on to the build fix.

        * runtime/MathCommon.h: Use the C++ std namespace version of the
        frexp function too.

2016-04-21  Joonghun Park  <jh718.park@samsung.com>

        [JSC] Fix build break since r199866. Unreviewed.
        https://bugs.webkit.org/show_bug.cgi?id=156892

        * runtime/MathCommon.h: Add namespace std to isnormal invoking.

2016-04-21  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add primitive String support to compare operators
        https://bugs.webkit.org/show_bug.cgi?id=156783

        Reviewed by Geoffrey Garen.

        Just the basics.
        We should eventually inline some of the simplest cases.

        This is a 2% improvement on Longspider. It is unfortunately neutral
        for Sunspider on my machine because most of the comparison are from
        baseline.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStringCompare):
        (JSC::DFG::SpeculativeJIT::compileStringIdentCompare):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareLess):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareLessEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareGreater):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareGreaterEq):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::callWithoutSideEffects):
        * jit/JITOperations.h:
        * tests/stress/string-compare.js: Added.
        (makeRope):
        (makeString):
        (let.operator.of.operators.eval.compareStringIdent):
        (let.operator.of.operators.compareStringString):
        (let.operator.of.operators.compareStringIdentString):
        (let.operator.of.operators.compareStringStringIdent):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.eval):

2016-04-21  Benjamin Poulain  <bpoulain@webkit.org>

        [JSC] Commute FDiv-by-constant into FMul-by-reciprocal when it is safe
        https://bugs.webkit.org/show_bug.cgi?id=156871

        Reviewed by Filip Pizlo.

        FMul is significantly faster than FDiv.
        For example, on Haswell, FMul has a latency of 5, a throughput of 1
        while FDiv has latency 10-24, throughput 8-18.

        Fortunately for us, Sunspider and Kraken have plenty of division
        by a simple power of 2 constant. Those are just exponent operations
        and can be easily reversed to use FMul instead of FDiv.

        LLVM does something similar in InstCombine.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * jit/JITDivGenerator.cpp:
        (JSC::JITDivGenerator::loadOperand):
        (JSC::JITDivGenerator::generateFastPath):
        * jit/SnippetOperand.h:
        (JSC::SnippetOperand::asConstNumber):
        * runtime/MathCommon.h:
        (JSC::safeReciprocalForDivByConst):
        * tests/stress/floating-point-div-to-mul.js: Added.
        (opaqueDivBy2):
        (opaqueDivBy3):
        (opaqueDivBy4):
        (opaqueDivBySafeMaxMinusOne):
        (opaqueDivBySafeMax):
        (opaqueDivBySafeMaxPlusOne):
        (opaqueDivBySafeMin):
        (opaqueDivBySafeMinMinusOne):
        (i.catch):
        (i.result.opaqueDivBySafeMin.valueOf):

2016-04-21  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Improve the absThunkGenerator() for 64bit
        https://bugs.webkit.org/show_bug.cgi?id=156888

        Reviewed by Michael Saboff.

        A few tests spend a lot of time in this abs() with double argument.

        This patch adds custom handling for the JSValue64 representation.
        In particular:
        -Do not load the value twice. Unbox the GPR if it is not an Int32.
        -Deal with IntMin inline instead of falling back to the C function call.
        -Box the values ourself to avoid a duplicate function tail and return.

        * jit/ThunkGenerators.cpp:
        (JSC::absThunkGenerator):

2016-04-21  Saam barati  <sbarati@apple.com>

        LLInt CallSiteIndex off by 1
        https://bugs.webkit.org/show_bug.cgi?id=156886

        Reviewed by Benjamin Poulain.

        I think was done for historical reasons but isn't needed anymore.

        * llint/LLIntSlowPaths.cpp:

2016-04-21  Keith Miller  <keith_miller@apple.com>

        FTL should handle exceptions in operationInOptimize
        https://bugs.webkit.org/show_bug.cgi?id=156885

        Reviewed by Michael Saboff.

        For some reasone we didn't handle any exceptions in "in" when we called
        operationInOptimize in the FTL.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        * ftl/FTLPatchpointExceptionHandle.h: Add comments explaining which
        function to use for different exception types.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionNoFTL):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::setNeverFTLOptimize):
        (JSC::ScriptExecutable::neverFTLOptimize):
        * tests/stress/in-ftl-exception-check.js: Added.
        (foo):
        (bar):
        (catch):

2016-04-21  Filip Pizlo  <fpizlo@apple.com>

        JSC virtual call thunk shouldn't do a structure->classInfo lookup
        https://bugs.webkit.org/show_bug.cgi?id=156874

        Reviewed by Keith Miller.
        
        This lookup was unnecessary because we can just test the inlined type field.

        But also, this meant that we were exempting JSBoundFunction from the virtual call optimization.
        That's pretty bad.

        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

2016-04-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: sourceMappingURL not loaded in generated script
        https://bugs.webkit.org/show_bug.cgi?id=156022
        <rdar://problem/25438595>

        Reviewed by Geoffrey Garen.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
        Synthetic CallFrames for native code will not have script identifiers.

        * inspector/ScriptCallFrame.cpp:
        (Inspector::ScriptCallFrame::ScriptCallFrame):
        (Inspector::ScriptCallFrame::isEqual):
        (Inspector::ScriptCallFrame::buildInspectorObject):
        * inspector/ScriptCallFrame.h:
        * inspector/protocol/Console.json:
        Include the script identifier in ScriptCallFrame so we can correlate this
        to the exactly script, even if there isn't a URL. The Script may have a
        sourceURL, so the Web Inspector frontend may decide to show / link to it.

        * inspector/ScriptCallStackFactory.cpp:
        (Inspector::CreateScriptCallStackFunctor::operator()):
        (Inspector::createScriptCallStackFromException):
        Include SourceID when we have it.

        * interpreter/Interpreter.cpp:
        (JSC::GetStackTraceFunctor::operator()):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::sourceID):
        * interpreter/StackVisitor.h:
        Access the SourceID when we have it.

2016-04-21  Saam barati  <sbarati@apple.com>

        Lets do less locking of symbol tables in the BytecodeGenerator where we don't have race conditions
        https://bugs.webkit.org/show_bug.cgi?id=156821

        Reviewed by Filip Pizlo.

        The BytecodeGenerator allocates all the SymbolTables that it uses.
        This is before any concurrent compiler thread can use that SymbolTable.
        This means we don't actually need to lock for any operations of the
        SymbolTable. This patch makes this change by removing all locking.
        To do this, I've introduced a new constructor for ConcurrentJITLocker
        which implies no locking is necessary. You instantiate such a ConcurrentJITLocker like so:
        `ConcurrentJITLocker locker(ConcurrentJITLocker::NoLockingNecessary);`

        This patch also removes all uses of Strong<SymbolTable> from the bytecode
        generator and instead wraps bytecode generation in a DeferGC.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::instantiateLexicalVariables):
        (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKind):
        (JSC::BytecodeGenerator::superBinding):
        (JSC::BytecodeGenerator::generate):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/ConcurrentJITLock.h:
        (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase):
        (JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase):
        (JSC::ConcurrentJITLocker::ConcurrentJITLocker):

2016-04-21  Saam barati  <sbarati@apple.com>

        Remove some unnecessary RefPtrs in the parser
        https://bugs.webkit.org/show_bug.cgi?id=156865

        Reviewed by Filip Pizlo.

        The IdentifierArena or the SourceProviderCacheItem will own these UniquedStringImpls
        while we are using them. There is no need for us to reference count them.

        This might be a 0.5% speedup on octane code-load.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * parser/Parser.h:
        (JSC::Scope::setIsLexicalScope):
        (JSC::Scope::isLexicalScope):
        (JSC::Scope::closedVariableCandidates):
        (JSC::Scope::declaredVariables):
        (JSC::Scope::lexicalVariables):
        (JSC::Scope::finalizeLexicalEnvironment):
        (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::getCapturedVars):
        (JSC::Scope::setStrictMode):
        (JSC::Scope::isValidStrictMode):
        (JSC::Scope::shadowsArguments):
        (JSC::Scope::copyCapturedVariablesToVector):
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::usedVariables):
        (JSC::SourceProviderCacheItem::~SourceProviderCacheItem):
        (JSC::SourceProviderCacheItem::create):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
        (JSC::SourceProviderCacheItem::writtenVariables): Deleted.

2016-04-21  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess adds sizeof(CallerFrameAndPC) rather than subtracting it when calculating stack height
        https://bugs.webkit.org/show_bug.cgi?id=156872

        Reviewed by Geoffrey Garen.
        
        The code that added sizeof(CallerFrameAndPC) emerged from a bad copy-paste in r189586. That was
        the revision that created the PolymorphicAccess class. It moved code for generating a
        getter/setter call from Repatch.cpp to PolymorphicAccess.cpp. You can see the code doing a
        subtraction here:
        
            http://trac.webkit.org/changeset/189586/trunk/Source/JavaScriptCore/jit/Repatch.cpp
        
        This makes the world right again.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateImpl):

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

        Build warning: CODE_SIGN_ENTITLEMENTS specified without specifying CODE_SIGN_IDENTITY
        https://bugs.webkit.org/show_bug.cgi?id=156862

        Reviewed by Joseph Pecoraro.

        * Configurations/Base.xcconfig: Specify the ad hoc signing identity by
        default. See <http://trac.webkit.org/changeset/143544>.

2016-04-21  Andy Estes  <aestes@apple.com>

        REGRESSION (r199734): WebKit crashes loading numerous websites in iOS Simulator
        https://bugs.webkit.org/show_bug.cgi?id=156842

        Reviewed by Daniel Bates.

        Disable separated heap on iOS Simulator.

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

2016-04-21  Michael Saboff  <msaboff@apple.com>

        Align RegExp[@@match] with other @@ methods
        https://bugs.webkit.org/show_bug.cgi?id=156832

        Reviewed by Mark Lam.

        Various changes to align the RegExp[@@match] with [@@search] and [@@split].

        Made RegExp.prototype.@exec a hidden property on the global object and
        called it @regExpBuiltinExec to match the name it has in the standard.
        Changed all places that used the old name to use the new one.

        Made the match fast path function, which used to be call @match, to be called
        @regExpMatchFast and put it on the global object.  Changed it to also handle
        expressions both with and without the global flag.  Refactored the builtin
        @match accordingly.

        Added the builtin function @hasObservableSideEffectsForRegExpMatch() that
        checks to see if we can use the fast path of if we need the explicit version.

        Put the main RegExp functions @match, @search and @split in alphabetical
        order in RegExpPrototype.js.  Did the same for @match, @repeat, @search and 
        @split in StringPrototype.js.
        
        * builtins/RegExpPrototype.js:
        (regExpExec):
        (hasObservableSideEffectsForRegExpMatch): New.
        (match):
        (search):
        (hasObservableSideEffectsForRegExpSplit):
        Reordered in the file and updated to use @regExpBuiltinExec.

        * builtins/StringPrototype.js:
        (match):
        (repeatSlowPath):
        (repeat):
        (search):
        (split):
        Reordered functions in the file.

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setGlobalThis):
        (JSC::getById):
        (JSC::getGetterById):
        (JSC::JSGlobalObject::init):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncMatchFast):
        (JSC::regExpProtoFuncMatchPrivate): Deleted.
        * runtime/RegExpPrototype.h:

2016-04-20  Geoffrey Garen  <ggaren@apple.com>

        JavaScriptCore garbage collection is missing an autorelease pool
        https://bugs.webkit.org/show_bug.cgi?id=156751
        <rdar://problem/25787802>

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::releaseDelayedReleasedObjects): Add an autorelease pool to
        catch autoreleases when we call out to arbitrary ObjC code.

        We use the C interface here because this is not an ObjC compilation unit.

2016-04-20  Filip Pizlo  <fpizlo@apple.com>

        DFG del_by_id support forgets to set()
        https://bugs.webkit.org/show_bug.cgi?id=156830

        Reviewed by Saam Barati.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * tests/stress/dfg-del-by-id.js: Added.

2016-04-20  Saam barati  <sbarati@apple.com>

        Improve sampling profiler CLI JSC tool
        https://bugs.webkit.org/show_bug.cgi?id=156824

        Reviewed by Mark Lam.

        This patch enhances the Sampling Profiler CLI tool from the JSC shell
        to display the JITType of a particular CodeBlock. Because this happens
        once we process a log of stack frames, the data for a particular frame
        being in LLInt vs. Baseline could be wrong. For example, we may have taken 
        a stack trace of a CodeBlock while it was executing in the LLInt, then 
        it tiers up to the baseline, then we process the log. We will show such CodeBlocks
        as being in the baseline JIT. We could be smarter about this in the future if
        it turns out to truly be a problem.

        This patch also adds a 'samplingProfilerTimingInterval' JSC option to allow
        CLI users to control the sleep time between stack traces.

        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):

2016-04-20  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] DFG should not generate two jumps when the target of DoubleBranch is the next block  
        https://bugs.webkit.org/show_bug.cgi?id=156815

        Reviewed by Mark Lam.

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

2016-04-20  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG
        https://bugs.webkit.org/show_bug.cgi?id=155164

        Reviewed by Mark Lam.

        Every "inc" in loop was looking like this:
            move rX, rY
            inc rY
            jo 0x230f4a200580

        This patch add register Reuse to that case to remove
        the extra "move".

        * dfg/DFGOSRExit.h:
        (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
        (JSC::DFG::SpeculationRecovery::immediate):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        * tests/stress/arith-add-with-constant-overflow.js: Added.
        (opaqueAdd):

2016-04-20  Saam barati  <sbarati@apple.com>

        We don't need a manual stack for an RAII object when the machine's stack will do just fine
        https://bugs.webkit.org/show_bug.cgi?id=156807

        Reviewed by Mark Lam.

        We kept around a vector for an RAII object to maintain
        the recursive nature of having these RAII objects on
        the stack as the parser recursed. Instead, the RAII object
        can just have a field with the value it wants to restore
        and use the machine's stack.

        This is a 1% octane code-load progression.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::BinaryExprContext::BinaryExprContext):
        (JSC::SyntaxChecker::BinaryExprContext::~BinaryExprContext):
        (JSC::SyntaxChecker::UnaryExprContext::UnaryExprContext):
        (JSC::SyntaxChecker::UnaryExprContext::~UnaryExprContext):
        (JSC::SyntaxChecker::operatorStackPop):

2016-04-20  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r190289): Spin trying to view/sign in to hbogo.com
        https://bugs.webkit.org/show_bug.cgi?id=156765

        Reviewed by Saam Barati.

        In the op_get_by_val case, we were holding the lock on a profiled CodeBlock
        when we call into handleGetById(). Changed to drop the lock before calling
        handleGetById().

        The bug here was that the call to handleGetById() may end up calling in to
        getPredictionWithoutOSRExit() for a tail call opcode. As part of that
        processing, we walk back up the stack to find the effective caller and when
        found, we lock the corresponding CodeBlock to get the predicition.
        That CodeBLock may be the same one locked above. There is no need anyway
        to hold the CodeBlock lock when calling handleGetById().

        Added a new stress test.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * tests/stress/regress-156765.js: Added.
        (realValue):
        (object.get hello):
        (ok):

2016-04-20  Mark Lam  <mark.lam@apple.com>

        Unindent an unnecessary block in stringProtoFuncSplitFast().
        https://bugs.webkit.org/show_bug.cgi?id=156802

        Reviewed by Filip Pizlo.

        In webkit.org/b/156013, I refactored stringProtoFuncSplit into
        stringProtoFuncSplitFast.  In that patch, I left an unnecessary block of code in
        its original block (with FIXMEs) to keep the diff for that patch minimal.  Now
        that the patch for webkit.org/b/156013 has landed, I will unindent that block and
        remove the FIXMEs.

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

2016-04-20  Brady Eidson  <beidson@apple.com>

        Modern IDB (Workers): Enable INDEXED_DATABASE_IN_WORKERS compile time flag, but disabled in RuntimeEnabledFeatures.
        https://bugs.webkit.org/show_bug.cgi?id=156782

        Reviewed by Alex Christensen.

        * Configurations/FeatureDefines.xcconfig:

2016-04-20  Saam barati  <sbarati@apple.com>

        Remove unused m_writtenVariables from the parser and related bits
        https://bugs.webkit.org/show_bug.cgi?id=156784

        Reviewed by Yusuke Suzuki.

        This isn't a octane/codeload speedup even though we're doing less work in
        collectFreeVariables. But it's good to get rid of things that are not used.

        * parser/Nodes.h:
        (JSC::ScopeNode::usesEval):
        (JSC::ScopeNode::usesArguments):
        (JSC::ScopeNode::usesArrowFunction):
        (JSC::ScopeNode::isStrictMode):
        (JSC::ScopeNode::setUsesArguments):
        (JSC::ScopeNode::usesThis):
        (JSC::ScopeNode::modifiesParameter): Deleted.
        (JSC::ScopeNode::modifiesArguments): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::hasDeclaredParameter):
        (JSC::Scope::preventAllVariableDeclarations):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::mergeInnerArrowFunctionFeatures):
        (JSC::Scope::getSloppyModeHoistedFunctions):
        (JSC::Scope::getCapturedVars):
        (JSC::Scope::setStrictMode):
        (JSC::Scope::strictMode):
        (JSC::Scope::fillParametersForSourceProviderCache):
        (JSC::Scope::restoreFromSourceProviderCache):
        (JSC::Parser::hasDeclaredParameter):
        (JSC::Parser::exportName):
        (JSC::Scope::declareWrite): Deleted.
        (JSC::Parser::declareWrite): Deleted.
        * parser/ParserModes.h:

2016-04-19  Saam barati  <sbarati@apple.com>

        Unreviewed, fix cloop build after r199754.

        * jsc.cpp:
        (jscmain):

2016-04-19  Michael Saboff  <msaboff@apple.com>

        iTunes crashing JavaScriptCore.dll
        https://bugs.webkit.org/show_bug.cgi?id=156647

        Reviewed by Filip Pizlo.

        Given that there there are only 128 FLS indices compared to over a 1000 for TLS,
        I eliminated the thread specific m_threadSpecificForThread and instead we look
        for the current thread in m_registeredThreads list when we need it.
        In most cases there will only be one thread.

        Added THREAD_SPECIFIC_CALL to signature of ThreadSpecific remove callbacks
        to set the calling convention correctly for Windows 32 bit.

        * heap/MachineStackMarker.cpp:
        (JSC::ActiveMachineThreadsManager::remove):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        * heap/MachineStackMarker.h:

2016-04-19  Benjamin Poulain  <bpoulain@webkit.org>

        [JSC] Small cleanup of RegisterAtOffsetList
        https://bugs.webkit.org/show_bug.cgi?id=156779

        Reviewed by Mark Lam.

        I was wondering why RegisterAtOffsetList always cache-miss.
        It looks like it is doing more than it needs to.

        We do not need to sort the values. The total order of
        RegisterAtOffset is:
        1) Order of Reg.
        2) Order of offsets.
        We already generate the list in order.

        Also allocate the right array size ahead of filling the array.

        * jit/RegisterAtOffsetList.cpp:
        (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
        (JSC::RegisterAtOffsetList::sort): Deleted.
        * jit/RegisterAtOffsetList.h:
        (JSC::RegisterAtOffsetList::append): Deleted.

2016-04-19  Saam barati  <sbarati@apple.com>

        Add a couple UNLIKELY macros in parseMemberExpression
        https://bugs.webkit.org/show_bug.cgi?id=156775

        Reviewed by Filip Pizlo.

        These UNLIKELY macros have to do with the base of the
        member expression being 'super'. I think it's safe to
        argue that this is truly UNLIKELY. I am seeing speedups
        sometimes on Octane codeload. Usually around 0.5%. Sometimes 1%.

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

2016-04-19  Saam barati  <sbarati@apple.com>

        allow jsc shell to dump sampling profiler data
        https://bugs.webkit.org/show_bug.cgi?id=156725

        Reviewed by Benjamin Poulain.

        This patch adds a '--reportSamplingProfilerData' option to the
        JSC shell which will enable the sampling profiler and dump
        its data at the end of execution. The dump will include the
        40 hottest functions and the 80 hottest bytecode locations.
        If you're using this option to debug, it's easy to just hack
        on the code to make it dump more or less information.

        * jsc.cpp:
        (CommandLine::parseArguments):
        (jscmain):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        (JSC::SamplingProfiler::stackTracesAsJSON):
        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
        (JSC::SamplingProfiler::StackFrame::hasBytecodeIndex):
        (JSC::SamplingProfiler::StackFrame::hasCodeBlockHash):
        (JSC::SamplingProfiler::setStopWatch):

2016-04-19  Mark Lam  <mark.lam@apple.com>

        Re-landing: ES6: Implement RegExp.prototype[@@search].
        https://bugs.webkit.org/show_bug.cgi?id=156331

        Reviewed by Keith Miller.

        What changed?
        1. Implemented search builtin in RegExpPrototype.js.
           The native path is now used as a fast path.
        2. Added DFG support for an IsRegExpObjectIntrinsic (modelled after the
           IsJSArrayIntrinsic).
        3. Renamed @isRegExp to @isRegExpObject to match the new IsRegExpObjectIntrinsic.
        4. Change the esSpecIsRegExpObject() implementation to check if the object's
           JSType is RegExpObjectType instead of walking the classinfo chain.

        * builtins/RegExpPrototype.js:
        (search):
        * builtins/StringPrototype.js:
        (search):
        - fixed some indentation.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileIsRegExpObject):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::isExoticForTypeof):
        (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::isType):
        * runtime/Intrinsic.h:
        - Added IsRegExpObjectIntrinsic.

        * runtime/CommonIdentifiers.h:

        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        (JSC::esSpecIsConstructor):
        - Changed to use uncheckedArgument since this is only called from internal code.
        (JSC::esSpecIsRegExpObject):
        (JSC::esSpecIsRegExp): Deleted.
        * runtime/ECMAScriptSpecInternalFunctions.h:
        - Changed to check the object for a JSType of RegExpObjectType.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Added split fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncSearchFast):
        (JSC::regExpProtoFuncSearch): Deleted.
        * runtime/RegExpPrototype.h:

        * tests/es6.yaml:
        * tests/stress/regexp-search.js:
        - Rebased test.

2016-04-19  Mark Lam  <mark.lam@apple.com>

        Replace $vm.printValue() with $vm.value().
        https://bugs.webkit.org/show_bug.cgi?id=156767

        Reviewed by Saam Barati.

        When debugging with $vm, this change allows us to do this:

            $vm.print("myObj = " + $vm.value(myObj) + "\n");

        ... instead of having to do this:

            $vm.print("myObj = ");
            $vm.printValue(myObj);
            $vm.print("\n");

        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::printValue):
        (JSC::functionValue):
        (JSC::JSDollarVMPrototype::finishCreation):
        (JSC::functionPrintValue): Deleted.

2016-04-19  Mark Lam  <mark.lam@apple.com>

        Re-landing: ES6: Implement String.prototype.split and RegExp.prototype[@@split].
        https://bugs.webkit.org/show_bug.cgi?id=156013

        Reviewed by Keith Miller.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/PromisePrototype.js:
        - refactored to use the @speciesConstructor internal function.

        * builtins/RegExpPrototype.js:
        (advanceStringIndex):
        - refactored from @advanceStringIndexUnicode() to be match the spec.
          Benchmarks show that there's no advantage in doing the unicode check outside
          of the advanceStringIndexUnicode part.  So, I simplified the code to match the
          spec (especially since @@split needs to call advanceStringIndex from more than
          1 location).
        (match):
        - Removed an unnecessary call to @Object because it was already proven above.
        - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
          Again, there's no perf regression for this.
        (regExpExec):
        (hasObservableSideEffectsForRegExpSplit):
        (split):
        (advanceStringIndexUnicode): Deleted.

        * builtins/StringPrototype.js:
        (split):
        - Modified to use RegExp.prototype[@@split].

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::lookup):
        * bytecode/BytecodeIntrinsicRegistry.h:
        - Added the @@split symbol.

        * runtime/CommonIdentifiers.h:
        * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
        (JSC::esSpecIsConstructor):
        (JSC::esSpecIsRegExp):
        * runtime/ECMAScriptSpecInternalFunctions.h: Added.

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

        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        - Removed an assert that is no longer valid.

        * runtime/RegExpObject.h:
        - Made advanceStringUnicode() public so that it can be re-used by the regexp split
          fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncSearch):
        (JSC::advanceStringIndex):
        (JSC::regExpProtoFuncSplitFast):
        * runtime/RegExpPrototype.h:

        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        - Hoisted some utility functions from StringPrototype.cpp so that they can be
          reused by the regexp split fast path.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::builtinStringSubstrInternal):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringIncludesImpl):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::jsStringWithReuse): Deleted.
        (JSC::jsSubstring): Deleted.
        (JSC::stringProtoFuncSplit): Deleted.
        * runtime/StringPrototype.h:

        * tests/es6.yaml:

2016-04-19  Commit Queue  <commit-queue@webkit.org>

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

        WebKit tests crash on Windows 32 (Requested by msaboff on
        #webkit).

        Reverted changeset:

        "iTunes crashing JavaScriptCore.dll"
        https://bugs.webkit.org/show_bug.cgi?id=156647
        http://trac.webkit.org/changeset/199726

2016-04-19  Michael Saboff  <msaboff@apple.com>

        iTunes crashing JavaScriptCore.dll
        https://bugs.webkit.org/show_bug.cgi?id=156647

        Reviewed by Saam Barati.

        Given that there there are only 128 FLS indices compared to over a 1000 for TLS, I
        eliminated the thread specific m_threadSpecificForThread and instead we look for the
        current thread in m_registeredThreads list when we need it.  In most cases there
        will only be one thread.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::machineThreadForCurrentThread):
        (JSC::MachineThreads::removeThread):
        * heap/MachineStackMarker.h:

2016-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [INTL] Use @thisNumberValue instead of `instanceof @Number`
        https://bugs.webkit.org/show_bug.cgi?id=156680

        Reviewed by Saam Barati.

        Use @thisNumberValue instead of `instanceof @Number`.
        `instanceof @Number` is not enough;
        For example, given 2 realms, the object created in one realm does not
        inherit the Number of another realm.
        Another example is that the object which does not inherit Number.

        ```
        var number = new Number(42);
        number.__proto__ = null;
        ```

        * builtins/NumberPrototype.js:
        (toLocaleString):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncValueOf):
        * runtime/NumberPrototype.h:
        * tests/stress/number-to-locale-string-should-accept-strange-number-objects.js: Added.
        (shouldBe):

2016-04-19  Commit Queue  <commit-queue@webkit.org>

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

        It caused a serious regression on 32 bit platform (Requested
        by gskachkov on #webkit).

        Reverted changeset:

        "calling super() a second time in a constructor should throw"
        https://bugs.webkit.org/show_bug.cgi?id=151113
        http://trac.webkit.org/changeset/199712

2016-04-09  Skachkov Oleksandr  <gskachkov@gmail.com>

        calling super() a second time in a constructor should throw
        https://bugs.webkit.org/show_bug.cgi?id=151113

        Reviewed by Saam Barati and Keith Miller.

        Currently, our implementation checks if 'super()' was called in a constructor more 
        than once and raises a RuntimeError before the second call. According to the spec 
        we need to raise an error just after the second super() is finished and before 
        the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
        To implement this behavior this patch adds a new op code, op_is_empty, that is used 
        to check if 'this' is empty.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsEmpty):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionCallValueNode::emitBytecode):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_empty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_empty):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/class-syntax-double-constructor.js: Added.

2016-04-18  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Fix some overhead affecting small codegen
        https://bugs.webkit.org/show_bug.cgi?id=156728

        Reviewed by Filip Pizlo.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        (JSC::AbstractMacroAssembler::random):
        cryptographicallyRandomNumber() is very costly.
        We only need it in lowering some very particular cases
        of non-trusted immediates. No inline cache needs that.

        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::link):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::addSlowCase):
        Do not copy the JumpList to access its elements.

2016-04-18  Saam barati  <sbarati@apple.com>

        implement dynamic scope accesses in the DFG/FTL
        https://bugs.webkit.org/show_bug.cgi?id=156567

        Reviewed by Geoffrey Garen.

        This patch adds dynamic scope operations to the DFG/FTL.
        This patch adds three new DFG nodes: ResolveScope, PutDynamicVar and GetDynamicVar.
        When we encounter a Dynamic/UnresolvedProperty/UnresolvedPropertyWithVarInjectionChecks
        resolve type, we will compile dynamic scope resolution nodes. When we encounter
        a resolve type that needs var injection checks and the var injection
        watchpoint has already been fired, we will compile dynamic scope resolution
        nodes.

        This patch also adds a new value to the InitializationMode enum: ConstInitialization.
        There was a subtle bug where we used to never compile the var injection variant of the 
        resolve type for an eval that injected a var where there was also a global lexical variable with the same name. 
        For example, the store compiled in this eval("var foo = 20;") wouldn't be compiled 
        with var injection checks if there was global let/const variable named "foo".
        So there was the potential for the injected var to store to the GlobalLexicalObject.
        I found this bug because my initial implementation in the DFG/FTL ran into it.
        The reason this bug existed is because when we compile a const initialization,
        we never need a var injections check. The const initialization always
        knows where to store its value. This same logic leaked into the above eval's 
        "var foo = 20" store. This new enum value allows us to distinguish const
        initialization stores from non-const initialization stores.

        (I also changed InitializationMode to be an enum class instead of an enum).

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
        (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::initializeVariable):
        (JSC::BytecodeGenerator::emitInstanceOf):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        (JSC::BytecodeGenerator::pushScopedControlFlowContext):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::initializationModeForAssignmentContext):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::EmptyLetExpression::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        (JSC::BindingNode::bindValue):
        (JSC::AssignmentElementNode::bindValue):
        (JSC::RestParameterNode::emit):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
        (JSC::DFG::ByteCodeParser::promoteToConstant):
        (JSC::DFG::ByteCodeParser::needsDynamicLookup):
        (JSC::DFG::ByteCodeParser::planLoad):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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::hasIdentifier):
        (JSC::DFG::Node::identifierNumber):
        (JSC::DFG::Node::hasGetPutInfo):
        (JSC::DFG::Node::getPutInfo):
        (JSC::DFG::Node::hasAccessorAttributes):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
        (JSC::DFG::SpeculativeJIT::compileResolveScope):
        (JSC::DFG::SpeculativeJIT::compileGetDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        * dfg/DFGSpeculativeJIT.h:
        (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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compare):
        (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
        (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/GetPutInfo.h:
        (JSC::resolveModeName):
        (JSC::initializationModeName):
        (JSC::isInitialization):
        (JSC::makeType):
        (JSC::GetPutInfo::GetPutInfo):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):

2016-04-18  Filip Pizlo  <fpizlo@apple.com>

        Disable AVX.

        Rubber stampted by Benjamin Poulain.

        AVX is silly. If you use it and some of your other code isn't careful with float register bits, you
        will run 10x slower. We could fix the underlying issue, but it's better to stay away from this odd
        instruction subset.

        This fixes a massive regression on some real code.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsAVX):
        (JSC::MacroAssemblerX86Common::updateEax1EcxFlags):

2016-04-18  Filip Pizlo  <fpizlo@apple.com>

        ToThis should have a fast path based on type info flags
        https://bugs.webkit.org/show_bug.cgi?id=156712

        Reviewed by Geoffrey Garen.

        Prior to this change, if we couldn't nail down the type of ToThis to something easy, we'd emit code
        that would take slow path if the argument was not a final object. We'd end up taking that slow path
        a lot.

        This adds a type info flag for ToThis having non-obvious behavior and changes the DFG and FTL paths
        to test this flag. This is a sub-1% speed-up on SunSpider and Octane.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::create):
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::create):
        * runtime/JSString.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::overridesGetOwnPropertySlot):
        (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
        (JSC::TypeInfo::structureIsImmortal):
        (JSC::TypeInfo::overridesToThis):
        (JSC::TypeInfo::overridesGetPropertyNames):
        (JSC::TypeInfo::prohibitsPropertyCaching):
        (JSC::TypeInfo::getOwnPropertySlotIsImpure):
        * runtime/StrictEvalActivation.h:
        (JSC::StrictEvalActivation::create):
        * runtime/Symbol.h:

2016-04-18  Filip Pizlo  <fpizlo@apple.com>

        Check to see how the perf bots react to megamorphic load being disabled.

        Rubber stamped by Chris Dumez.

        * runtime/Options.h:

2016-04-18  Keith Miller  <keith_miller@apple.com>

        We should support delete in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=156607

        Reviewed by Benjamin Poulain.

        This patch adds support for the delete in the DFG as it appears that
        some major frameworks use the operation in particularly hot functions.
        As a result, even if the function rarely ever calls delete we would never
        tier up to the DFG. This patch also changes operationDeleteById to take a
        UniquedStringImpl and return a size_t.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * 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::hasIdentifier):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDeleteById):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_del_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_del_by_id):

2016-04-17  Filip Pizlo  <fpizlo@apple.com>

        FTL should pin the tag registers at inline caches
        https://bugs.webkit.org/show_bug.cgi?id=156678

        Reviewed by Saam Barati.

        This is a long-overdue fix to our inline caches. Back when we had LLVM, we couldn't rely on the tags
        being pinned to any registers. So, if the inline caches needed tags, they'd have to materialize them.
        
        This removes those materializations. This should reduce the amount of code generated in inline caches
        and it should make inline caches faster. The effect appears to be small.

        It may be that after this change, we'll even be able to kill the
        HaveTagRegisters/DoNotHaveTagRegisters logic.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generateImpl):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileIn):
        (JSC::FTL::DFG::LowerDFGToB3::getById):
        * jit/Repatch.cpp:
        (JSC::readCallTarget):
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

2016-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES7] yield star should not return if the inner iterator.throw returns { done: true }
        https://bugs.webkit.org/show_bug.cgi?id=156576

        Reviewed by Saam Barati.

        This is slight generator fix in ES7. When calling generator.throw(),
        the yield-star should call the throw() of the inner generator. At that
        time, when the result of throw() is { done: true}, the generator should
        not stop itself.

            function * gen()
            {
                yield * (function * () {
                    try {
                        yield 42;
                    } catch (error) { }
                }());
                // Continue executing.
                yield 42;
            }

            let g = gen();
            g.next();
            shouldBe(g.throw().value, 42);


        * builtins/GeneratorPrototype.js:
        (generatorResume):
        (next):
        (return):
        (throw):
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDelegateYield):
        * runtime/JSGeneratorFunction.h:
        * tests/stress/generator-yield-star.js:
        (gen):
        * tests/stress/yield-star-throw-continue.js: Added.
        (shouldBe):
        (generator):
        (shouldThrow):

2016-04-17  Jeremy Huddleston Sequoia  <jeremyhu@apple.com>

        Fix incorrect assumption that APPLE implies Mac.
        https://bugs.webkit.org/show_bug.cgi?id=156683
    
        Addresses build failure introduced in r199094

        Reviewed by Alex Christensen.

        * CMakeLists.txt:

2016-04-17  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] ReduceDoubleToFloat should work accross Phis
        https://bugs.webkit.org/show_bug.cgi?id=156603
        <rdar://problem/25736205>

        Reviewed by Saam Barati and Filip Pizlo.

        This patch extends B3's ReduceDoubleToFloat phase to work accross
        Upsilon-Phis. This is important to optimize loops and some crazy cases.

        In its simplest form, we can have conversion propagated from something
        like this:
            Double @1 = Phi()
            Float @2 = DoubleToFloat(@1)

        When that happens, we just need to propagate that the result only
        need float precision accross all values coming to this Phi.


        There are more complicated cases when the value produced is effectively Float
        but the user of the value does not do DoubleToFloat.

        Typically, we have something like:
            #1
                @1 = ConstDouble(1)
                @2 = Upsilon(@1, ^5)
            #2
                @3 = FloatToDouble(@x)
                @4 = Upsilon(@3, ^5)
            #3
                @5 = Phi()
                @6 = Add(@5, @somethingFloat)
                @7 = DoubleToFloat(@6)

        Here with a Phi-Upsilon that is a Double but can be represented
        as Float without loss of precision.

        It is valuable to convert such Phis to float if and only if the value
        is used as float. Otherwise, you may be just adding useless conversions
        (for example, two double constants that flow into a double Add should not
        turn into two float constant flowing into a FloatToDouble then Add).


        ReduceDoubleToFloat do two analysis passes to gather the necessary
        meta information. Then we have a simplify() phase to actually reduce
        operation. Finally, the cleanup() pass put the graph into a valid
        state again.

        The two analysis passes work by disproving that something is float.
        -findCandidates() accumulates anything used as Double.
        -findPhisContainingFloat() accumulates phis that would lose precision
         by converting the input to float.

        With this change, Unity3D improves by ~1.5%, box2d-f32 improves
        by ~2.8% (on Haswell).

        * b3/B3ReduceDoubleToFloat.cpp:
        (JSC::B3::reduceDoubleToFloat):
        * b3/testb3.cpp:
        (JSC::B3::testCompareTwoFloatToDouble):
        (JSC::B3::testCompareOneFloatToDouble):
        (JSC::B3::testCompareFloatToDoubleThroughPhi):
        (JSC::B3::testDoubleToFloatThroughPhi):
        (JSC::B3::testDoubleProducerPhiToFloatConversion):
        (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
        (JSC::B3::testDoubleProducerPhiWithNonFloatConst):
        (JSC::B3::testStoreDoubleConstantAsFloat):
        (JSC::B3::run):
        * tests/stress/double-compare-to-float.js: Added.
        (canSimplifyToFloat):
        (canSimplifyToFloatWithConstant):
        (cannotSimplifyA):
        (cannotSimplifyB):
        * tests/stress/double-to-float.js: Added.
        (upsilonReferencingItsPhi):
        (upsilonReferencingItsPhiAllFloat):
        (upsilonReferencingItsPhiWithoutConversion):
        (conversionPropagages):
        (chainedUpsilonBothConvert):
        (chainedUpsilonFirstConvert):

2016-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Use @isObject to check Object Type instead of using instanceof
        https://bugs.webkit.org/show_bug.cgi?id=156676

        Reviewed by Darin Adler.

        Use @isObject instead of `instanceof @Object`.
        The `instanceof` check is not enough to check Object Type.
        For example, given 2 realms, the object created in one realm does not inherit the Object of another realm.
        Another example is that the object which does not inherit Object.
        This object can be easily created by calling `Object.create(null)`.

        * builtins/RegExpPrototype.js:
        (match):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionCreateGlobalObject):
        * tests/stress/regexp-match-in-other-realm-should-work.js: Added.
        (shouldBe):
        * tests/stress/regexp-match-should-work-with-objects-not-inheriting-object-prototype.js: Added.
        (shouldBe):
        (regexp.exec):

2016-04-17  Darin Adler  <darin@apple.com>

        Remove more uses of Deprecated::ScriptXXX
        https://bugs.webkit.org/show_bug.cgi?id=156660

        Reviewed by Antti Koivisto.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptCallArgumentHandler::appendArgument): Deleted
        unneeded overloads that take a ScriptObject and ScriptValue.
        * bindings/ScriptFunctionCall.h: Ditto.

        * bindings/ScriptObject.h: Added operator so this can change
        itself into a JSObject*. Helps while phasing this class out.

        * bindings/ScriptValue.h: Export toInspectorValue so it can be
        used in WebCore.

        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript): Changed
        return value from Deprecated::ScriptObject to JSObject*.
        (Inspector::InjectedScriptManager::injectedScriptFor): Updated for
        the return value change above.
        * inspector/InjectedScriptManager.h: Ditto.

2016-04-16  Benjamin Poulain  <bpoulain@webkit.org>

        [JSC] DFG should support relational comparisons of Number and Other
        https://bugs.webkit.org/show_bug.cgi?id=156669

        Reviewed by Darin Adler.

        In Sunspider/3d-raytrace, DFG falls back to JSValue in some important
        relational compare because profiling sees "undefined" from time to time.

        This case is fairly common outside Sunspider too because of out-of-bounds array access.
        Unfortunately for us, our fallback for compare is really inefficient.

        Fortunately, relational comparison with null/undefined/true/false are trival.
        We can just convert both side to Double. That's what this patch adds.

        I also extended constant folding for those cases because I noticed
        a bunch of "undefined" constant going through DoubleRep at runtime.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * tests/stress/compare-number-and-other.js: Added.
        (opaqueSideEffect):
        (let.operator.of.operators.eval.testPolymorphic):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.eval.testMonomorphic):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.testMonomorphicLeftConstant):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.testMonomorphicRightConstant):
        (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.i.testPolymorphic):

2016-04-16  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] FRound/Negate can produce an impure NaN out of a pure NaN
        https://bugs.webkit.org/show_bug.cgi?id=156528

        Reviewed by Filip Pizlo.

        If you fround a double with the bits 0xfff7000000000000
        you get 0xfffe000000000000. The first is a pure NaN, the second isn't.

        This is without test because I could not find a way to create a 0xfff7000000000000
        while convincing DFG that its pure.
        When we purify NaNs from typed array, we use a specific value of NaN if the input
        is any NaN, making testing tricky.

        * bytecode/SpeculatedType.cpp:
        (JSC::typeOfDoubleNegation):

2016-04-16  Konstantin Tokarev  <annulen@yandex.ru>

        JS::DFG::nodeValuePairListDump does not compile with libstdc++ 4.8
        https://bugs.webkit.org/show_bug.cgi?id=156670

        Reviewed by Darin Adler.

        * dfg/DFGNode.h:
        (JSC::DFG::nodeValuePairListDump): Modified to use lambda as comparator.

2016-04-16  Konstantin Tokarev  <annulen@yandex.ru>

        [mips] Implemented moveZeroToDouble.
        https://bugs.webkit.org/show_bug.cgi?id=155429

        Reviewed by Darin Adler.

        This function is required to fix compilation after r197687.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::moveZeroToDouble):

2016-04-15  Darin Adler  <darin@apple.com>

        Reduce use of Deprecated::ScriptXXX classes
        https://bugs.webkit.org/show_bug.cgi?id=156632

        Reviewed by Alex Christensen.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptCallArgumentHandler::appendArgument): Deleted version that takes a Deprecated::ScriptValue.
        (Deprecated::ScriptFunctionCall::call): Changed to return a JSValue.
        * bindings/ScriptFunctionCall.h: Updated for the above.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue): Moved from Deprecated namespace to Inspector namespace. Later, we should
        move this to another source file in the inspector directory.
        (Inspector::toInspectorValue): Added.
        (Deprecated::ScriptValue::toInspectorValue): Updated for change to underlying function.
        * bindings/ScriptValue.h: Update for the above.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::evaluateOnCallFrame): Changed arguments and return values from
        Deprecated::ScriptValue to JSC::JSValue.
        (Inspector::InjectedScript::functionDetails): Ditto.
        (Inspector::InjectedScript::wrapCallFrames): Ditto.
        (Inspector::InjectedScript::wrapObject): Ditto.
        (Inspector::InjectedScript::wrapTable): Ditto.
        (Inspector::InjectedScript::previewValue): Ditto.
        (Inspector::InjectedScript::setExceptionValue): Ditto.
        (Inspector::InjectedScript::findObjectById): Ditto.
        (Inspector::InjectedScript::inspectObject): Ditto.
        * inspector/InjectedScript.h: Ditto.
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled): Ditto.
        (Inspector::InjectedScriptBase::makeCall): Ditto.
        * inspector/InjectedScriptBase.h: Ditto.
        * inspector/InjectedScriptModule.cpp:
        (Inspector::InjectedScriptModule::ensureInjected): Ditto.
        * inspector/ScriptDebugListener.h: Ditto.
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::evaluateBreakpointAction): Ditto.
        (Inspector::ScriptDebugServer::dispatchDidPause): Ditto.
        (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe): Ditto.
        (Inspector::ScriptDebugServer::exceptionOrCaughtValue): Ditto.
        * inspector/ScriptDebugServer.h: Ditto.
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason): Ditto.
        (Inspector::InspectorDebuggerAgent::didPause): Ditto.
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe): Ditto.
        (Inspector::InspectorDebuggerAgent::didContinue): Ditto.
        (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState): Ditto.
        * inspector/agents/InspectorDebuggerAgent.h: Ditto.
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::getPreview): Ditto.
        (Inspector::InspectorHeapAgent::getRemoteObject): Ditto.

2016-04-15  Keith Miller  <keith_miller@apple.com>

        Some JIT/DFG operations need NativeCallFrameTracers
        https://bugs.webkit.org/show_bug.cgi?id=156650

        Reviewed by Michael Saboff.

        Some of our operation functions did not have native call frame
        tracers. This meant that we would crash occasionally on some
        of our tests when they triggered a GC in one of the functions
        without a tracer. In particular, this was exemplified by another
        upcoming patch when calling operationSetFunctionName.

        This patch does not add tests since this happens consistently in
        the patch adding delete_by_id to the DFG.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:

2016-04-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: sourceMappingURL not used when sourceURL is set
        https://bugs.webkit.org/show_bug.cgi?id=156021
        <rdar://problem/25438417>

        Reviewed by Timothy Hatcher.

        Clean up Debugger.sourceParsed to separately include:

            - url ("resource URL", "source url" in JSC APIs)
            - sourceURL - //# sourceURL directive

        By always having the resource URL the Web Inspector frontend
        can better match this Script to a Resource of the same URL,
        and decide to use the sourceURL if it is available when
        appropriate.

        * inspector/protocol/Debugger.json:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        Send the new sourceParsed parameters.

2016-04-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Cleanup inspector/debugger tests
        https://bugs.webkit.org/show_bug.cgi?id=156619

        Reviewed by Brian Burg.

        While cleaning up the tests it exposed the fact that breakpoints
        were not getting disabled when the inspector closes. This means
        that opening the inspector, with breakpoints, and closing the
        inspector, would leave the JSC::Debugger thinking breakpoints
        are active. The JSC::Debugger should be reset.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::disable):

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        CopiedBlock should be 64kB

        Reviewed by Benjamin Poulain.

        Let's try another value.

        This is 25% faster on kraken-audio-beat-detection on Mac Pro.

        * heap/CopiedBlock.h:

2016-04-15  Zan Dobersek  <zdobersek@igalia.com>

        Tail call optimizations lead to crashes on ARM Thumb + Linux
        https://bugs.webkit.org/show_bug.cgi?id=150083

        Reviewed by Csaba Osztrogonác.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::repatchNearCall): In case of a tail call relink to the
        data location of the destination, and not the executable address. This is needed for
        the ARM Thumb2 platform where both the source and destination addresses of a jump relink
        must not have the bottom bit decorated, as asserted in ARMv7Assembler::relinkJump().
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall): Similarly, when linking a tail call we must link to the
        address that has a non-decorated bottom bit, as asserted in ARMv7Assembler::linkJumpAbsolute().

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling out r199567.

        performance regression on kraken on macbook*

        Reverted changeset:

        "CopiedBlock should be 8kB"
        https://bugs.webkit.org/show_bug.cgi?id=156610
        http://trac.webkit.org/changeset/199567

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        CopiedBlock should be 8kB
        https://bugs.webkit.org/show_bug.cgi?id=156610

        Reviewed by Michael Saboff.

        On Mac Pro, this is:

            15% faster on kraken-audio-beat-detection

            5% faster on v8-splay

        Hopefully, this will be OK on MacBook* bots as well.

        32kB is the full size of L1 cache on x86. So, allocating and zero-filling
        a 32kB CopiedBlock would basically flush the L1 cache. We can ameliorate
        this problem by using smaller blocks -- or, if that doesn't work, we can
        use larger blocks to amortize the cost.

        * heap/CopiedBlock.h:

2016-04-14  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess should try to generate a stub only once
        https://bugs.webkit.org/show_bug.cgi?id=156555

        Reviewed by Geoffrey Garen.
        
        This changes the PolymorphicAccess heuristics to reduce the amount of code generation even
        more than before. We used to always generate a monomorphic stub for the first case we saw.
        This change disables that. This change also increases the buffering countdown to match the
        cool-down repatch count. This means that we will allow for ten slow paths for adding cases,
        then we will generate a stub, and then we will go into cool-down and the repatching slow
        paths will not even attempt repatching for a while. After we emerge from cool-down - which
        requires a bunch of slow path calls - we will again wait for ten slow paths to get new
        cases. Note that it only takes 13 cases to cause the stub to give up on future repatching
        entirely. Also, most stubs don't ever get to 10 cases. Therefore, for most stubs this change
        means that each IC will repatch once. If they make it to two repatching, then the likelihood
        of a third becomes infinitesimal because of all of the rules that come into play at that
        point (the size limit being 13, the fact that we go into exponential cool-down every time we
        generate code, and the fact that if we have lots of self cases then we will create a
        catch-all megamorphic load case).

        This also undoes a change to the megamorphic optimization that I think was unintentional.
        As in the change that originally introduced megamorphic loads, we want to do this only if we
        would otherwise exhaust the max size of the IC. This is because megamorphic loads are pretty
        expensive and it's best to use them only if we know that the alternative is giving up on
        caching.

        This is neutral on JS benchmarks, but looks like it's another speed-up for page loading.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::dump):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::StructureStubInfo):
        * runtime/Options.h:

2016-04-14  Mark Lam  <mark.lam@apple.com>

        Update treatment of invoking RegExp.prototype methods on RegExp.prototype.
        https://bugs.webkit.org/show_bug.cgi?id=155922

        Reviewed by Keith Miller.

        According to the TC39 committee, when invoking the following RegExp.prototype
        methods on the RegExp.prototype:
        1. RegExp.prototype.flags yields ""
        2. RegExp.prototype.global yields undefined
        3. RegExp.prototype.ignoreCase yields undefined
        4. RegExp.prototype.multiline yields undefined
        5. RegExp.prototype.unicode yields undefined
        6. RegExp.prototype.source yields "(?:)"
        7. RegExp.prototype.sticky yields undefined
        8. RegExp.prototype.toString() yields "/(?:)/"

        and RegExp.prototype is still NOT an instance of RegExp.  The above behavior
        changes is a special dispensation applicable only to RegExp.prototype.  The ES6
        spec of throwing errors still applies if those methods are applied to anything =
        else that is not a RegExp object.

        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoGetterGlobal):
        (JSC::regExpProtoGetterIgnoreCase):
        (JSC::regExpProtoGetterMultiline):
        (JSC::regExpProtoGetterSticky):
        (JSC::regExpProtoGetterUnicode):
        (JSC::regExpProtoGetterFlags):
        (JSC::regExpProtoGetterSource):
        - Implemented new behavior.

        * tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js:
        (test):
        - Updated to match current kangax test.

2016-04-14  Geoffrey Garen  <ggaren@apple.com>

        Some imported ES6 tests are missing __createIterableObject
        https://bugs.webkit.org/show_bug.cgi?id=156584

        Reviewed by Keith Miller.

        These tests were failing because I neglected to include __createIterableObject
        when I first imported them. Now they pass.

        * tests/es6.yaml:
        * tests/es6/Array_static_methods_Array.from_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Array_static_methods_Array.from_instances_of_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Array_static_methods_Array.from_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/Array_static_methods_Array.from_map_function_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Array_static_methods_Array.from_map_function_instances_of_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/Map_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/Promise_Promise.all_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test.asyncTestPassed):
        * tests/es6/Promise_Promise.race_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test.asyncTestPassed):
        * tests/es6/Set_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/WeakMap_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/WeakSet_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/destructuring_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/destructuring_with_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/destructuring_with_instances_of_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/for..of_loops_iterator_closing_break.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/for..of_loops_iterator_closing_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/for..of_loops_with_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/for..of_loops_with_instances_of_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/generators_yield_star_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/spread_..._operator_with_generic_iterables_in_arrays.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/spread_..._operator_with_generic_iterables_in_calls.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/spread_..._operator_with_instances_of_iterables_in_arrays.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):
        * tests/es6/spread_..._operator_with_instances_of_iterables_in_calls.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        (test):

2016-04-13  Alex Christensen  <achristensen@webkit.org>

        CMake MiniBrowser should be an app bundle
        https://bugs.webkit.org/show_bug.cgi?id=156521

        Reviewed by Brent Fulgham.

        * PlatformMac.cmake:
        Unreviewed build fix.  Define __STDC_WANT_LIB_EXT1__ so we can find memset_s.

2016-04-13  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Improve Class instances and JSC API Exported Values view in Console / ObjectTree
        https://bugs.webkit.org/show_bug.cgi?id=156566
        <rdar://problem/16392365>

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        Treat non-basic object types as not lossless so they can be expanded.
        Show non-enumerable native getters in Object previews.

2016-04-13  Michael Saboff  <msaboff@apple.com>

        Some tests fail with ES6 `u` (Unicode) flag for regular expressions
        https://bugs.webkit.org/show_bug.cgi?id=151597

        Reviewed by Geoffrey Garen.

        Added two new tables to handle the anomolies of \w and \W CharacterClassEscapes
        when specified in RegExp's with both the unicode and ignoreCase flags.  Given the
        case folding rules described in the standard vie the meta function Canonicalize(),
        which allow cross ASCII case folding when unicode is specified, the unicode characters
        \u017f (small sharp s) and \u212a (kelvin symbol) are part of the \w (word) characterClassEscape.
        This is true because they case fold to 's' and 'k' respectively.  Because they case fold
        to lower case letters, the corresponding letters, 'k', 'K', 's' and 'S', are also matched with
        \W with the unicode and ignoreCase flags.

        * create_regex_tables:
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
        (JSC::Yarr::YarrPattern::YarrPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::wordcharCharacterClass):
        (JSC::Yarr::YarrPattern::wordUnicodeIgnoreCaseCharCharacterClass):
        (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
        (JSC::Yarr::YarrPattern::nonwordUnicodeIgnoreCaseCharCharacterClass):

2016-04-13  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r199502 and r199511.
        https://bugs.webkit.org/show_bug.cgi?id=156557

        Appears to have in-browser perf regression (Requested by mlam
        on #webkit).

        Reverted changesets:

        "ES6: Implement String.prototype.split and
        RegExp.prototype[@@split]."
        https://bugs.webkit.org/show_bug.cgi?id=156013
        http://trac.webkit.org/changeset/199502

        "ES6: Implement RegExp.prototype[@@search]."
        https://bugs.webkit.org/show_bug.cgi?id=156331
        http://trac.webkit.org/changeset/199511

2016-04-13  Keith Miller  <keith_miller@apple.com>

        isJSArray should use ArrayType rather than the ClassInfo
        https://bugs.webkit.org/show_bug.cgi?id=156551

        Reviewed by Filip Pizlo.

        Using the JSType rather than the ClassInfo should be slightly faster
        since the type is inline on the cell whereas the ClassInfo is only
        on the structure.

        * runtime/JSArray.h:
        (JSC::isJSArray):

2016-04-13  Mark Lam  <mark.lam@apple.com>

        ES6: Implement RegExp.prototype[@@search].
        https://bugs.webkit.org/show_bug.cgi?id=156331

        Reviewed by Keith Miller.

        What changed?
        1. Implemented search builtin in RegExpPrototype.js.
           The native path is now used as a fast path.
        2. Added DFG support for an IsRegExpObjectIntrinsic (modelled after the
           IsJSArrayIntrinsic).
        3. Renamed @isRegExp to @isRegExpObject to match the new IsRegExpObjectIntrinsic.
        4. Change the esSpecIsRegExpObject() implementation to check if the object's
           JSType is RegExpObjectType instead of walking the classinfo chain.

        * builtins/RegExpPrototype.js:
        (search):
        * builtins/StringPrototype.js:
        (search):
        - fixed some indentation.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * 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::compileIsArrayConstructor):
        (JSC::DFG::SpeculativeJIT::compileIsRegExpObject):
        (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
        * 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/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
        (JSC::FTL::DFG::LowerDFGToB3::isExoticForTypeof):
        (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject):
        (JSC::FTL::DFG::LowerDFGToB3::isType):
        * runtime/Intrinsic.h:
        - Added IsRegExpObjectIntrinsic.

        * runtime/CommonIdentifiers.h:

        * runtime/ECMAScriptSpecInternalFunctions.cpp:
        (JSC::esSpecIsConstructor):
        - Changed to use uncheckedArgument since this is only called from internal code.
        (JSC::esSpecIsRegExpObject):
        (JSC::esSpecIsRegExp): Deleted.
        * runtime/ECMAScriptSpecInternalFunctions.h:
        - Changed to check the object for a JSType of RegExpObjectType.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Added split fast path.

        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncSearchFast):
        (JSC::regExpProtoFuncSearch): Deleted.
        * runtime/RegExpPrototype.h:

        * tests/es6.yaml:
        * tests/stress/regexp-search.js:
        - Rebased test.

2016-04-12  Filip Pizlo  <fpizlo@apple.com>

        PolymorphicAccess::regenerate() shouldn't have to clone non-generated AccessCases
        https://bugs.webkit.org/show_bug.cgi?id=156493

        Reviewed by Geoffrey Garen.

        Cloning AccessCases is only necessary if they hold some artifacts that are used by code that
        they already generated. So, if the state is not Generated, we don't have to bother with
        cloning them.

        This should speed up PolymorphicAccess regeneration a bit more.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::commit):
        (JSC::PolymorphicAccess::regenerate):

2016-04-13  Mark Lam  <mark.lam@apple.com>

        ES6: Implement String.prototype.split and RegExp.prototype[@@split].
        https://bugs.webkit.org/show_bug.cgi?id=156013

        Reviewed by Keith Miller.

        Re-landing r199393 now that the shadow chicken crash has been fixed.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/GlobalObject.js:
        (speciesConstructor):
        * builtins/PromisePrototype.js:
        - refactored to use the @speciesConstructor internal function.

        * builtins/RegExpPrototype.js:
        (advanceStringIndex):
        - refactored from @advanceStringIndexUnicode() to be match the spec.
          Benchmarks show that there's no advantage in